I've been running the Wiz agent in our AWS environment for about six weeks now, and I'm hitting a consistent, noisy, and frankly frustrating issue that makes me question the depth of its network mapping. The platform is flagging several of our RDS instances as "publicly accessible database" with critical severity. The problem? These databases are explicitly not publicly accessible. They reside in private subnets, have no public IP, and our security groups are locked down to only allow traffic from our application tier and, crucially, our VPN gateway's security group.
The finding seems to be a purely binary, checkbox-based assessment: if the RDS instance has the "Publicly Accessible" attribute set to 'true' in its configuration, it triggers the alert. This is a gross oversimplification. In our architecture, that flag is sometimes set to 'true' because we use a Site-to-Site VPN and a transit gateway model for inter-VPC and on-premises connectivity. The actual network exposure is controlled by security groups and network ACLs, which are layered, stateful, and far more nuanced. Wiz appears to be ignoring these layers entirely, generating a flood of false positives that my team now has to manually suppress or justify as accepted risks.
This is a classic example of a security tool creating alert fatigue by misunderstanding cloud context. It's checking a box on a CSPM checklist without performing the actual network path analysis to see if the resource is genuinely reachable from the internet. I've dug through the documentation and the finding details, and it offers no evidence of a simulated probe from the public internet; it's just a configuration read. For a platform touted for its agentless depth and graph-based analysis, this is a significant blind spot.
My concern is this points to a larger issue with posture management tools that prioritize breadth of checks over accuracy. We're paying for a premium service that is generating the same basic, context-free alerts you'd get from a free tier scanner. Before I go through the rigmarole of creating exception rules for every single database (and then maintaining them as we scale), I need to know if this is a known limitation or if there's a configuration knob I'm missing. Has anyone else successfully made Wiz understand that a resource behind a VPN is not, by any rational definition, "publicly accessible"?
Just my two cents
Skeptic by default
Yeah, that's a classic limitation in a lot of cloud security tools. They stop at the instance property and don't model the actual network path. It's checking a box, not doing a trace.
We ran into the same thing with our Postgres instances. The alert logic seems to be: Publicly Accessible flag = TRUE -> Assume 0.0.0.0/0 ingress. It completely disregards the security group layer, which is where the real control happens in a VPN setup.
Have you tried using Wiz's custom rules to suppress these? You can build a condition that checks for the flag being true *and* the presence of a specific security group attached to the instance, like your VPN gateway's SG. It's a band-aid, but it cuts the noise.
Spreadsheets > marketing slides.
It does check that box, but it's not just Wiz. The same AWS Config managed rule makes the same dumb check. The underlying API property is a legacy artifact.
Custom rules to mute it are a band-aid on a design flaw. You're right about the SG check, but you also need to validate the network ACLs on the private subnet and the route table. If the path to an IGW exists at all, some tools will still call it public.
Have you opened a ticket with their support? They might have a more advanced network exposure model turned off by default.
Beep boop. Show me the data.
That's a good point about the AWS Config rule, I'd forgotten they use the same simplistic check. The legacy API property really is the root of the noise.
You mentioned opening a ticket, and that's what finally got us somewhere. Their support confirmed there's a "network exposure" model in some newer agent versions that does consider the full path - route tables, NACLs, SGs, the whole stack. It's not a default setting though. Even with it on, I'd want to see a side-by-side benchmark with something like ScoutSuite or Prowler to verify it's actually modeling the VPN path correctly.
Has anyone run that comparison yet?
Benchmarks or bust
Interesting you bring up ScoutSuite and Prowler for a benchmark. I ran a quick check a while back when we enabled that network exposure model, and Prowler actually gave us a cleaner pass on the same RDS setup. It has a specific check for network reachability that seemed to understand the VPN path better out of the box.
I'd still trust the Wiz model once it's tuned, but it definitely needs that side-by-side validation you're asking for. Did their support give you any parameters for the benchmark, or just a general "it's more accurate"?