CI/CD systems often hold cloud keys, API tokens, and repository credentials in one place, which makes them efficient targets for attackers seeking multiple reusable secrets. Once malicious code executes there, it can harvest identity material at scale. That is why build environments need tighter segmentation than general developer workstations.
Why This Matters for Security Teams
CI/CD is high-value because it concentrates privilege, automation, and trust in one path that can touch source code, build systems, artifact stores, cloud accounts, and deployment targets. That makes it a natural place for NHI abuse, especially when secrets are reused across stages. NHI Mgmt Group research shows that 96% of organisations store secrets outside secrets managers in places such as code, config files, and CI/CD tools, and that is exactly the kind of sprawl attackers look for in build pipelines. See Ultimate Guide to NHIs and the Guide to the Secret Sprawl Challenge for the broader risk pattern.
Security teams often underestimate how quickly a single pipeline compromise becomes a credential collection event. A runner, action, or plugin that can read environment variables, mounted files, or vault responses can exfiltrate tokens faster than manual review detects the change. That is why the issue is not only code execution, but identity concentration: build systems often hold the keys needed to impersonate workloads elsewhere. Current guidance from NIST Cybersecurity Framework 2.0 still applies, but it has to be translated into pipeline-specific controls. In practice, many security teams encounter this only after a compromised workflow has already minted deploy access or pulled production secrets.
How It Works in Practice
Attackers target CI/CD because these systems are designed to authenticate to many downstream services with very little human friction. A single job may have access to package registries, container signing keys, cloud APIs, Kubernetes credentials, and source-control tokens. If the job can run arbitrary code, it can often enumerate secrets from the environment, fetch them from logs, or abuse build steps to pivot into adjacent systems. The problem is not just exposed credentials, but the trust chain that allows those credentials to be used broadly.
One useful benchmark is the scale of the exposure problem: NHI Mgmt Group cites that Ultimate Guide to NHIs reports 80% of identity breaches involving compromised non-human identities. That helps explain why pipeline abuse remains so effective. In operational terms, defenders should separate build, test, and deploy identities; issue short-lived tokens per job; and make every secret retrieval auditable. Where possible, use workload identity rather than static shared credentials, and keep runtime permissions narrower than what the human developer can access.
Practical controls usually include:
- JIT credentials for each pipeline stage, rather than long-lived tokens stored in runner images.
- Per-repository or per-environment workload identity, so a test job cannot impersonate a production deployer.
- Secret scanning plus automated revocation, because detection without revocation leaves valid access in place.
- Policy checks at run time, not just at merge time, because the pipeline context changes during execution.
This aligns with the NIST view of continuous risk management and with supply-chain guidance in CI/CD pipeline exploitation case study and NIST Cybersecurity Framework 2.0. These controls tend to break down when shared runners, broad admin tokens, and ad hoc scripts are still allowed to reach production systems directly.
Common Variations and Edge Cases
Tighter pipeline control often increases release friction, requiring organisations to balance delivery speed against blast-radius reduction. That tradeoff is real, especially in teams that rely on ephemeral preview environments, GitOps, or heavily parameterised build templates. Best practice is evolving here, and there is no universal standard for how much autonomy a pipeline should have before it becomes a security liability.
Edge cases show up when CI/CD is also used for infrastructure changes, signed artifact promotion, or AI-assisted development. In those environments, the pipeline may not just store secrets; it may also decide which secrets to request, which increases the value of intent review and runtime authorisation. The right control is not always a larger vault. Sometimes it is narrower scope, shorter TTL, and stronger separation between human approval and machine execution. For agent-like build automation, that can resemble the same workload-identity pattern discussed in Ultimate Guide to NHIs and the attack patterns documented in the 52 NHI Breaches Analysis.
Two additional points matter in practice. First, private repositories are not automatically safe just because they are not public; internal systems often contain the most reusable secrets. Second, if a toolchain includes third-party actions, package hooks, or shared runners, the trust boundary expands beyond the organisation’s own code. Security teams should treat those dependencies as part of the identity surface, not just the software supply chain. That is where many CI/CD controls fail: the environment is trusted for convenience long before it is trusted for resilience.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Pipeline secrets need rotation and short-lived use to limit NHI abuse. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central to stopping pipeline credential sprawl. |
| NIST Zero Trust (SP 800-207) | SC-2 | Zero trust limits lateral movement when a runner or action is compromised. |
Replace static CI/CD credentials with short-lived NHI tokens and enforce rotation on every pipeline trust boundary.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
