They should minimise the number of long-lived credentials available to build jobs, use short-lived scoped tokens where possible, and treat runners as privileged systems. Every pipeline should have a clear revocation path so that exposed secrets can be invalidated quickly when compromise is suspected.
Why This Matters for Security Teams
Secrets in CI are not just an account hygiene problem. Build systems sit in the middle of source code, artifact signing, deployment, and test automation, so one exposed token can become a path to source theft, package tampering, cloud access, or lateral movement. In NHIMG research, GitGuardian’s State of Secrets Sprawl 2026 found 64% of valid secrets leaked in 2022 are still valid and exploitable today, which shows why detection alone is insufficient without revocation.
Security teams often miss that CI runners are privileged systems, not disposable utilities. They execute code from pull requests, install dependencies, call internal APIs, and often inherit broad environment access. That means the blast radius is defined by the runner, the pipeline design, and the secret lifetime, not just by the secret value itself. Current guidance from OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both points toward least privilege, controlled exposure, and fast recovery.
In practice, many security teams encounter credential abuse only after a pipeline has already been used to mint, copy, or exfiltrate secrets rather than through intentional monitoring.
How It Works in Practice
The most effective pattern is to reduce standing access and issue credentials only when a job actually needs them. That means replacing long-lived API keys, SSH material, and shared service accounts with short-lived, scoped credentials tied to the pipeline identity and the specific task. Where possible, use workload identity so the runner proves what it is at runtime instead of carrying a reusable secret throughout the build. NHIMG’s Guide to the Secret Sprawl Challenge is a useful reference for the operational side of this problem.
A practical control set looks like this:
- Issue JIT credentials per job or per stage, with TTLs measured in minutes, not days.
- Scope each token to one repository, one environment, or one deployment action.
- Store secrets outside the CI platform whenever possible, then retrieve them at runtime from a vault or identity broker.
- Restrict runner permissions so untrusted builds cannot reach production secrets or signing keys.
- Rotate and revoke on every suspicion event, and verify that revocation actually propagates.
That model is especially important because compromised CI infrastructure is not rare. NHIMG research in the CI/CD pipeline exploitation case study shows how attackers use pipeline trust to move from code execution to secrets exposure. The pattern also aligns with OWASP guidance and with NIST’s emphasis on recoverability and continuous monitoring, rather than trusting a one-time approval.
These controls tend to break down when runners are reused across many projects or when teams embed secrets into build images, because the same credential can be exposed outside the intended job boundary.
Common Variations and Edge Cases
Tighter secret controls often increase build friction, requiring organisations to balance developer speed against exposure reduction. That tradeoff is real, especially in monorepos, release engineering, and self-hosted runner fleets where caching, parallelism, and permission boundaries can be difficult to separate cleanly.
One common exception is third-party tooling that still requires static credentials. In those cases, best practice is evolving rather than settled: use the shortest possible TTL, isolate the integration to a dedicated service account, and monitor for unusual use. Another edge case is ephemeral preview environments, where teams may be tempted to copy production secrets for convenience. That creates unnecessary duplication and weakens incident response, especially when secrets are also stored in chat, tickets, or configuration files.
NHIMG research highlights the scale of the underlying problem: 62% of all secrets are duplicated and stored in multiple locations in The 2025 State of NHIs and Secrets in Cybersecurity, which makes cleanup and revocation slower than teams expect. For policy framing, NIST Cybersecurity Framework 2.0 remains the most practical baseline, while OWASP Non-Human Identity Top 10 is useful for identifying where identity sprawl and weak lifecycle controls turn into pipeline exposure.
The hard case is highly automated release systems with multiple downstream secrets dependencies, because revocation can interrupt production delivery unless dependency ownership and fallback paths are defined in advance.
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 SPIFFE/SPIRE set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses secret lifecycle and rotation failures in CI pipelines. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central to limiting CI secret exposure. |
| SPIFFE/SPIRE | Workload identity is the preferred primitive for authenticating CI runners without static secrets. |
Bind runners to workload identity and exchange that identity for short-lived credentials at runtime.
