Notifications
Clear all
Topic starter
11/07/2026 8:23 pm
TL;DR: A scan of roughly 5.6 million public GitLab repositories found 17,430 verified live secrets, 406 GitLab keys in GitLab itself, and a higher secret density than Bitbucket, according to TruffleHog research. The result shows that discovery at scale is useful, but governance fails when credentials outlive the systems and workflows that created them.
NHIMG editorial — based on content published by TruffleHog: Scanning 5.6 million public GitLab repositories for secrets
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
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 secrets in public repositories remain a major identity risk?
A: Public repositories combine broad visibility with long-lived history, so one mistake can create an exposure that persists across forks and cached copies.
Q: How can security teams tell whether secret scanning is actually working?
A: Look at how many findings are validated, revoked, and closed within a defined service-level target.
Practitioner guidance
- Bind secret scanning to immediate invalidation workflows Route every verified leak to the owning system so the credential is revoked or rotated before it can be reused.
- Separate repository access from credential custody Do not allow build, deploy, or SaaS credentials to live in the same environment where source code is authored and reviewed.
- Treat Git history as a credential archive Assume old commits, forks, and mirrors may still expose secrets even after a file is deleted.
What's in the full report
TruffleHog's full article covers the operational detail this post intentionally leaves for the source:
- The repository scanning workflow used to enumerate 5.6 million public GitLab projects at scale.
- The Lambda and SQS architecture behind the 24-hour scanning process and how it avoided duplicate work.
- The triage workflow for identifying disclosure paths across 2,800+ organisations and 120+ remediations.
- The platform-locality comparison between GitLab and Bitbucket secret patterns, with the underlying counts.
👉 Read TruffleHog's analysis of secrets exposed across 5.6 million GitLab repositories →
GitLab secret sprawl: what identity teams need to change?
Explore further
11/07/2026 8:53 pm
Standing secret risk is a lifecycle failure, not a detection failure. The article shows that thousands of valid secrets can still be found in public repositories even when scanning is mature. That means the broken premise is that discovery alone meaningfully reduces exposure. In reality, a secret is governed only when it is revoked, reissued, and traced back to the owning service. Practitioners should treat leaked credentials as unmanaged NHI assets until the lifecycle is closed.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
A question worth separating out:
Q: Who should be accountable when a leaked secret affects multiple SaaS systems?
A: Accountability should sit with the service owner and the platform owner together, because the leak path and the remediation path are split. Security teams can coordinate, but only the owners of the credential and the destination system can revoke access, confirm scope, and prevent recurrence.
👉 Read our full editorial: GitLab secret sprawl exposes why credential governance fails
