GitLab secret sprawl exposes why credential governance fails

At a glance

What this is: A large-scale scan of public GitLab repositories found 17,430 verified live secrets and showed that secrets cluster where developers work, creating a dense, persistent exposure problem.

Why it matters: IAM, NHI, and secrets teams need to treat public code, collaboration systems, and revocation workflows as one control plane because leakage, discovery, and remediation are linked.

By the numbers:

• 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.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read TruffleHog's analysis of secrets exposed across 5.6 million GitLab repositories

Context

Public code hosting platforms remain a durable secrets exposure surface because credentials are often embedded in commit history, copied across repositories, and left valid long after their original purpose ends. In NHI governance terms, this is not just an engineering hygiene issue. It is a lifecycle failure for secrets, tokens, and cloud credentials that were never designed to self-expire.

The GitLab scan shows the scale of the problem: exposure can be discovered at internet scale, but remediation still depends on ownership, triage, and revocation discipline. The article also points to a pattern identity teams should recognise immediately. When credentials are colocated with development activity, the same platform that enables delivery also becomes the most likely place for secret leakage.

Technical detection alone does not close the loop. If a leaked credential still has standing access, the control gap is not visibility but the absence of fast, reliable offboarding for non-human identities and secrets.

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 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. The risk is highest when the credential still has standing access. In that case, repository disclosure becomes an authentication problem, not merely a code review issue.

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. Detection counts alone can be misleading if the same secrets remain usable. The strongest signal is shrinking time from discovery to invalidation, especially for credentials with cloud or SaaS access.

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.

Technical breakdown

Why public Git repositories become long-lived secret stores

Git records history immutably, which means a secret committed once can survive in old revisions, forks, mirrors, and derived branches even after the visible file is cleaned up. That makes deletion a weak control unless the secret is also revoked. In NHI terms, the repository becomes an unintended credential archive, and the exposure window is determined by secret lifetime, not by the day it was first detected.

Practical implication: treat repository history as a credential exposure source and pair discovery with revocation, not cleanup alone.

What platform-locality means for secrets governance

Platform-locality is the tendency for credentials to leak in the same ecosystem they authenticate against, such as GitLab tokens appearing inside GitLab repositories. This is more than coincidence. It reflects developer workflow, reuse patterns, and trust assumptions that encourage operational convenience over segregation. Once a credential is stored beside the code that uses it, compromise becomes both easier to introduce and harder to notice.

Practical implication: separate build, deploy, and hosting credentials from the environments where they are authored and reviewed.

Why scanning without revocation leaves standing risk

Secret scanning identifies exposure, but it does not remove privilege. A valid token, API key, or cloud credential remains usable until the owning system revokes or rotates it. This is why large scans routinely produce backlogs of open findings that outlive the original commit. For identity teams, the real control is lifecycle enforcement across secrets, not detection volume.

Practical implication: define a revocation SLA for every secret class and measure time-to-invalidate, not just time-to-detect.

Threat narrative

Attacker objective: The attacker seeks durable authenticated access to SaaS, cloud, or developer systems using credentials discovered in public repository history.

1. Entry occurs when a valid secret is committed into a public Git repository or exposed through repository history, making it reachable to anyone scanning the platform.
2. Escalation follows when the leaked credential is still active, allowing the holder to authenticate directly to cloud services, SaaS consoles, or internal APIs with standing privilege.
3. Impact comes from account takeover, data access, or environment manipulation before the secret is revoked, which can happen long after the exposure was first created.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• 17,000+ Secrets Exposed in Public GitLab Repositories — Over 17,000 secrets including API keys and tokens exposed in public GitLab Cloud repositories.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Platform-locality creates an identity governance blind spot. The finding that GitLab credentials frequently appear inside GitLab itself is a strong signal that identity controls are being shaped by developer convenience instead of separation of duties. This is not just about source control hygiene. It shows that the same platform often holds the secret, the workload, and the audit trail, which collapses accountability if governance is not externalised. Practitioners should reassess where credentials are allowed to live at all.

Secret scanning becomes operationally meaningful only when paired with revocation automation. Large-scale detection creates a backlog unless remediation is bound to the finding workflow. The article's disclosure effort shows how much manual triage is still required across thousands of domains, which is a reminder that governance at scale depends on ownership mapping and revocation speed. Practitioners should measure whether their secret response process can invalidate access faster than the exposure can be exploited.

Git history turns every leaked secret into a persistent identity event. Once a credential lands in commit history, the exposure can outlive the original branch, repository owner, and deployment context. That means secrets need to be governed as identities with a lifecycle, not as one-time configuration values. Practitioners should align secrets governance with NHI lifecycle control, not with code review alone.

Named concept, platform-locality of secrets, should now be treated as a governance signal. When the platform that hosts code also becomes the most common place for its credentials to leak, the control failure is systemic. The implication is that identity teams must evaluate repository, pipeline, and secret ownership together, because the boundary between code storage and credential custody has already blurred. Practitioners should redesign policy around that coupled risk.

From our research:

• 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.
• Use the Guide to the Secret Sprawl Challenge to build revocation workflows that match the speed of modern leakage patterns.

What this signals

With 64% of valid secrets leaked in 2022 still exploitable today, the governance problem is not discovery volume but the absence of automated revocation and ownership closure. That is why secret exposure should now be tracked as an identity lifecycle event, not just a security finding.

Platform-locality of secrets: credentials often leak in the same ecosystem where they are meant to operate, which means repository controls, pipeline controls, and identity controls cannot be managed in separate silos. Practitioners should expect more leakage from developer tooling as AI-assisted and multi-platform workflows increase.

The practical next step is to connect source control monitoring with lifecycle enforcement, supported by source-of-truth ownership and fast offboarding paths. The more repositories and automation expand, the more your programme needs one revocation model across code, workloads, and secrets.

For practitioners

• 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. Track time-to-invalidate as the primary success metric, not scan volume. Use the revocation step to close the exposure window in the same incident record.
• 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. Put issuance, storage, and use behind distinct controls so a repository leak does not automatically become an authentication event.
• Treat Git history as a credential archive Assume old commits, forks, and mirrors may still expose secrets even after a file is deleted. Search historical revisions during incident response and confirm that revocation covered every discovered secret class, including tokens, API keys, and certificates.
• Map every secret to an accountable owner Build ownership records that connect each credential to a service, team, and rotation path. Without that mapping, large-scale disclosure becomes a triage exercise with no reliable offboarding path for exposed non-human identities.

Key takeaways

• A public repository can become a persistent credential archive when secrets are committed into history and never revoked.
• The scale of verified live secrets in GitLab shows that detection is useful only when ownership and invalidation keep pace.
• Identity teams should treat leaked secrets as lifecycle failures across NHI, pipeline, and SaaS access, not as isolated code mistakes.

Key terms

• Standing Secret: A standing secret is a token, key, or certificate that remains valid until someone explicitly revokes or rotates it. In practice, it creates lasting access rather than temporary access, which is why leaked credentials remain dangerous long after the original commit or disclosure.
• Platform-locality: Platform-locality describes the tendency for credentials to leak in the same system they are meant to access, such as GitLab secrets appearing in GitLab repositories. It reflects workflow design, credential reuse, and ownership gaps that make leakage more likely and remediation harder.
• Secret Revocation: Secret revocation is the process of invalidating a credential so it can no longer authenticate, even if it has been copied elsewhere. It is the control that turns exposure discovery into risk reduction, because deletion from code alone does not remove standing privilege.
• Credential Lifecycle: Credential lifecycle is the full path from issuance to use, rotation, revocation, and retirement. For non-human identities, it matters because a secret is only safe while its lifecycle is actively managed, and exposure without offboarding leaves access alive beyond intent.

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.

👉 TruffleHog's full post includes the scan architecture, disclosure workflow, and platform-locality findings.

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.