ShutterGap: Why Daily CSPM Scans Miss 99% of AWS Snapshot Leaks

Anyone who has run an on-call rotation for an AWS estate knows the quiet dread of the words "public snapshot." Aryon Security's new ShutterGap research says the problem is worse than the dashboards suggest: 20% of publicly shared RDS snapshots are visible for less than two minutes, and 99% of deleted RDS and DocumentDB snapshots disappear within 30 minutes of creation. If your CSPM runs on a daily cycle, it is effectively blind to the majority of real exposure events.

The Numbers

The core finding, as CyberSecurityNews reported, is a timing mismatch between how fast AWS resources flicker into public view and how slowly most security tooling checks for them. In a single 90-minute observation window in us-east-1, the count of publicly available RDS snapshots changed 12 times. Six appeared. Six went away. That is one state change roughly every seven and a half minutes, in one region, for one resource type.

Now overlay a daily scan cadence. If your CSPM samples once every 24 hours, and 20% of exposures live under two minutes, you are missing them with a probability that rounds to certainty. Even the 30-minute tail, where 99% of deleted snapshots have already vanished, is well inside the noise floor of most posture-management schedules. Production incidents I've seen in fintech typically follow this shape: the audit log shows the misconfiguration existed, the scanner shows nothing, and the postmortem argues about whether a tree fell in the forest.

Aryon didn't stop at counting flickers. They pulled a sample of 24 publicly shared RDS snapshots, restored them, and looked at what was inside. The restored databases contained AWS account identifiers, email addresses, potential secrets, patterns consistent with private keys, and indicators of financial data. They stopped extraction at that point, which is the responsible move, but the signal is unambiguous: these ephemeral exposures aren't empty test fixtures. They contain the material an attacker actually wants.

The monitored surface went beyond RDS. Aryon also watched Amazon DocumentDB snapshots, Amazon Machine Images, and AWS Systems Manager documents, all resource types that support public sharing by design. None of this is an AWS vulnerability. It is customer configuration error, and AWS has told customers for years not to keep sensitive data in publicly shareable resources. The problem is that a modern platform team ships hundreds of infrastructure changes a day. Some fraction will be wrong. The question is whether your controls catch them in seconds or in hours.

What's Actually New

The concept of misconfigured public snapshots isn't new. What's new is the empirical measurement of exposure duration and the operational conclusion that falls out of it. For years the industry has been sold on posture management as the answer to cloud misconfiguration. Buy the scanner, wire it into Slack, close the tickets. ShutterGap breaks that mental model by showing that the exploitable window is smaller than the scanner's clock resolution.

The second genuinely new detail is the attack economics. An attacker doesn't need to exfiltrate the database during the window. They just need to issue a snapshot copy into their own AWS account. Once the copy lands, the original owner can revoke public access all they want; the data is gone. That reframes ShutterGap from a race condition into a persistence primitive. Two minutes of exposure equals permanent compromise, if someone is watching.

And someone is watching. Public AWS resource inventories are trivially enumerable. Any competent adversary can run a continuous poller against the same APIs Aryon used and copy anything interesting the moment it appears. The cost to run that infrastructure is trivial compared to the value of a single production RDS snapshot with credentials in it.

My take: this shifts the CSPM conversation from "how many findings did we close this week" to "what did we prevent from ever being creatable in the first place." The Aryon recommendations lean hard on Service Control Policies, and that is the correct instinct. SCPs are boring, they don't generate pretty dashboards, and they work. Blocking snapshot-sharing attribute changes, maintaining the block on public AMI sharing, and preventing SSM document public sharing are all one-time policy writes that neutralize entire classes of the finding forever. Compare that to paying an analyst to triage the same recurring alert 40 times a quarter.

What's Priced In for Security Teams

Most senior platform leads already suspected daily scans were insufficient. That part is priced in. Anyone who has worked a serious cloud estate has watched a developer flip a bucket public at 2pm and flip it back at 2:04pm, and understood in their gut that no scanner would ever see it. What wasn't priced in is the scale. Six new public RDS snapshots in 90 minutes in one region is not one developer making a mistake. It is a systemic pattern of behavior, likely tied to snapshot copy workflows, cross-account sharing scripts, and disaster-recovery testing that briefly toggles public access as a shortcut.

Also priced in: the idea that prevention beats detection in cloud security. Everyone says this at conferences. What's new is a concrete measurement that quantifies exactly how badly detection loses when the exposure window is under two minutes. That number is a budget-justification lever. If you are a CTO and your cloud security spend is 90% detection tooling and 10% preventive guardrails, this research is the memo you send to flip the ratio.

Not priced in: the CloudTrail forensics angle. Reviewing CloudTrail for RDS ModifyDBSnapshotAttribute, EC2 ModifyImageAttribute, and SSM ModifyDocumentPermission events is standard advice, but most teams I've worked with only look at those logs after an incident. Running a continuous query against them, with alerting when the attribute change makes a resource public, closes the visibility gap without waiting for the next CSPM scan. It is essentially free if you already ship CloudTrail to a SIEM. The uncomfortable read: most orgs don't, or they ship it and never query it.

Contrarian View

The consensus takeaway will be "buy a real-time cloud detection product." I'd push back. The contrarian read is that ShutterGap is not really a detection problem. It is an IAM permissions problem masquerading as a monitoring problem. If your developers can't call ModifyDBSnapshotAttribute with a public flag in the first place, the flicker never happens. No scanner needed.

The reason organizations don't do this is cultural, not technical. Locking down snapshot sharing via SCPs means someone has to review the exception requests when a legitimate cross-account share is needed. That is friction, and platform teams optimize against friction. So the industry buys another detection product instead, because a product purchase is a one-time political fight and a permissions boundary is a permanent one.

There is also a reasonable argument that the 24-snapshot sample is small. Aryon stopped extraction responsibly, which is right, but it means the "significant business information" claim rests on a narrow base. A skeptic could argue most flickered snapshots are empty test fixtures. Possible. But if even a single-digit percentage carry real secrets, the expected loss per year on a large estate is enormous. You don't need the base rate to be high for the risk to justify the fix.

Key Takeaways

• Daily CSPM scans cannot see ShutterGap. With 20% of public RDS snapshots exposed under two minutes and 99% gone in 30 minutes, a 24-hour cadence catches almost nothing.
• Prevention via SCP is the real fix. Block ModifyDBSnapshotAttribute for public sharing, keep public AMI sharing blocked, and prevent SSM document public sharing at the org level. Do this once, sleep better forever.
• Treat exposure as permanent, not temporary. An attacker only needs seconds to issue a snapshot copy into their own account. Revoking public access after the fact does not undo the compromise.
• Wire CloudTrail into real-time alerting. Query for RDS ModifyDBSnapshotAttribute, EC2 ModifyImageAttribute, and SSM ModifyDocumentPermission events as they happen, not during the next quarterly review.
• Require encryption on new RDS instances. It won't stop the exposure, but it raises the cost of restoring a copied snapshot in a foreign account and buys forensic time.