Alright, fellow Wiz users, I need to tap into the collective wisdom here. I’m deep into setting up our cloud security posture, and while I’m generally a fan of Wiz’s visibility, I’ve hit a real snag with managing scan scope. Specifically, **keeping its persistent scans out of our non-production sandbox and development accounts.**
We have a multi-account setup in AWS, with a clear separation of prod, staging, and several dev/sandbox accounts that are spun up and torn down frequently. The data in these sandboxes is often synthetic, messy, or contains deliberate "bad" configurations for testing. We *don’t* want these triggering alerts in our central Wiz dashboard—it creates alert fatigue and obscures real, critical issues in production.
I’ve been wrestling with the **Exclusions** feature, and I have to say, it feels clunky for this specific use case. It seems designed more for one-off resource exclusions rather than broad, account-level operational patterns. Here’s what I’ve tried and where it falls short:
* **Trying to exclude by AWS Account ID:** You can create an exclusion rule with a scope like `cloud.account.id in (123456789012, 210987654321)`. This *kind of* works, but it’s a manual, static list. Every time a new sandbox account is created, I have to remember to add it to the rule. It’s operational overhead we shouldn’t have.
* **Using tags:** We tag all sandbox resources with `Environment=Sandbox`. But Wiz exclusions require you to specify *which* finding types to exclude, and you have to apply it to every project. If a new finding type is introduced by Wiz, it’s not covered. I’d need a blanket "ignore everything from this tag" rule.
* **The volume of rules:** To effectively silence an account, you might need multiple exclusions for different services and finding types. It becomes a rule management nightmare.
What I *wish* for is a first-class concept of "Account Groups" or "Environments" where I could just say "Apply continuous scanning with full alerting to Prod, but for the 'Sandbox' group, just do periodic scans or only report critical issues." A centralized, account-level toggle.
My current workaround is a messy combo:
```json
// A sample of the clunky rule logic needed
{
"name": "Suppress-Sandbox-Accounts",
"target": {
"cloud.account.id": ["123456789012"]
},
"controls": ["CIS_1_4", "CIS_2_5"], // The list goes on and on
"reason": "Sandbox account - noisy development"
}
```
**So my questions to the community:**
* Has anyone built a more elegant solution? Perhaps using Wiz’s API to dynamically update exclusions based on AWS Organizations tags?
* Are there plans for a more robust environment-based scoping mechanism that I've missed?
* Would a service account integration pattern (where Wiz only scans accounts with a specific trust policy) be a better path?
I love the tool, but this feels like an operational gap for modern, dynamic cloud environments. How are you all handling this?
Data nerd out
Data nerd out
That "kind of works" is the most damning review of a security feature I've ever read. You've hit the core issue: the tool is built for static, known resources in a tidy world, not for the operational chaos we actually manage. I've seen teams try to solve this by tagging every sandbox resource with a "DoNotScan" label and creating dynamic exclusions off that, but it's just a more automated form of the same clunkiness. You're now maintaining policy in two places - your IaC and the Wiz console. The real question isn't how to make exclusions work, it's why a platform touting cloud-native intelligence can't infer intent from account naming or OU structure.
cg
The clunkiness you're seeing is by design. That exclusion engine is a compliance checkbox, not an operational tool. When you say >one-off resource exclusions< you're spot on, it's built for "don't scan this one specific S3 bucket forever," not for ephemeral chaos.
You think they'd have learned from the same mess in on-prem SIEMs a decade ago. Guess not.
Ever check what happens to an excluded resource when it's deleted and a new one gets the same logical ID in your sandbox? The exclusion sticks. Good luck.
—aB
Wait, so if an exclusion sticks to a logical ID, does that mean when we tear down a test VPC and rebuild it for the next sprint, the new one is already excluded without us knowing? That's... not great.
How do you even audit that? Is there a report for "exclusions attached to deleted resources" or something?
Seems like the kind of quiet misconfiguration that could bite you later.
I've been down that exact road. When you say it *kind of* works to exclude by AWS Account ID, what finally broke it for us was the lag. We'd add a new sandbox account ID to the exclusion list, but Wiz would still scan it for a good 30-60 minutes before the policy fully propagated and suppressed alerts.
That delay meant synthetic test data would still fire off critical findings, and we'd have to go manually dismiss them anyway, defeating the whole purpose.
Has anyone figured out if there's a way to pre-stage account IDs for exclusion, or is it always reactive?