They often contain many reusable secrets at once, including cloud keys, package tokens, SSH material, and cluster credentials. That concentration turns a single compromise into broad access. The risk rises when those secrets are stored in files, environment variables, or memory-backed paths that any process can read.
Why This Matters for Security Teams
CI/CD runners are high-risk because they are not just build workers. They are privileged execution environments that often sit close to source code, artifact stores, cloud APIs, package registries, and deployment targets. When a runner is compromised, the attacker is rarely limited to one secret. They can often pivot into signing keys, publishing tokens, cluster credentials, and infrastructure permissions in a single session.
This is why Guide to the Secret Sprawl Challenge treats pipeline exposure as a broad identity problem, not just a leakage problem. The control challenge is compounded by the fact that runners are ephemeral, automated, and frequently over-scoped to avoid build failures. NIST’s Cybersecurity Framework 2.0 reinforces the need to govern these systems as critical assets, not disposable infrastructure.
GitGuardian’s State of Secrets Sprawl 2026 found that 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations. In practice, many security teams discover the blast radius only after a pipeline account has already been used to move laterally into production.
How It Works in Practice
The risk comes from concentration, persistence, and execution context. A runner may receive secrets through environment variables, mounted files, workspace caches, injected credentials, or inherited cloud identity. Even when the runner is short-lived, the secrets it handles are often reusable far beyond the job that requested them. If the process can read them, so can malware, a malicious dependency, or a compromised build step.
Current guidance suggests reducing that exposure with Ultimate Guide to NHIs — Static vs Dynamic Secrets and with the identity controls described in the OWASP Non-Human Identity Top 10. In practice, that means:
- Issuing JIT credentials per job instead of reusing long-lived tokens.
- Binding secrets to workload identity and narrowing scope to the exact repository, branch, environment, or deployment target.
- Using short TTLs and automatic revocation so a stolen token ages out quickly.
- Separating build, test, and deploy privileges so one runner cannot perform every phase.
- Preventing secret material from landing in logs, caches, artifact outputs, or shell history.
When the pipeline needs cloud access, the better pattern is to exchange workload identity for ephemeral authorization at runtime, rather than storing static keys on the runner. That aligns with the operational direction of least privilege and with the identity-centric controls in NIST SP 800-53 control families, especially where access is time-bound and auditable. These controls tend to break down when legacy runners share persistent volumes or when one automation account is trusted across multiple environments.
Common Variations and Edge Cases
Tighter runner controls often increase build friction, requiring organisations to balance deployment speed against containment. That tradeoff is most visible in monorepos, self-hosted runners, and multi-tenant build fleets, where teams want broad access for convenience but the blast radius grows with every additional credential.
There is no universal standard for this yet, but best practice is evolving toward context-aware access decisions and runtime policy enforcement. For example, a release job may need signing authority only if it is triggered from a protected branch, on an approved runner image, with a verified commit and a valid attestation chain. If any of those signals are missing, the runner should receive less privilege or no credentials at all.
Edge cases matter. Some organisations hide secrets in container build args, local files, or shared caches because environment variables are easier to inspect, but the exposure problem remains the same. Others assume private repositories are safe, yet the underlying issue is still that a runner can read too much for too long. In environments with frequent third-party actions, nested workflows, or self-updating build scripts, the attack surface expands quickly and the policy model can lag behind reality.
That is why practitioners increasingly pair pipeline hardening with continuous secret scanning, workload identity, and automatic revocation. The hard part is not only finding the secret. It is ensuring the runner never becomes the place where one secret unlocks everything.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Runners act autonomously and can execute chained actions with broad privilege. |
| OWASP Non-Human Identity Top 10 | NHI-03 | CI/CD runners commonly rely on static secrets that outlive their job. |
| CSA MAESTRO | M1 | Pipeline agents need scoped, attributable identities for each execution context. |
| NIST AI RMF | Runner behaviour and blast radius require governance, measurement, and monitoring. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central to reducing runner credential exposure. |
Limit runner authority to task-specific actions and validate every tool call at runtime.
