TL;DR: Truffle Security reports that scanning 2,636,562 public Bitbucket Cloud repositories surfaced 6,212 verified live secrets, including 977 GCP credentials, 247 Atlassian-related credentials, and a live AWS key committed 12 years ago. Exposure discovery at that scale still leaves NHI governance dependent on revocation, inventory, and lifecycle ownership rather than scan results alone.
At a glance
What this is: This research scanned 2.6 million public Bitbucket Cloud repositories and found 6,212 verified live secrets, with especially high volumes in cloud and SaaS credentials.
Why it matters: It matters because IAM and NHI teams cannot treat secret scanning as the control outcome; exposed credentials still need ownership, rotation, revocation, and offboarding discipline to prevent persistent access.
By the numbers:
- The research found 6,212 verified live secrets.
- The most frequently leaked credential type was GCP, with 977 live credentials.
- The oldest live AWS key had been committed 12 years ago, in June 2013.
👉 Read Truffle Security's analysis of public Bitbucket secrets and live NHI exposure
Context
Bitbucket repositories can hide secrets in long commit histories, which makes exposed credentials harder to spot and easier to leave active for years. In this case, the problem is not simply secret discovery but the governance gap between finding a credential and proving it has been revoked, rotated, or owned.
For IAM and NHI programmes, the important question is whether the organisation can connect a leaked secret back to an accountable owner and a lifecycle state. Without that chain, scan results create visibility but not control, especially when public code, SaaS tokens, and cloud keys are involved.
The article also shows why Bitbucket deserves the same governance attention as better-monitored code platforms. Public repositories remain a durable source of credential exposure, and the age of the leaked secrets suggests many teams still lack reliable offboarding and rotation discipline.
Key questions
Q: What breaks when a secret is deleted from code but not revoked?
A: The exposure remains active because repository cleanup does not remove standing privilege. Anyone who found the secret before deletion can still authenticate until the backing service invalidates it. That is why leak response must include revocation, rotation, and confirmation that the token no longer works, not just removal from the file.
Q: Why do long-lived secrets increase enterprise risk?
A: Long-lived secrets increase risk because they remain usable long after exposure. If a key, token or certificate is stolen, the attacker can keep returning until the credential expires or is revoked. That persistence makes detection less useful unless rotation and expiration are enforced automatically.
Q: How should security teams prioritise leaked credentials in developer environments at scale?
A: Security teams should rank credentials by exposure path, privilege level, and likely attacker value, not by raw count alone. LLM-assisted triage can help identify the secrets that matter most, especially when scans surface large volumes of low-risk findings. The goal is to focus remediation on credentials that could enable account takeover, data access, or lateral movement.
Q: How do security teams prevent repository scanning from becoming false assurance?
A: They should tie every finding to an owner, a rotation or revocation decision, and a closure check that confirms the credential no longer works. If the programme cannot prove those three things, scanning has produced visibility but not control.
Technical breakdown
Why secrets persist in public Git history
Git preserves commit history by design, so a secret removed from the latest version can still remain recoverable in earlier commits, branches, or tags. That creates a time gap between exposure and remediation, especially when repositories are public and can be scanned at scale. Detection tooling can enumerate live credentials, but it cannot infer whether a secret has already been rotated, whether downstream integrations still depend on it, or whether the owner even knows it exists. The core technical problem is persistence, not discovery.
Practical implication: treat repository history as part of the attack surface and not just the current file tree.
Why live cloud and SaaS keys create governance debt
A live key is dangerous because it is an executable credential, not evidence of exposure alone. Cloud API keys, SaaS tokens, and service credentials can often be used immediately if permissions remain intact, which means the security issue depends on scope, not just presence. When credentials are embedded in code or config, they often bypass normal lifecycle controls such as provisioning, ownership review, and offboarding. That leaves organisations with a credential that exists technically, works operationally, and is often invisible to identity governance processes.
Practical implication: track exposed secrets as managed identities with owners, scopes, and expiry, not as isolated findings.
Why age matters more than teams assume
The presence of a live AWS key committed 12 years ago shows that exposure age and exploitation age are not the same thing. A secret can remain valid for years if rotation never happens and if no control continuously tests whether it is still live. That is why long-lived secrets are a governance problem as much as a security problem: they represent standing access with no reliable lifecycle boundary. In practice, the longer a secret survives, the more systems it can silently accumulate around it.
Practical implication: use secret age as a risk signal and force rotation or revocation review when exposure predates current governance records.
Threat narrative
Attacker objective: The attacker objective is to reuse exposed credentials to reach the connected SaaS or cloud service with valid access before the owner rotates or revokes the secret.
- Entry begins when a public repository exposes a credential in code, config, or commit history that an external party can harvest without authenticating to the owning system.
- Credential access occurs when the exposed secret is still live and can be used against the connected cloud, SaaS, or API service.
- Impact follows when the credential grants access to data, admin functions, integrations, or billing workflows before the organisation detects and revokes it.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- Cloudflare Thanksgiving breach 2023: One service token and three service accounts left unrotated after the Okta breach gave a nation-state attacker access to Cloudflare's Atlassian systems.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Public code exposure is only the first half of the problem: the real governance failure begins when discovery is not tied to ownership, revocation, and lifecycle state. A repository scan can tell you that a secret exists, but it cannot tell you who is accountable for removing access or whether downstream systems still trust it. In NHI terms, exposure without lifecycle closure creates persistent identity debt. The practitioner conclusion is simple: finding secrets is a detection function, but governing them is an identity lifecycle function.
Long-lived secrets are a standing-access problem, not a hygiene problem: a credential that remains valid for years behaves like untracked privilege. The article's oldest live AWS key shows that some secrets survive longer than many governance programmes keep records. That means inventory, rotation, and offboarding must be treated as a single control chain rather than separate tasks. The practitioner conclusion is to measure how much access in the estate is still effectively permanent.
Bitbucket is a reminder that platform focus creates blind spots: security attention tends to cluster around the most visible code platforms, while less-scrutinised repositories can accumulate equally dangerous secrets. That asymmetry matters because attackers do not need the noisiest platform, only the one where monitoring, scanning, and response lag behind. The practitioner conclusion is to govern every public repository source with the same lifecycle expectations.
Identity blast radius should be the organising concept for leaked secrets: a leaked credential is not defined by where it was found, but by what it can reach. Identity blast radius: the set of systems, data, and administrative paths reachable through one still-valid secret. This article shows that cloud, SaaS, and collaboration tokens can all expand blast radius far beyond the repository itself. The practitioner conclusion is to rank exposures by reachable privilege, not by file count alone.
Secret scanning without revocation discipline creates false confidence: organisations often count findings as progress even when no lifecycle action follows. That assumption fails because a detected secret may still be live, still privileged, and still usable long after the scanner has moved on. The implication is that governance needs a closure loop, not just a detection feed. The practitioner conclusion is to prove every secret finding has an owner, a status, and a completed response.
What this signals
Identity blast radius: exposed secrets should be assessed by what they can reach, not by how many files they appear in. That shift matters because a single live token can expose cloud consoles, SaaS data, or automation paths even when the repository itself looks low risk.
Repository exposure becomes a lifecycle problem the moment a secret remains valid after discovery. Teams that treat scanning as the end state will continue to miss the revocation and ownership work required to actually remove access.
For practitioners
- Map exposed secrets to accountable owners Require every secret finding to resolve to a system owner, a business owner, and a documented remediation status so exposure does not sit in a generic backlog.
- Revoke or rotate live credentials immediately If a secret is confirmed live, rotate or revoke it before treating the finding as closed, and verify that dependent integrations still function with the replacement credential.
- Search commit history, not just current files Scan branches, tags, and prior commits because secrets removed from the latest revision can still remain recoverable in Git history.
- Prioritise high-impact credential types Triage cloud keys, SaaS tokens, and product-specific credentials ahead of low-scope secrets because they can expand blast radius quickly if still live.
- Create offboarding rules for stale secrets Treat any credential that predates current governance records as a lifecycle exception and force explicit review for ownership, scope, and continued need.
Key takeaways
- Public repositories can hold live credentials for years, which turns code history into a durable access pathway rather than a closed record.
- The scale of the Bitbucket scan shows that secret exposure is not a rare edge case but a routine governance problem across cloud and SaaS identities.
- The control gap is closure, not discovery: organisations need ownership, revocation, and lifecycle tracking to make exposed secrets stop working.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article is fundamentally about live secrets exposed in public repositories. |
| NHI-07 — Long-Lived Secrets | The research shows credentials remaining valid for years after exposure. | |
| Recommendation — Scan repositories for secret leakage and revoke any live credential that is discovered. Reduce the lifetime of exposed credentials and enforce rotation on any secret that outlives its expected window. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Live secrets require lifecycle management, rotation, and revocation controls. |
| Recommendation — Apply authenticator management controls to rotate, revoke, and track exposed machine credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Leaked secrets become harmful when permissions and entitlements are still active. |
| Recommendation — Review and constrain access permissions tied to exposed secrets before closing the incident. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The threat pattern is reuse of exposed credentials for unauthorized access. |
| Recommendation — Map exposed-secret findings to credential access and prioritise the credentials most likely to enable reuse. | ||
Key terms
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
- Long-Lived Secret: A long-lived secret is a credential, token, API key, or certificate that remains valid for an extended period without frequent renewal. In NHI environments, it creates durable exposure because one leaked secret can keep granting access long after the original use case has changed.
- Credential Revocation: Credential revocation is the process of disabling a secret, token, or key so it can no longer authenticate or authorize action. It is the operational half of detection, because exposed credentials remain dangerous until they are invalidated and replaced across every dependent system.
What's in the full report
Truffle Security's full article covers the operational detail this post intentionally leaves for the source:
- The exact scanning approach used to enumerate 2,636,562 public Bitbucket Cloud repositories at scale.
- The distribution of leaked credential types, including cloud, SaaS, and Atlassian-related secrets.
- The automation pattern used to run large-scale TruffleHog scans in AWS Lambda.
- The disclosure and bounty workflow used to validate, report, and revoke live secrets.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org