TL;DR: GitGuardian says enterprise secrets sprawl now extends across repositories, documentation tools, and collaboration platforms, and that large-scale control depends on developer trust, low false positives, and prevention-first workflows rather than scanner volume alone. The governance question is no longer whether secrets leak, but whether organisations can prevent, prioritise, and remediate them before history preserves the exposure.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on GitGuardian's blog post: Secrets sprawl at enterprise scale is a governance and lifecycle problem, not just a detection problem, because exposures now spread across code and collaboration tools.
Why it matters: IAM, IGA, PAM, and NHI teams need to treat secrets as governed identities with lifecycle controls, because visibility without prevention and remediation still leaves exploitable exposure.
👉 Read GitGuardian's analysis of secrets sprawl at enterprise scale
Context
Secrets sprawl is the uncontrolled spread of credentials, tokens, API keys, and certificates across systems where they are hard to inventory, govern, and revoke. In this article, the problem is not limited to code repositories. It reaches collaboration platforms, documentation tools, and container registries, which means the governance gap sits across the full identity and software delivery lifecycle.
GitGuardian uses Orange Business's enterprise experience to show why this matters at scale: thousands of developers, hundreds of projects, and multiple toolchains create more opportunity for exposure than traditional scanning models assume. The article's core point is that secrets management fails when teams treat leakage as a repository-only issue instead of an enterprise governance problem.
Key questions
Q: What breaks when secret scanning is limited to source code alone?
A: Code only scanning misses a large part of the exposure surface. Secrets also appear in Slack, Jira, Confluence, email, observability logs, data exports, and cloud storage. If teams ignore those channels, they create blind spots where credentials can circulate, persist, and be reused long after the original leak is discovered.
Q: Why do false positives undermine enterprise secrets programmes?
A: Because developers stop trusting alerts that are mostly noise, and ignored alerts quickly become tolerated exposure. At scale, the control is only effective when valid findings are easy to distinguish from context-specific exceptions and the remediation path is fast enough to keep pace with development.
Q: How do you know whether secrets prevention is actually working?
A: Look for fewer new exposures entering Git, lower bypass rates, and faster correction of valid findings by development teams. If alerts keep rising but remediation does not improve, the programme is detecting problems without changing behaviour.
Q: Should teams prioritise prevention or post-commit remediation for secrets?
A: Prioritise prevention first, because once a secret reaches Git history or downstream references, cleanup is partial and often expensive. Remediation still matters, but it should be treated as the backstop for exceptions, not the primary control.
Technical breakdown
Why repository-only secrets scanning misses enterprise exposure
Repository scanning only covers one surface in a much broader secrets estate. The article shows that secrets also appear in Teams, Confluence, Jira, container registries, and other systems where developers document, collaborate, and operate. That matters because a credential's risk is determined by where it can be reused, how long it remains valid, and whether anyone can actually revoke it across all copies and references. A tool that watches Git alone can detect exposure, but it cannot establish complete inventory or lifecycle control across the estate.
Practical implication: Map secrets detection to every place credentials are created, discussed, copied, or stored, not just source control.
How false positives turn secrets controls into a trust problem
False positives are not just an accuracy defect. At enterprise scale, they become an adoption problem that makes developers ignore controls and security teams lose remediation credibility. The article's example shows how one project can produce manageable output while another produces unusable volume, even when the underlying codebase is similar. That variance means policy enforcement must be paired with high-confidence detection and prioritisation, otherwise every alert competes with noise. In practice, the control fails when teams cannot separate valid exposure from contextual edge cases quickly enough to preserve workflow.
Practical implication: Tune secrets controls for precision first, then measure whether developers are still acting on the findings.
Why prevention matters more than post-commit cleanup
Once a secret is committed, Git history and downstream references can preserve it even if the visible file is later changed. The article makes clear that this creates a structural remediation problem, not a simple deletion problem. Prevention at commit time is therefore a different control class from detection after the fact. Lifecycle governance has to move left to the point where the secret is first introduced, because after that, removal is partial at best and auditability remains. That is why this is an identity governance issue, not only a code hygiene issue.
Practical implication: Prioritise prevention gates and immediate revocation workflows over relying on repository cleanup after exposure.
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 because the credential estate is no longer confined to source control. The article shows secrets living in collaboration tools, documentation systems, registries, and repositories at the same time. That destroys the old assumption that a repository scan is an adequate control boundary. Practitioners should treat secrets inventory, not scan volume, as the governance baseline.
Developer trust is the control plane for secrets management at enterprise scale. If alerts are noisy, teams rationally ignore them, and the governance model collapses into exception handling. Orange Business's experience shows that precision and workflow fit determine whether enforcement is accepted or bypassed. The practical conclusion is that secrets governance succeeds only when it is operationally credible to developers.
Prevention-first secrets governance is the only sustainable model once Git history preserves exposure. A deleted secret is not the same as an unexposed secret, because references and historical commits can remain reachable. That means remediation is always more expensive than prevention, and the article correctly frames the problem as lifecycle control rather than cleanup. The field should measure success by avoided exposure, not just by cleanup speed.
Enterprise secrets governance now demands distributed remediation with centralised visibility. Large organisations need a model that lets local teams fix issues while security retains enterprise oversight, audit trails, and prioritisation. That is the only way to operate across hundreds of projects without turning central security into a bottleneck. The practitioner lesson is to govern the estate as a system, not as isolated repositories.
Secrets sprawl should be understood as a named concept: credential surface expansion. As credentials move beyond code into collaboration and operations tools, the attack and governance surface expands faster than traditional reviews can follow. This expands the scope of NHI governance from detection of leaks to management of where credentials are created, reused, and retained. Practitioners should redesign controls around that broader surface, not the old repository model.
From our research library:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Enterprises manage far more machine secrets than human ones: 20 times as many according to Enterprise Strategy Group, and 45 times according to GitGuardian.
- Read next: Secrets Management Guide
What this signals
Credential surface expansion: Enterprises should stop treating secrets exposure as a repository-only problem. Once credentials are allowed to sprawl into chat, tickets, documentation, and registries, the governance model must shift from isolated scanning to estate-wide lifecycle control.
The practical signal for IAM and NHI programmes is that detection quality now matters as much as detection coverage. If developers do not trust the output, the control will be bypassed or ignored, and the organisation will be left with visibility but no reduction in exposure.
Secrets governance should now be measured by whether new exposures are prevented before they enter history, not just how quickly old ones are found. That changes the control objective from clean-up to prevention, revocation, and ownership at the point of creation.
For practitioners
- Inventory every secrets exposure surface Include source control, documentation tools, chat platforms, ticketing systems, registries, logs, and support workflows in the same credential inventory and review process.
- Shift enforcement to pre-commit and pre-receive gates Block new secrets before they enter Git history, while preserving a controlled bypass path for validated false positives and test values.
- Set precision thresholds for developer adoption Track false positive rate, escalation volume, and developer response time together so the control remains trusted enough to be used.
- Separate detection from remediation ownership Give local teams the ability to fix exposures while security retains central visibility, prioritisation, and auditability across all projects.
Key takeaways
- The article shows that secrets sprawl has outgrown repository-only controls and now spans collaboration and operational systems as well as source code.
- Enterprise-scale secrets programmes fail when alert noise destroys developer trust and makes enforcement operationally unsustainable.
- The control that matters most is preventing exposure before a secret enters history, because later cleanup cannot fully erase the risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on secrets leaking into code, chat, tickets, and documentation. |
| NHI-07 — Long-Lived Secrets | The article stresses that once secrets enter Git history, they remain reachable and hard to remove. | |
| Recommendation — Scan all developer and collaboration surfaces for exposed secrets and revoke anything that leaks. Reduce secret lifetime and rotate credentials immediately when exposure is discovered. | ||
| CIS Controls v8 | CIS-5 — Account Management | Secrets sprawl is a lifecycle and ownership problem across thousands of developers and projects. |
| Recommendation — Enforce accountable ownership and revocation for every secret-bearing account or credential. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing who can create, retain, and use secrets across the enterprise. |
| Recommendation — Review and limit entitlements that allow secrets to be created, copied, or retained outside managed stores. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Exposed secrets enable credential access and lateral movement if they are reused across systems. |
| Recommendation — Map leaked secrets to credential-access and lateral-movement detections in your threat hunting. | ||
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.
- False Positive Rate: False positive rate is the share of alerts, detections, or test results that incorrectly indicate a problem when none exists. In security and identity operations, it measures how often a control flags benign activity as suspicious, usually expressed as a percentage of all negative cases. Lower rates reduce analyst noise and wasted response effort.
- Pre-receive Hook: A pre-receive hook is a server-side Git control that evaluates a push before the repository accepts it. It provides centralized enforcement for secret detection and other policies, which helps catch developer bypasses and inconsistent local configurations before code reaches shared history.
- Credential Surface Expansion: The growth of places where secrets appear beyond source code, including chat, documentation, ticketing, registries, and logs. This expands the governance boundary from development repositories to the wider operational and collaboration estate.
What's in the full article
GitGuardian's full article covers the operational detail this post intentionally leaves for the source:
- The Orange Business rollout sequence, including how the team phased enforcement across projects
- The reported 5% false positive threshold and how it affected developer adoption
- The 17,000-to-1 comparison between GitLeaks and GitGuardian on the same codebase
- The broader list of systems being added to scanning, including Teams, Jira, Confluence, and container registries
Deepen your knowledge
NHI governance, secrets management, and workload identity security 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.
Published by the NHIMG editorial team on May 30, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org