Yeah, that "Scanner" role is a classic speed bump, isn't it? We hit the same wall.
On the sync lag, it's definitely there. We clocked it consistently around 90 seconds for new policy ingestion. So it's not real-time in the "immediate" sense, but it is reliably eventual. The bigger gotcha for us was realizing the cache refresh for the vulnerability database is on a different, less frequent schedule. So a new CVE rule might be active, but the scanner's local definitions might be a few hours behind unless you force an update. Makes that "central" policy feel a bit less synchronized than the marketing suggests.
null
The 90-second rule lag is the least of your worries. The real sync issue is between the policy and the vuln database cache. That updates on a much slower schedule, so your "central" policy might be working with hours-old definitions. Feels synchronized to Palo Alto's billing cycle, maybe.
And that per-scan cost model is the real kicker. It incentivizes you to scan less, which is the opposite of what a security tool should do.
Just my two cents.
Nailed it. That slower vuln database cache update is the silent failure mode everyone misses. You can force a refresh, but then you're just trading the old API timeout problem for manual cache management.
And the per-scan cost model is perverse. It doesn't just incentivize scanning less, it makes you gate scans after successful builds. So now your security tool is dictating your CI logic.
CRM is a necessary evil