Secrets sprawl at enterprise scale is now a governance problem

At a glance

What this is: This is an independent analysis of Orange Business's secrets security journey and its finding that prevention, accuracy, and developer adoption matter more than raw scan volume.

Why it matters: For IAM and NHI practitioners, it shows why secrets sprawl must be governed as a lifecycle problem across code, collaboration tools, and access workflows.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• 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.

👉 Read GitGuardian's analysis of Orange Business's secrets security rollout

Context

Secrets sprawl is what happens when credentials, tokens, certificates, and keys are created faster than they can be inventoried, rotated, or revoked. In this case, the NHI governance gap is clear: an enterprise can have vaults and scanners in place while still losing visibility across repositories, tickets, documentation, chat, and build systems.

Orange Business is operating at the scale where small process failures become enterprise exposure, which is typical for large development organisations and atypical for most practitioners only because they do not yet see the full distribution problem. The article's core lesson is that lifecycle control matters more than isolated detection.

Key questions

Q: How should security teams handle leaked secrets once they are found?

A: They should treat detection as the start of response, not the end. The right sequence is to confirm whether the secret is valid, revoke or rotate it immediately, review where else it may have been copied, and verify that access paths tied to it are closed. Discovery without revocation leaves the identity usable and the risk intact.

Q: What is the difference between secrets scanning and secrets governance?

A: Secrets scanning finds exposed values, while secrets governance controls ownership, lifecycle, validation, and response. Scanning is a detection function. Governance is the operating model that decides who can create secrets, where they may live, how quickly they must be rotated, and what happens after exposure.

Q: Why do secrets in Git history create long-term risk?

A: Because deleting a secret from the latest file does not guarantee it disappears from version history, platform databases, or clones already made elsewhere. If the secret was valid when committed, anyone who captured it earlier may still be able to use it until it is revoked.

Q: How can teams reduce secret leakage without slowing developers down?

A: Use controls that fit existing workflows, keep false positives low, and make remediation simple and fast. The goal is to stop real secrets early while avoiding alert noise that trains developers to ignore security checks. Adoption improves when the control feels like part of delivery, not an external gate.

Technical breakdown

Why secrets sprawl defeats point-in-time scanning

Secrets sprawl becomes hard to govern when credentials appear across repositories, documentation, tickets, container registries, and chat systems. A scanner can detect exposed values in one place, but it cannot by itself establish ownership, validity, or revocation priority. That is why point-in-time detection often creates noise rather than control: the tool sees a secret, but the organisation still has to decide whether it is real, active, duplicated, or already embedded in history. In an NHI model, every exposed secret is a live identity artifact with potential access authority, so the problem is lifecycle, not just discovery.

Practical implication: Treat secret discovery as an input to governance, not as the control itself.

Why false positives break developer-led security workflows

False positives are not just an operational nuisance. They shape whether developers trust the control enough to keep using it. When a scanning tool flags too many non-issues, teams begin bypassing it, which removes the very enforcement value the programme was designed to create. The article shows a practical truth in NHI security: prevention only works if the control is accurate enough to sit inside normal developer flow. Otherwise, security teams end up with alert fatigue, manual review debt, and weak adoption. This is especially true where secrets are generated or copied quickly in CI/CD pipelines.

Practical implication: Prioritise precision thresholds and exception handling before enforcing block-and-stop controls.

How pre-commit, pre-receive, and post-commit controls fit together

A layered model works because each stage closes a different gap. Pre-commit checks catch secrets on the workstation before they enter the repository. Pre-receive controls act as the enforcement point and can block pushes when policy requires it. Post-commit scanning then catches bypasses, historical exposure, and edge cases that slip through earlier layers. That architecture matters because no single control can reliably stop all secret leakage paths. For IAM and NHI teams, this is the same design logic used in privileged access controls: reduce standing exposure, then add monitoring for what cannot be eliminated.

Practical implication: Use layered enforcement so discovery, blocking, and monitoring reinforce one another.

Threat narrative

Attacker objective: The attacker objective is to turn exposed secrets into authenticated access that can be reused across systems without immediate detection.

1. Entry occurs when secrets are copied into code, chat, documentation, or build artefacts outside central control.
2. Escalation follows when those secrets remain valid, reusable, or duplicated across repositories and projects.
3. Impact comes from unauthorised access to cloud services, CI/CD systems, or application environments through exposed credentials.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• 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

Secrets sprawl is an NHI governance problem before it is a detection problem. Once credentials are scattered across repositories and collaboration tools, the organisation is no longer managing discrete secrets. It is managing distributed non-human identities with unclear ownership and unclear revocation paths. Practitioners should therefore measure the control plane, not just the number of findings.

Developer trust is the real control boundary. A secrets scanner that produces too much noise will be bypassed, ignored, or only partially deployed. That means precision, workflow fit, and exception handling are security requirements, not usability extras. Teams that want enforcement must first earn adoption.

Ephemeral detection without revocation creates trust debt. Finding a leaked secret does not reduce risk if the secret remains valid or if its historical references persist. This is the operational gap between discovery and actual risk reduction, and it should push teams toward automated rotation, expiry, and invalidation.

Prevention-first controls define the practical standard for modern secret management. The article reinforces a broader industry pattern: once a secret is committed, remediation becomes slower, costlier, and more brittle than prevention. For NHI programmes, that means the decisive control is stopping secrets before they enter shared systems.

From our research:

• 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.
• Internal repositories are 6x more likely to contain secrets than public ones, with 32.2% versus 5.6%, which shows why private-code assumptions are unsafe.
• For a broader governance baseline, see Guide to the Secret Sprawl Challenge for how secrets exposure extends beyond source control into day-to-day operations.

What this signals

Ephemeral credential trust debt: organisations that rely on detection alone accumulate hidden exposure because each discovered secret still has to be rotated, revoked, and traced across downstream systems. With 64% of valid secrets leaked in 2022 still valid and exploitable today, according to The State of Secrets Sprawl 2026, the governance gap is no longer theoretical.

Security programmes should expect secrets controls to move closer to enforcement at commit time and further into collaboration tools and build pipelines. That shift will force IAM teams to align repository policy, access review, and incident response more tightly than many current operating models allow.

For practitioners

• Map secret exposure beyond source code Inventory where credentials appear in documentation systems, tickets, chat, container registries, and logs. Apply the same ownership and remediation rules you use for code-based exposure because the risk is the same even when the location is not.
• Set a measurable false-positive threshold Define an acceptable alert precision target before scaling enforcement. If teams cannot trust the scanner output, they will bypass it, so tune detection and review workflows until developers see blocking as credible rather than noisy.
• Deploy layered commit controls Use workstation scanning, pre-receive blocking, and post-commit monitoring together. The combination catches different failure modes and gives security teams visibility into both accidental exposure and intentional bypasses.
• Automate revocation after detection Connect secret discovery to rotation, disablement, or invalidation so leaked credentials do not remain usable after they are found. Detection without revocation leaves the same identity active and only improves your reporting.
• Review Git history assumptions Assume that deleted secrets may still exist in repository history and related platform databases. Build remediation playbooks that include historical exposure, not just the latest branch state.

Key takeaways

• Secrets sprawl becomes an IAM and NHI governance issue when credentials outlive the systems and teams that created them.
• Developer trust determines whether secrets controls are ignored, bypassed, or adopted at scale.
• Prevention, revocation, and historical exposure review are the controls that actually reduce risk.

Key terms

• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials, tokens, keys, and certificates across systems, repositories, and collaboration tools. It turns identity material into an inventory problem, then into a governance problem when no team can confidently say where the secrets live or how quickly they can be revoked.
• Pre-Receive Control: A pre-receive control inspects code before it is accepted into a central repository. In secrets security, it acts as an enforcement point that can block commits containing credentials, but only works well when the detection is accurate and the exception process is tightly managed.
• False Positive Rate: False positive rate is the share of alerts that do not represent a real security issue. In secrets programmes, a high false positive rate drives developer bypass behaviour, reduces trust in controls, and creates operational noise that slows remediation of genuinely exposed credentials.
• Historical Exposure: Historical exposure is the persistence of leaked secrets in repository history, platform databases, clones, and backups after the visible code has been changed. It matters because removing a secret from the latest version does not automatically remove the access path the secret once enabled.

What's in the full article

GitGuardian's full article covers the operational detail this post intentionally leaves for the source:

• The phased rollout pattern for enforcing pre-receive blocking without breaking developer workflows.
• The practical impact of false positive rates on adoption, including why the team targeted under 5%.
• The three-layer detection model spanning workstation scanning, GitLab enforcement, and post-commit monitoring.
• The expansion plan beyond repositories into Confluence, Jira, Teams, Mattermost, container registries, and logs.

👉 GitGuardian's full post covers the rollout mechanics, developer feedback loop, and measured reduction in leaked secrets.

Deepen your knowledge

Secrets sprawl and lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a secrets governance programme in a large development environment, it is worth exploring.