The numbers
Truffle Security published research in August 2026 re-verifying 10,616 leaked AWS credential pairs pulled from public sources — git commit history, Hugging Face datasets, Docker images, package registries, and CI/CD logs — accumulated between August 2022 and August 2026. According to the report, about 88% of the tested credentials still authenticated successfully. Among the active corporate-linked keys, 526 were AWS root access keys, and 242 belonged to IAM users carrying the AdministratorAccess policy.
The broader dataset behind the sample was larger still: 64,024 unique AWS key pairs across 431,875 public findings, including over 10,000 root credentials. The report's most telling statistic isn't the leak count — public credential leaks are not new — it's the age distribution. The median leaked key was five years old, and the oldest dated back 17.4 years. Among a subset of 2,903 keys where access-key enumeration was possible, only 13.7% had a newer replacement key issued. In other words, the overwhelming majority of these credentials were never rotated after leaking, and in many cases were probably never rotated at all.
Why leaks stay active for years
The technical mechanism here isn't sophisticated — it's an absence of process. A key committed to a public repo, baked into a Docker image layer, or dumped into a CI log gets indexed by scanners (both defensive tools and attacker tooling) almost immediately after exposure. What determines the actual blast radius isn't whether the leak happens — leaks happen constantly, across every organization with more than a handful of engineers — it's how long the credential remains valid after exposure.
Three factors compound to keep a leaked key alive for years:
No automated revocation on exposure. Organizations that only discover a leak when a customer, researcher, or attacker reports it are already behind. GitHub's native secret scanning and push protection catch some leaks at commit time, but a key baked into a Docker image layer or dumped in application logs bypasses source-level scanning entirely.
No routine rotation baseline. If keys are only ever rotated in response to a known incident, and the incident detection rate is low, the rotation rate follows. A root key created five years ago and never rotated isn't unusual — it's the median case in this dataset.
Root keys and over-scoped IAM users in active use. 526 active root keys in a sample of this size is the more alarming number than the raw leak count. AWS has recommended against using root access keys for programmatic access for years; their continued presence suggests many organizations either never migrated off root keys for legacy tooling, or created them once for a one-off task and forgot to delete them.
What this changes for CI/CD practice
For teams running AWS workloads through CI/CD, the practical takeaways aren't novel, but this data is a good forcing function for actually implementing them:
Move to short-lived credentials via OIDC instead of long-lived access keys. GitHub Actions, GitLab CI, and most modern CI platforms support OpenID Connect federation with AWS, letting a pipeline assume an IAM role for the duration of a single run without ever storing a static key as a secret.
# GitHub Actions — OIDC-based AWS auth, no stored access key
permissions:
id-token: write
contents: read
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/ci-deploy-role
aws-region: ap-northeast-1
# No AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY secret exists to leakDelete root access keys entirely. AWS IAM allows disabling or deleting root access keys outright; day-to-day operations, including CI/CD, should never need them. If a legacy script still depends on a root key, that's a migration task, not a reason to keep the key active.
Run secret scanning on more than source code. Since a large share of these leaks came from Docker images, package registries, and CI/CD logs rather than git history alone, scanning needs to cover build artifacts, not just commits. Tools like TruffleHog, Gitleaks, or AWS's own IAM Access Analyzer can be wired into the build pipeline to fail a build when a credential pattern is detected in an image layer or log output.
Set a rotation SLA independent of incident detection. Even IAM users that must use long-lived keys for legacy reasons should have a maximum key age enforced — 90 days is a common baseline — with automated rotation or expiry, rather than relying on someone noticing the key is old.
A five-year-old key is a policy failure, not bad luck
The most useful framing from this research isn't "leaks happen" — every org's threat model already assumes that. It's that a leaked credential surviving five years unrotated indicates the absence of two things: automated exposure detection across build artifacts (not just source), and a rotation policy that doesn't depend on someone catching the leak manually.
For clients we work with on AWS infrastructure, the audit we're now recommending is narrow and mechanical: enumerate every IAM user and role with a long-lived access key, confirm none of them are root keys, check the last-rotated date against a 90-day policy, and move CI/CD authentication to OIDC role assumption wherever a static key currently sits in a secrets manager or, worse, a pipeline environment variable. None of this requires new tooling most teams don't already have access to — it requires treating credential rotation as a scheduled operational task rather than an incident response.