Public Bitbucket secrets expose long-lived NHI governance gaps

At a glance

What this is: This research scanned all public Bitbucket Cloud repositories and found more than 6,000 verified live secrets, showing how exposed credentials can persist for years across enterprise code hosting.

Why it matters: It matters because IAM, PAM, and NHI programmes still fail when secrets are buried in source history, remain unrotated, or are not centrally governed across code platforms and SaaS estates.

By the numbers:

• 36 hours
• Only 44% of organisations are currently using a dedicated secrets management system.

👉 Read TruffleHog's analysis of 2.6 million public Bitbucket repositories for secrets

Context

Public source control is now part of the identity attack surface because secrets committed to repositories often outlive the intent behind them. In practice, a leaked credential in Git history is an NHI problem first, because the secret, token, or key becomes a reusable identity that can be abused outside any normal access review cycle.

This research shows that public Bitbucket Cloud remains a large and searchable reservoir of live secrets, including cloud keys, SaaS tokens, and product credentials. The pattern is not unusual for modern code platforms, but the scale is still a reminder that discovery, revocation, and ownership are rarely aligned in real organisations.

Key questions

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. A deleted file does not remove the credential from every clone or cache. The real failure is not the commit itself, but the absence of fast revocation, ownership, and follow-up verification after discovery.

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. That makes the credential a high-value NHI because it can act independently against cloud APIs and SaaS platforms. The risk grows when the same secret can unlock multiple downstream services.

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. If live secrets keep showing up in code repositories, or if teams cannot measure time to revoke, the programme is not controlling exposure. Effectiveness is visible in reduced dwell time and fewer verified live secrets.

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.

Technical breakdown

Why Git history turns secrets into durable identities

Git preserves object history, which means a secret committed once can remain recoverable long after a pull request is merged or a file is deleted. That makes source control different from ordinary file storage. Secret scanners work by matching credential patterns, validating whether a discovered token is live, and then triaging impact by provider, scope, and repository context. The important point is that the credential itself becomes the identity, not the file containing it. When teams lack clean ownership and rotation, old commits keep producing new exposure.

Practical implication: treat repository history as a live identity surface and scan it continuously, not only on new commits.

Why public repository scanning finds high-value SaaS and cloud tokens

The research found live credentials for GCP, AWS, SendGrid, MongoDB, Atlassian products, Azure Storage, Stripe, Slack, and Twilio. That matters because these secrets often provide direct service-to-service access with far more privilege than a human session token. In NHI terms, a single token can represent access to multiple downstream systems, and exposure in one public repository can cascade into SaaS compromise, cloud abuse, or operational disruption. The breadth of providers also shows that secrets sprawl is not a single-platform problem.

Practical implication: inventory secrets by provider and downstream reach, then prioritise the tokens with the widest SaaS and cloud blast radius.

How verified secret discovery changes remediation priority

A verified live secret is more operationally urgent than a generic pattern match because it proves the credential can still be used. That shifts the workflow from detection to containment, ownership, and revocation. The article also shows that some credentials remained live for years, which means age alone is not a reliable safety indicator. In governance terms, the weak point is not just exposure, but persistence without lifecycle closure. A secrets programme that cannot link discovery to revocation remains incomplete.

Practical implication: build a verified-secret response path that assigns ownership, revokes access, and confirms closure before the finding ages out.

Threat narrative

Attacker objective: The attacker objective is to turn exposed repository secrets into usable access against cloud and SaaS systems without needing further exploitation.

1. Entry occurs when a secret is committed into a public Bitbucket repository and becomes discoverable through source code history.
2. Escalation follows when the credential remains live, allowing abuse of SaaS or cloud access that was never meant to be publicly reachable.
3. Impact is achieved through unauthorized use of the token or key, which can expose data, trigger service abuse, or open the door to broader environment compromise.

Breaches seen in the wild

• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 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.

Secret discovery without revocation is governance theatre. Finding a live secret only matters if the organisation can identify the owner, determine the system it unlocks, and revoke it quickly enough to matter. The research found secrets that remained live for years, which means many environments still rely on hope rather than lifecycle enforcement. That is exactly where OWASP-NHI and NIST CSF alignment should focus: ownership, containment, and evidence of closure.

Secrets sprawl creates identity blast radius across SaaS and cloud services. The mix of GCP, AWS, Atlassian, SendGrid, Azure Storage, Slack, Twilio, and other tokens shows that one repository can expose many downstream systems at once. That is not a narrow credential problem, it is an ecosystem governance problem. Identity blast radius: the amount of downstream access a single leaked credential can unlock across interconnected platforms, and it should be the unit of prioritisation for remediation.

Public code remains an underweighted control plane in NHI programmes. The fact that established enterprise software still yields live secrets at scale means many organisations have not connected source control governance to identity governance. Code scanning, secrets management, and access review are still too often run as separate disciplines. Practitioners should fold repository exposure into their NHI risk model and measure how quickly discovered secrets are tied to owners and removed.

Atlassian-related credential leakage is a useful proxy for internal trust assumptions. The research found 247 valid Atlassian credentials, including high-severity findings, which suggests organisations often mirror identity trust across tools without isolating blast radius. When product suites share identity assumptions, a leaked token in one system can become a pivot into others. Teams should assume suite-level compromise paths exist until proven otherwise.

From our research:

• 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.
• For a broader control model, compare this with Guide to the Secret Sprawl Challenge for the remediation patterns that prevent leaked credentials from becoming lasting access paths.

What this signals

Secrets sprawl is becoming a governance metric, not just a detection problem. When 88.5% of organisations say non-human IAM is behind human IAM, the implication is that repository leakage, token sprawl, and revocation lag are all symptoms of the same structural gap. Security teams should measure how quickly a discovered secret is tied to ownership and removed, because that is where the programme proves itself. For control alignment, map the workflow to OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0.

Identity blast radius should replace raw secret counts in executive reporting. A repository full of low-impact test keys is not the same as one token that reaches cloud control planes, messaging platforms, and billing systems. The better indicator is downstream reach, because that is what turns a leaked credential into a business event. Teams should build reporting around NIST SP 800-53 Rev 5 Security and Privacy Controls access and audit requirements, not just scan totals.

For practitioners

• 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. Add verified-secret workflows that classify provider, scope, and repository ownership before remediation begins.
• Tie every secret to a named owner and expiry path. Do not allow repository-discovered tokens to remain unattributed. Maintain ownership metadata, service dependency records, and a revocation path for each secret so containment can start immediately when a live credential is found.
• 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. Use blast radius to set response order instead of treating all secrets as equal.
• Separate developer convenience from identity governance. Remove the assumption that low-friction code workflows are safe for credential handling. Enforce pre-commit scanning, pull request checks, and secure secret injection so developers do not need to handle long-lived secrets in source at all.

Key takeaways

• Public repositories remain a live identity exposure surface because Git history preserves secrets long after developers think they are gone.
• The scale matters: more than 6,000 verified live secrets across 2.6 million public Bitbucket repositories shows this is systemic, not occasional.
• The control gap is lifecycle closure, not just discovery, so ownership, revocation, and blast-radius prioritisation must be part of the response.

Key terms

• Verified Live Secret: A verified live secret is a credential, token, or key that is not only detectable in code or logs, but also still valid when tested. It is more urgent than a pattern match because it represents usable access, not just exposure risk.
• Identity Blast Radius: Identity blast radius is the amount of downstream access a leaked or over-privileged credential can unlock across systems. In NHI governance, it is the practical measure of how much damage one secret can cause if it is discovered or abused.
• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials across code, pipelines, collaboration tools, and cloud services. It becomes a governance failure when organisations cannot inventory, assign ownership to, or revoke those secrets consistently across their lifecycle.

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

👉 The full TruffleHog post covers the scanning workflow, secret distribution, and disclosure outcomes in more detail.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.