Access becomes invisible, reusable, and hard to revoke, which means the organisation loses control of where authentication material exists. Once secrets are embedded in code or pipeline tools, discovery gets harder, offboarding slows down, and the same credential can survive multiple deployment cycles.
Why This Matters for Security Teams
Secrets in code and CI/CD tools turn authentication into ambient infrastructure instead of a controlled security primitive. That shift breaks revocation, ownership, and visibility at the same time. Once a token is copied into a repo, build variable, runner image, or chatops workflow, it can be reused by developers, automation, forks, contractors, and attackers long after the original task is finished. NHI governance then fails at the exact point where security teams need certainty: who can authenticate, where, and for how long.
This is not a theoretical issue. GitGuardian reported that The State of Secrets Sprawl 2026 detected 28.65 million new hardcoded secrets in public GitHub commits in 2025 alone, showing that exposure at commit time remains a massive operational problem. The OWASP Non-Human Identity Top 10 treats exposed and overlong-lived credentials as a core identity risk, not just a hygiene issue. In practice, many security teams discover the blast radius only after a pipeline has already promoted the same credential across multiple deployment cycles.
For deeper incident context, see the CI/CD pipeline exploitation case study and the Reviewdog GitHub Action supply chain attack, both of which show how pipeline trust can become credential sprawl.
How It Works in Practice
The failure starts with convenience. Developers embed secrets in source files, environment definitions, container build steps, pipeline variables, or shared automation scripts so systems can “just work.” That creates several downstream breaks: secrets are copied into logs, cached in build artifacts, inherited by runners, replicated across environments, and left behind when staff or services are offboarded. A credential that should behave like a JIT entitlement instead becomes a static identity artifact with no clear expiry.
Current guidance suggests treating secrets as short-lived workload credentials, not configuration data. That means issuing dynamic credentials at runtime, scoping them to a specific task, and revoking them automatically when the task ends. In mature setups, this is paired with workload identity so the pipeline or agent proves what it is through cryptographic identity, then receives only the minimum access needed for that run. The Ultimate Guide to NHIs — Static vs Dynamic Secrets is a useful reference point for this shift, especially where static credentials have been embedded into CI/CD templates for years.
- Detect hardcoded secrets in code, build specs, runner images, and collaboration tools before release.
- Replace long-lived tokens with ephemeral credentials issued per job or per deployment.
- Bind access to workload identity and policy decisions evaluated at request time.
- Revoke on completion, not on a quarterly schedule.
The Guide to the Secret Sprawl Challenge and Shai Hulud npm malware campaign both illustrate how quickly secrets leak once they enter developer tooling and automated delivery paths. These controls tend to break down when CI/CD runners are shared across projects or persist across jobs because credential residue survives beyond the intended trust boundary.
Common Variations and Edge Cases
Tighter secret handling often increases delivery friction, requiring organisations to balance release speed against revocation certainty and operational overhead. That tradeoff is real, especially in polyglot pipelines, legacy build systems, and platform teams that still rely on static environment variables for compatibility.
There is no universal standard for this yet, but best practice is evolving toward a few consistent patterns. First, separate developer convenience from production trust by using different credential classes for local testing, preview environments, and release pipelines. Second, treat secret scanning as a control to reduce exposure, not as the control that makes exposure safe. GitGuardian’s Guide to the Secret Sprawl Challenge context is reinforced by the 2025 finding that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which shows why detection without revocation leaves the real risk intact.
Third, recognise that shared tools introduce non-code leakage paths. Slack, Jira, Confluence, and other collaboration systems often carry tokens in tickets, approvals, and deployment notes. The 52 NHI Breaches Analysis is a reminder that identity failures regularly appear outside the repository itself, and the OWASP Non-Human Identity Top 10 remains the clearest external reference for prioritising those failure modes.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Secret sprawl makes credential rotation and revocation the core identity problem. |
| NIST CSF 2.0 | PR.AC-1 | This issue is fundamentally about controlling and limiting authentication access. |
| NIST AI RMF | Automated pipelines and agents need governance for runtime credential use and accountability. |
Replace embedded secrets with short-lived credentials and enforce automatic rotation or revocation.
