Secrets sprawl is widening the non-human identity governance gap

At a glance

What this is: This is GitGuardian’s analysis of how secrets sprawl keeps widening the non-human identity governance gap, with leaked credentials remaining active long after exposure.

Why it matters: It matters because IAM and NHI programmes cannot rely on detection alone when exposed credentials, tokens, and API keys can remain valid and exploitable for months or years.

By the numbers:

• 70% of the secrets leaked in 2022 are still valid today.
• 35% of all customers’ private repositories scanned contained at least one plaintext secret.

👉 Read GitGuardian’s State of Secrets Sprawl 2025 report on NHI governance risks

Context

Secrets sprawl is the steady spread of credentials, tokens, keys, and certificates across code, collaboration tools, build systems, and cloud services. In this article, GitGuardian argues that the core problem is not simply detection of leaked secrets, but governance of the non-human identities those secrets represent.

That distinction matters because a secret is only the authentication material. The underlying NHI remains active until it is rotated, revoked, scoped down, or offboarded, and many organisations still treat those steps as optional cleanup rather than part of the identity lifecycle.

The result is a control gap that spans developers, DevOps pipelines, and cloud workloads. In this operating model, exposure can happen in public repositories, private repositories, Slack, Jira, Confluence, and container images, which makes secrets management a lifecycle issue rather than a code-scanning issue.

Key questions

Q: What breaks when exposed NHI secrets are left in public DevOps environments?

A: Publicly exposed NHI secrets break the assumption that internal trust boundaries still protect machine credentials. Once tokens, keys, or certificates are readable outside intended control, attackers can authenticate directly, move into adjacent systems, and copy data without exploiting a software flaw. The result is faster compromise, wider blast radius, and harder containment.

Q: Why do leaked service credentials remain dangerous after they are discovered?

A: They remain dangerous because exposure and invalidation are separate events. If the secret still authenticates, an attacker can use it immediately, and the organisation’s delay in revocation determines how much access and lateral movement remains available.

Q: How do identity teams know whether secrets governance is actually working?

A: Identity teams know secrets governance is working when they can prove that every active secret has an owner, an approved scope, and a tested revocation path. If they cannot quickly identify where a secret is used or remove it without breaking the workload, governance is still incomplete.

Q: What is the difference between secret scanning and secrets management?

A: Secret scanning finds credentials that have been exposed, while secrets management controls how credentials are stored, issued, rotated, and revoked. Scanning is detective. Management is preventive and lifecycle-based. Strong programmes need both because discovery alone does not remove access.

Technical breakdown

Why hardcoded secrets persist in modern delivery pipelines

Hardcoded secrets persist because software delivery systems still assume credentials can be embedded, copied, and later cleaned up without changing the access model. That assumption breaks when secrets are reused across environments, stored outside dedicated managers, or left in build and collaboration tooling. A secret in source control is not just a leakage event. It is a durable authentication path that outlives the commit, the ticket, or the message where it appeared. This is why the same secret often remains exploitable even after it is detected. The mechanism is simple: discovery is faster than governance, and governance is slower than reuse.

Practical implication: treat every exposed secret as an active identity until rotation and revocation are confirmed, not as a completed detection event.

Why private repositories and collaboration tools are not safe boundaries

Private repositories and internal collaboration tools often create a false sense of containment. GitGuardian’s findings show that secrets do not stay neatly inside source code platforms; they also surface in Slack, Jira, and Confluence, where teams exchange operational context and temporary access material. Private systems reduce visibility, not risk. Once a secret is pasted into a chat, ticket, or document, it has escaped the normal guardrails of code review, repository scanning, and branch protection. The governance failure is boundary thinking: teams protect the repository while ignoring the broader secret lifecycle across the work system.

Practical implication: extend secret scanning and revocation workflows to collaboration platforms, ticketing systems, and other non-code channels where credentials are shared.

Why secrets managers do not eliminate NHI exposure

Secrets managers centralise storage, but they do not automatically solve lifecycle, ownership, or misuse. If applications, workloads, or developers continue to export credentials into configs, CI/CD jobs, or local files, the manager becomes one control point in a wider sprawl problem. That is why governance must include issuance, rotation, expiration, and recovery rather than storage alone. From an identity perspective, the secret is only the token of trust; the NHI is the subject that must be continuously governed. When that lifecycle is weak, even a secrets manager is just another place where bad hygiene can accumulate.

Practical implication: govern secrets managers as part of the NHI lifecycle, with ownership, rotation, and expiry rules enforced across all consuming systems.

Threat narrative

Attacker objective: The objective is to use exposed non-human credentials to obtain persistent access, expand reach across systems, and increase blast radius before defenders can revoke the secret.

1. Entry occurs when a hardcoded secret, token, or API key is exposed in GitHub, a document, or a collaboration tool and becomes available for reuse.
2. Credential access follows when an attacker or unauthorized user copies the secret and authenticates as the underlying non-human identity.
3. Escalation happens when the credential grants access wider than the original use case, such as cloud services, build systems, or production workflows.
4. Impact is achieved when the exposed identity is used for lateral movement, data access, or destructive actions before the secret is revoked.

Breaches seen in the wild

• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
• Millions of Misconfigured Git Servers Leaking Secrets: Nearly 5 million misconfigured Git servers expose sensitive secrets and credentials online.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secrets sprawl is now an identity governance problem, not a discovery problem. GitGuardian’s data shows that exposed credentials continue to circulate across repositories, collaboration tools, and images long after teams think they have contained them. The real failure is that organisations still separate secret detection from identity lifecycle control. The practitioner conclusion is that secrets management must be treated as NHI governance, not as a standalone hygiene task.

Long-lived credential trust debt is the core failure mode. A secret that remains valid after exposure represents unresolved trust debt that compounds over time. GitGuardian’s finding that 70% of 2022 leaks are still valid shows that many teams do not have a reliable revocation path, or do not operationalise it fast enough. The implication is that blast radius, not leak count, is the metric that matters for NHI security.

Private storage does not create private risk. Secrets appearing in private repositories, Slack, Jira, and Confluence show that the organisation’s secret surface extends beyond source code and into the everyday workflow of engineering and operations. That broadens the governance burden across human, machine, and service-account touchpoints. The practitioner conclusion is that secret controls must follow the identity wherever it is used, not where the team wishes it lived.

Secrets managers reduce sprawl only when ownership and expiry are enforced. Central vaulting does not fix insecure authentication practices, misconfiguration, or human reuse of credentials across systems. A secrets manager that lacks lifecycle discipline can become a repository for dormant trust rather than a control for active trust. The implication is that teams should measure whether secrets are actually expiring and being revoked, not just where they are stored.

Ephemeral exposure still leaves durable access unless offboarding is automatic. This is the most important named concept in the article: the organisation may detect the leak quickly, but the identity behind the leak remains reachable until the access path is closed. That is why NHI programmes need continuous governance over issuance, rotation, and revocation. The practitioner conclusion is that exposure response must be built into the identity lifecycle, not bolted on after the fact.

From our research library:

• 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, according to the State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
• Read next: Ultimate Guide to NHIs — Key Research and Survey Results

What this signals

Secrets sprawl changes the control point from detection to invalidation. Once credentials are scattered across code, chat, tickets, and images, teams need to govern where trust can still be exercised, not just where it was found. The article’s lesson is that secret exposure becomes a lifecycle failure when invalidation is slower than reuse.

Ephemeral credential trust debt: This is the gap between finding a leaked secret and making it unusable. The bigger the delay, the more likely the secret is to outlive its intended purpose and become part of the attacker’s access path.

When non-human identities are governed only at creation time, the organisation has no reliable answer to who still has usable access after a leak. That pushes NHI programmes toward continuous ownership, expiry, and revocation rather than periodic cleanup.

For practitioners

• Implement secret lifecycle ownership Assign a named owner for every credential, token, and key so that discovery triggers a clear revoke-or-rotate workflow rather than an informal cleanup task.
• Expand scanning beyond source control Scan Slack, Jira, Confluence, CI/CD logs, and container artefacts for secrets because the article shows leaks frequently originate outside repositories.
• Shorten the validity window Replace static credentials with short-lived secrets where possible and enforce expiry so leaked material becomes useless faster than adversaries can exploit it.
• Tie revocation to exposure events Make revocation or key replacement an immediate control outcome when a secret is detected, with evidence that the old credential can no longer authenticate.
• Audit private-repo assumptions Review internal repositories and developer workflows for the assumption that private equals safe, because the article shows private code still contains plaintext secrets.

Key takeaways

• Secrets sprawl is a governance problem because leaked credentials often remain valid after discovery, which leaves the underlying non-human identity exposed to reuse.
• The article shows that secrets leak far beyond source code, including collaboration tools and private repositories, so scanning only public code misses a large part of the risk surface.
• The practical control is not just finding secrets faster, but making sure every exposed secret is revoked, rotated, or expired before it can be reused.

Key terms

• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Long-Lived Secret: A long-lived secret is a credential, token, API key, or certificate that remains valid for an extended period without frequent renewal. In NHI environments, it creates durable exposure because one leaked secret can keep granting access long after the original use case has changed.
• Secrets Lifecycle: Secrets lifecycle is the management of credentials from issuance through rotation, revocation, and offboarding. It matters because a secret that is technically valid can still be operationally unsafe if its owner, purpose, or downstream access paths are no longer current.
• Credential Invalidity Window: Credential invalidity window is the time between secret exposure and the point at which the secret can no longer authenticate. The shorter this window, the less time an attacker has to exploit a leaked NHI credential before the organisation removes its value.

What's in the full report

GitGuardian’s full report covers the operational detail this post intentionally leaves for the source:

• Breakdown of where secrets are leaking across public repositories, private repositories, collaboration tools, and container images
• Analysis of generic credentials versus more identifiable secret types, useful for prioritising detection strategy
• Examples of how GitHub Push Protection fails to cover several common secret formats
• The report’s practical recommendations for semi-automated expiration, rotation, and cross-vault governance

👉 GitGuardian’s full report covers the leak patterns, invalidation gaps, and remediation priorities behind secrets sprawl

Deepen your knowledge

NHI governance, secrets management, and 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.