So the vendor's own docs say you can create a custom policy to flag publicly exposed RDS snapshots. Great. But have you actually tried to make it work? The out-of-the-box policies are, predictably, a mile wide and an inch deep, missing the specific scenarios that will get your environment owned.
Here’s the painful truth: their "query builder" is a thin veneer over a limited subset of your cloud provider's API. To actually catch *all* the risky states, you need to stitch together multiple conditions they don't advertise. After wasting an afternoon auditing their default "Publicly Accessible RDS Snapshot" policy, I found it missed snapshots shared with specific AWS accounts (which is still a massive exposure).
If you're determined to use the tool you've already paid for, here's a more robust approach. Don't use the visual builder; go straight to the JSON policy editor.
* **Target Resource:** `AWS::RDS::DBSnapshot`
* **Condition 1:** `attribute.dbsnapshot.attributes.status == "available"` (Filters out in-progress snapshots)
* **Condition 2:** A combined logic block checking for public exposure:
* `attribute.dbsnapshot.attributes.attributes.sharedAccounts EXISTS` (Catches accounts it's explicitly shared with)
* OR `attribute.dbsnapshot.attributes.isPublicSnapshots == true` (Their standard check)
* OR `attribute.dbsnapshot.attributes.attributes.restorableBy EXISTS` (Catches a different API condition)
Set the action to alert or auto-remediate (good luck getting that approved in a real org). The real pitfall? This policy will fire constantly in any sane Dev environment. Prepare to drown in noise unless you build a massive exclusion list for your sandbox accounts, which of course, becomes a full-time maintenance job.
The takeaway? This "custom policy" capability is a checkbox feature. It's just flexible enough to make you think you can solve the problem, but so clunky and noisy that you'll question why you're not just running a simple, auditable script against your CSPM's own data export. But hey, you're already locked into the platform, so you might as well try to make it work.
—JP
If it's free, you're the product. If it's expensive, you're still the product.
Totally feel this. I was nodding along until you mentioned the JSON editor. That's the only way I've gotten anything precise to work too.
The visual builder lulls you into thinking it'll cover the logic, then you find the gaps. My team got bit by something similar with unattached volumes last quarter. The default policy looked fine, then an audit found a dozen it missed because of a status filter it didn't apply.
So, quick question for you on condition 2: when you check for `sharedAccounts EXISTS`, does that reliably flag both "all" public and shared-with-specific-account scenarios? I'm guessing it does, but I'm always paranoid about the API field names being slightly different.
You've nailed a really important nuance here. The default policies are great for broad awareness, but for true compliance or security-critical resources, you have to roll up your sleeves and build your own. It's a common gap I see across many SaaS security tools; they have to balance noise with coverage for a general audience.
Your point about using the JSON editor is key. The visual builder abstracts away the raw data model, which hides the exact field names and logic operators you need for precision. For others reading this, I'd recommend always starting with a small sample of resources in your actual environment and using the tool's discovery or resource view to see the exact attribute paths. That `sharedAccounts` field is a perfect example. Sometimes it's an empty array `[]` versus not existing, which can trip up the `EXISTS` check.
Thanks for sharing this specific methodology. It's exactly the kind of detailed, evidence-based approach that helps the whole community build better configurations. I'm curious if anyone has validated a similar pattern for the equivalent GCP or Azure resources?
Stay curious.