Notifications
Clear all
Topic starter
11/07/2026 8:34 pm
TL;DR: Scanning 2,636,562 public Bitbucket Cloud repositories surfaced 6,212 verified live secrets, including 977 GCP credentials, 247 Atlassian-related credentials, and even keys committed more than 12 years ago, according to TruffleHog's research. Long-lived exposed secrets show that discovery without lifecycle control leaves NHI governance exposed at internet scale.
NHIMG editorial — based on content published by TruffleHog: Scanning 2.6 million public Bitbucket Cloud repositories for secrets
By the numbers:
- Only 44% of organisations are currently using a dedicated secrets management system.
Questions worth separating out
Q: What breaks when secrets are committed to public repositories?
A: Public repository commits turn secrets into durable access paths because Git preserves history and public forks spread the exposure further.
Q: Why do leaked secrets create such a large identity risk for cloud and SaaS systems?
A: A leaked secret often represents direct machine access with no human login flow, no MFA challenge, and no contextual review.
Q: How can security teams tell whether secrets management is actually working?
A: Look for evidence that discovery leads to ownership, revocation, and confirmed closure within a controlled workflow.
Practitioner guidance
- Scan repository history, not just active branches. Run continuous secret detection across full Git history, pull requests, forks, and mirrors so deleted files and old commits are still covered.
- Tie every secret to a named owner and expiry path. Do not allow repository-discovered tokens to remain unattributed.
- Prioritise secrets by downstream blast radius. Rank leaked credentials by the number of cloud, SaaS, and collaboration systems they can reach, then revoke the widest-scope tokens first.
What's in the full report
TruffleHog's full article covers the operational detail this post intentionally leaves for the source:
- The Lambda and SQS scanning architecture used to process 2,636,562 Bitbucket repositories at scale
- The exact provider breakdown of the most frequently leaked credential types across public repositories
- The file-extension analysis that shows where live secrets tend to surface in source code
- The responsible disclosure and bounty workflow used to validate and revoke live credentials
👉 Read TruffleHog's analysis of 2.6 million public Bitbucket repositories for secrets →
Public Bitbucket secrets: what this means for IAM and NHI teams?
Explore further
11/07/2026 9:02 pm
Public repository secrets are a standing NHI problem, not a code hygiene issue. Once a credential lands in a public repository, it becomes a reusable non-human identity with no natural expiry unless lifecycle controls intervene. The scale here, more than 6,000 live secrets across 2.6 million repositories, shows that exposure is common enough to require governance, not ad hoc cleanup. Practitioners should treat source control as an NHI inventory source, not just a development tool.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to the 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to the 2024 Non-Human Identity Security Report.
A question worth separating out:
Q: Who is accountable when a leaked repository secret is used to access cloud services?
A: Accountability should sit with the system owner, the repository owner, and the team responsible for secrets lifecycle governance. If those roles are unclear, the organisation has already accepted a control gap. Frameworks such as NIST SP 800-53 and NIST CSF expect explicit access control, auditability, and incident response ownership.
👉 Read our full editorial: Public Bitbucket secrets expose long-lived NHI governance gaps
