Because delivery systems rely on accounts and tokens that can approve, modify, and push changes without human involvement. If those privileges persist or overlap, a compromise in one stage can cascade into the next. The risk is not just code tampering, but trust propagation across build, release, and production systems.
Why This Matters for Security Teams
DevSecOps pipelines are often treated as safe because they are automated, but automation concentrates trust into a small set of identities, tokens, and service accounts. When those identities can read source, trigger builds, approve deployments, or update infrastructure, they become high-value targets. That is why NHI governance is central here, not optional. The OWASP Non-Human Identity Top 10 is useful because it frames pipeline credentials as identities that need lifecycle control, not just secret storage.
The practical risk is privilege propagation. A token that is acceptable in a build stage may become dangerous if it can reach release tooling, cloud control planes, package registries, or signing services. Security teams often miss this because access reviews focus on human users while leaving machine identities, ephemeral runners, and integration accounts largely ungoverned. The result is a pipeline that can be trusted to move fast, but not to fail safely. As a baseline, the NIST Cybersecurity Framework 2.0 pushes organisations to manage identity as part of overall risk, not as a narrow admin task. In practice, many security teams encounter pipeline compromise only after a build token has already been reused to reach production, rather than through intentional scope design.
How It Works in Practice
The right question is not whether the pipeline needs access, but which exact action each identity must perform and for how long. In mature environments, each stage should use a distinct non-human identity with narrowly defined permissions, short-lived credentials where possible, and explicit separation between build, test, signing, and deployment. The same principle applies to runners, orchestration jobs, API tokens, and external integrations such as artifact repositories and cloud APIs. NIST control families in NIST SP 800-53 Rev 5 Security and Privacy Controls are relevant here because they translate cleanly into access enforcement, auditability, and configuration integrity.
Operationally, teams should treat pipeline identities like production identities:
- Use separate service accounts for source control, CI execution, artifact signing, and deployment.
- Scope each token to a single repository, environment, or API action where possible.
- Prefer ephemeral credentials and automatic rotation over static secrets embedded in variables or images.
- Log every privileged action and link it to a specific pipeline run, commit, or change request.
- Block lateral movement between stages unless a policy engine or approval gate explicitly allows it.
That design reduces blast radius and makes anomaly detection more meaningful, because unusual access stands out against a constrained baseline. It also supports the control intent described in the OWASP NHI guidance, where identity lifecycle, authorization boundaries, and secret exposure are treated as interconnected risks. These controls tend to break down when legacy CI systems reuse one shared deploy token across multiple environments because the pipeline then has no meaningful separation between routine automation and privileged release authority.
Common Variations and Edge Cases
Tighter access scoping often increases operational overhead, requiring organisations to balance release speed against the cost of more identities, more approvals, and more secret rotation. That tradeoff is real, especially in fast-moving DevSecOps environments where teams want low-friction deployments.
Best practice is evolving for ephemeral runners, AI-assisted code generation, and agentic automation, and there is no universal standard for this yet. Some organisations use just-in-time elevation for deployment jobs, while others rely on policy-as-code and workload identity federation to avoid long-lived secrets altogether. The most important distinction is whether the pipeline can be replayed or abused outside its intended context. Shared runners, multi-tenant build farms, and cross-account deployment patterns make this harder because trust boundaries blur quickly.
Identity risk also increases when pipeline permissions overlap with signing keys, package publishing, or infrastructure provisioning. In those cases, a single compromised credential can alter code, metadata, and runtime state at once. For teams aligning to broader cyber resilience, the same principles that underpin NIST Cybersecurity Framework 2.0 apply: reduce exposure, verify continuously, and contain compromise before it propagates across environments.
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 SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-1 | Pipeline service accounts and tokens are non-human identities needing lifecycle control. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege is central to limiting pipeline identity blast radius. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege control directly maps to scoping DevSecOps machine accounts. |
Inventory every pipeline identity, assign an owner, and rotate or retire credentials on a strict schedule.
