Scan your AWS S3 buckets for secrets

  Release Date: August 25, 2026

Nobody reviews a bucket. Yet, they're filled with database dumps, CI logs, Terraform state, container images, notebooks, support exports, and the occasional .env swept up by a backup script. No format, no schema, no owner, no retention. A single bucket can hold ten years of it, and one forgotten object can carry a credential that never existed in code, which makes it invisible to every scanner you run today.

GitGuardian now scans your AWS S3 buckets with the same detection engine and incident workflow as your repositories, including the objects nested inside archives.

What does this mean for you?

• Secrets no code scanner can reach: an access key in a CI log, a .env swept into a nightly backup, a token in Terraform state, a connection string in a support export. GitGuardian opens archives too, so a credential buried in a tar.gz still surfaces as an incident.
• No long-lived AWS keys to hand over: GitGuardian assumes a read-only IAM role in your own account through OIDC. You create the role, you scope it, and you can revoke it at any time.
• You choose which buckets are monitored: start with the buckets that scare you, backups and log archives, then widen. Select buckets individually in the integration settings and assign them to teams like any other source.
• Cost stays under your control: scanning is limited to the integration's region and to the S3 Standard storage class by default. Cross-region scanning and other storage classes, which can incur retrieval and transfer charges, are both opt-in.
• Nothing new to learn: secrets found in objects, and in the archives containing them, become regular incidents with the severity, validity, playbooks, and notifications you use today.

Why is this important?

Object storage is where content goes to be forgotten, and it's not an attacker's blind spot: it is a step in their playbook. Our research on Crimson Collective, ShinyHunters, and Scattered Lapsus$ Hunters and the Sisense breach shows the same pattern again and again. One leaked credential gets them in. They then enumerate databases, and storage, including buckets, snapshot what they find, and stage exfiltration in S3 buckets inside the victim's own account. Valid secrets lead to more valid secrets: the bucket holding a production database dump usually holds the connection string too.

The exposure is measurable. 28% of the secret incidents we detect originate entirely outside source code repositories, and those leaks are 13% more likely to be critical than code-only ones (State of Secrets Sprawl 2026. One broad s3:GetObject grant, one stale read-only key, one bucket policy nobody has read since 2021, and the whole archive is readable at once.

You cannot remediate what you can't see. This is how you get the full picture.

Scanning is on demand at this stage: you trigger a historical scan on the buckets you select, and recurrent scanning of new and modified objects is coming soon.

Get Started Today!

Setup takes three steps: create the OIDC provider and read-only IAM role in AWS, and register the account ID and role name in GitGuardian. Then start with the backlog: trigger a historical scan on critical buckets you select. Recurrent scanning of new and modified objects is coming soon.

Integrate AWS S3 | Manage your monitored perimeter

Fixes

• Incidents: Resolved an issue where certain invalid incidents were not ignored by the corresponding playbook filter.
• Sources:
  • Fixed an issue where some scan statuses were missing from the pygitguardian Python client library and from the API documentation.
  • Resolved a regression where Jira Cloud recurrent scans could fail on multi-page issue listings, preventing affected sources from completing their scans.
  • Fixed an issue where an integration could remain out of sync after a GitHub outage, and improved health verification for monitored sources.