Cloud Security Wire
AWS Azure GCP RSS
AWS Misconfiguration high

ShutterGap: Why Your CSPM Never Saw the RDS Snapshot That Went Public for 90 Seconds

Researchers found millions of AWS resources — RDS and DocumentDB snapshots, AMIs, SSM documents — flip to public and back within minutes, invisible to periodic CSPM scans. Here's how to catch these transient exposures with event-driven detection instead.

By Editorial Team · ·
#AWS#ShutterGap#RDS#DocumentDB#AMI#SSM#CSPM#misconfiguration#EventBridge#GuardDuty#data exposure
High Severity

This issue has been assessed as high severity. Review affected configurations immediately.

Cloud security posture tools work on a scan cycle: pull an inventory, check it against a ruleset, flag what’s wrong, repeat in an hour or a day. That model assumes a misconfiguration sits still long enough to get caught. Research published in late July 2026 by Aryon Security shows a large class of AWS exposures that don’t sit still — resources flip public, get discovered, and flip back private, all inside a window most CSPM and CNAPP tools never sample. The researchers named the pattern ShutterGap and measured it at scale: roughly 3.7 million short-lived public exposures a year across the resource types customers most often make public by accident — RDS and DocumentDB snapshots, Amazon Machine Images, and Systems Manager documents.

The numbers on duration are what make this a detection problem rather than just another misconfiguration statistic. Twenty percent of publicly shared RDS snapshots in the study were public for under two minutes, and 99% of deleted RDS and DocumentDB snapshots were removed within 30 minutes of being shared. That’s well inside the polling interval of most posture tools, and it’s exactly the window automated scrapers use to enumerate public snapshots the moment they appear. This isn’t an AWS vulnerability — it’s the predictable result of AWS’s public-sharing features being one API call away from any snapshot, image, or document, combined with humans and automation toggling that flag for a legitimate reason (sharing a snapshot with a partner account, testing an AMI) and forgetting, or a script, that flips it back before anyone notices it was ever wrong.

The API calls that create the exposure window

A handful of mutation calls are responsible for essentially all of this exposure class:

# RDS snapshot made public — the `all` value in Attribute is the tell
aws rds modify-db-snapshot-attribute \
  --db-snapshot-identifier my-snapshot \
  --attribute-name restore \
  --values-to-add all

# DocumentDB cluster snapshot, same pattern
aws docdb modify-db-cluster-snapshot-attribute \
  --db-cluster-snapshot-identifier my-cluster-snapshot \
  --attribute-name restore \
  --values-to-add all

# AMI made public
aws ec2 modify-image-attribute \
  --image-id ami-0123456789abcdef0 \
  --launch-permission "Add=[{Group=all}]"

# SSM document made public
aws ssm modify-document-permission \
  --name my-runbook \
  --permission-type Share \
  --account-ids-to-add all

Each of these appears in CloudTrail as a distinct, cheaply matched event — ModifyDBSnapshotAttribute, ModifyDBClusterSnapshotAttribute, ModifyImageAttribute, ModifyDocumentPermission — regardless of how long the public state persists afterward. That’s the leverage point: you don’t need to catch the resource while it’s public, you need to catch the API call that made it public.

Detecting the flip, not the state

Build an EventBridge rule off CloudTrail rather than relying on a scheduled inventory check:

{
  "source": ["aws.rds", "aws.docdb", "aws.ec2", "aws.ssm"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventName": [
      "ModifyDBSnapshotAttribute",
      "ModifyDBClusterSnapshotAttribute",
      "ModifyImageAttribute",
      "ModifyDocumentPermission"
    ]
  }
}

Route matches to a Lambda that inspects the request parameters for all / Group=all and, if found, immediately reverts the attribute and pages the owning team — auto-remediation measured in seconds beats a scan cycle measured in hours every time. GuardDuty also has native finding types worth enabling if you haven’t: Exfiltration:S3/... doesn’t cover snapshots, but PublicAccess findings under RDS and EC2 protection plans will flag the state if your remediation Lambda misses it.

Closing the door structurally

Detection buys you a fast response; it doesn’t stop the next accidental share. Two preventive controls remove the exposure window entirely:

  • Service control policy blocking public-sharing calls outright, if your org has no legitimate business need for cross-account snapshot or AMI sharing via the all principal:
{
  "Effect": "Deny",
  "Action": [
    "rds:ModifyDBSnapshotAttribute",
    "rds:ModifyDBClusterSnapshotAttribute",
    "ec2:ModifyImageAttribute"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": { "rds:AttributeName": "restore" }
  }
}

Scope this carefully — teams that legitimately share AMIs or snapshots cross-account need an exception path, not a blanket deny that pushes them toward workarounds.

  • AWS Config rules (rds-snapshots-public-prohibited, ec2-ami-public-restricted) with PERIODIC and CONFIGURATION_CHANGE triggers still matter as a backstop and compliance record, even though they inherit the same latency problem ShutterGap exploits — treat them as your audit trail, not your primary control.

The broader takeaway generalizes past these four API calls: any AWS resource type with a public-sharing attribute is a ShutterGap candidate, including EBS snapshot sharing, RAM resource shares, and Redshift snapshot sharing. If your detection strategy for public exposure is “scan and alert,” you’re structurally unable to catch the exposures that resolve themselves before the next scan runs. Event-driven detection on the mutation calls themselves is the only architecture that closes the gap.

← All Analysis Subscribe via RSS