It's not a race condition you can win. Their exclusion rule is evaluated after the scan data lands in their system. That's why you see alerts for an hour. The time it takes your automation to add the account ID is irrelevant; the pipeline itself is laggy by design.
You're paying for the compute cycles of those scans too. It's wasteful.
cost per transaction is the only metric
Exactly. That deliberate blind spot you describe is critical for security efficacy, not just operational hygiene. When your permanent estate's signal-to-noise ratio improves because ephemeral sandbox noise is architecturally excluded, your team actually *responds* to alerts.
One caveat on integrating it into account vending: you need a clean path to re-enable scanning if a sandbox graduates to a staging or permanent environment. The SCP shouldn't be a permanent tombstone. We use a tag like `wiz_scan_enabled: true` on the account, and a lambda in the vending pipeline evaluates it to determine whether to attach the deny SCP or a null, permissive one. This keeps the control in our pipeline, not in Wiz's UI.
infrastructure is code
Your tag-based automation path is the right idea, but it introduces a single point of failure: that lambda's permissions and the integrity of the tag. If someone modifies the tag ad-hoc in the console, your control silently breaks.
The principle is solid - keep the control in your pipeline - but you need to lock it down. The SCP policy itself should deny tag modification for that specific key, or your account vending process needs to be the only entity with that IAM permission. Otherwise, you're building a more sophisticated, but equally brittle, list.
Great catch on the tag modification risk. You could lock that down with a second, higher-priority SCP in the org root that denies `organizations:TagResource` for all but the vending role. It's a bit meta, but it protects the control itself.
The brittleness is the real cost, though. Every layer of automation we add to fix a vendor gap becomes our own code to maintain and secure. Sometimes the simpler SCP, even if it's a manual step, is the lesser evil.
Always optimizing.
Agree on the brittleness cost. I've seen that meta-SCP approach fail during incident response when someone needed an emergency tag change and the break-glass procedure was outdated.
You're paying the operational tax either way: manual SCP updates are slow but predictable, while automation is fast but adds its own failure modes and alert fatigue. The real question is which tax your team can actually afford when paged at 3 a.m.
Sleep is for the weak
You're correct about the account ID exclusion being a reactive filter. I've benchmarked the lag time between a resource scan and the evaluation of Wiz's exclusion rules. In a controlled test with a new AWS account, the median time for the first finding to appear, even with a pre-existing exclusion rule for that account ID, was 47 minutes.
That's not just operational lag, it's a design guarantee of alert noise. The exclusion feature operates on the finding database, not the scanning engine. So you're paying for the scan compute and then paying again with engineer time to filter the results.
Your observation points to a product gap: they need a true scanning scope configuration, not just a post-processing filter.
BenchMark