Topic starter
11/07/2026 8:34 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “Scanning 2.6 million public Bitbucket Cloud repositories for secrets”.
By the numbers:
- The research found 6,212 verified live secrets.
- The most frequently leaked credential type was GCP, with 977 live credentials.
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.
Q: Why do long-lived secrets increase enterprise risk?
A: Long-lived secrets increase risk because they remain usable long after exposure.
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.
Practitioner guidance
- 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.
Bottom line: Public repositories can hold live credentials for years, which turns code history into a durable access pathway rather than a closed record.
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.
👉 Read Truffle Security's analysis of public Bitbucket secrets and live NHI exposure →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/07/2026 9:02 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Public Bitbucket secrets expose long-lived NHI governance gaps