Because they are governed by non-human identities with broad access to code, registries, and deployment systems. If those identities have standing credentials or overbroad scopes, patch automation can become a privileged attack path. The security issue is not just the software artefact, but the identity permissions that move that artefact through production.
Why This Matters for Security Teams
Build and release pipelines sit in a high-trust zone because they move code from source control into registries, test environments, and production deployment paths. That makes them attractive to attackers who want to tamper with artifacts, inject malicious dependencies, or reuse pipeline credentials for lateral movement. The risk is rarely the pipeline software alone. It is usually the identity model around it, including service accounts, API tokens, signing keys, and automation scopes.
Security teams often miss this because pipeline access looks operational rather than privileged. A token with “just enough” rights for one workflow can still become a production-grade credential if it is reused, long-lived, or visible to too many systems. Guidance from the OWASP Non-Human Identity Top 10 is clear that machine identities need the same governance discipline as human users, especially where secrets and trust boundaries overlap. In practice, many security teams encounter pipeline identity abuse only after a release channel has already been used as the shortest path into production, rather than through intentional control testing.
How It Works in Practice
Pipeline identity risk usually starts with one of three patterns: standing credentials, excessive permissions, or poor secret handling. A CI job may be allowed to pull source code, access artifact repositories, sign packages, and trigger deployment. If that same job also has broad write access, any compromise in the build stage can be converted into trusted release activity. That is why release governance is a supply chain security issue as much as a DevOps issue.
Operationally, the safest pattern is to treat each pipeline step as a distinct identity with a narrow purpose. Build, test, sign, and deploy should not all share one credential set unless there is a documented control justification. Secrets should be short-lived where possible, stored in a dedicated secrets manager, and rotated when a pipeline definition changes. Stronger designs also separate human approval from machine execution so that a compromised automation token cannot silently approve its own promotion path. The NIST Cybersecurity Framework 2.0 is useful here because it pushes teams to connect identity control, change integrity, monitoring, and recovery into one operating model.
- Use distinct non-human identities for build, sign, and deploy stages.
- Scope tokens to one repository, one environment, or one action where feasible.
- Store signing keys and release secrets outside pipeline logs and job output.
- Require artifact provenance and verification before deployment.
- Monitor for unusual token use, failed auth bursts, and unexpected release timing.
Where supply chain maturity is higher, teams also bind pipeline actions to attestation and policy checks so that artifact integrity is validated before promotion. Current guidance suggests that identity-aware controls work best when combined with provenance, change approval, and runtime monitoring rather than used as isolated hardening steps. These controls tend to break down in fast-moving multi-cloud environments because shared runners, inherited roles, and ad hoc secret injection make it difficult to prove which identity performed each release action.
Common Variations and Edge Cases
Tighter pipeline identity controls often increase release friction, requiring organisations to balance delivery speed against blast-radius reduction. That tradeoff is real, especially when teams rely on ephemeral infrastructure, temporary credentials, or cross-account deployments. Best practice is evolving, and there is no universal standard for exactly how much privilege a pipeline should hold at each stage.
Some environments need broader access for practical reasons. For example, legacy build systems may not support fine-grained identity boundaries, and regulated release processes may require stronger approval chains around signing or production promotion. In those cases, compensating controls matter: strict secret vaulting, immutable logging, separation of duties, and review of pipeline configuration changes. The OWASP Non-Human Identity Top 10 is especially relevant when organisations inherit long-lived service accounts, while NIST guidance is more helpful for mapping those risks into broader governance and recovery expectations.
Edge cases also appear in container and infrastructure-as-code pipelines. A single compromised runner can inherit credentials for registry pushes, cloud deployment, and secret retrieval if the environment is not isolated. That is why many teams are moving toward short-lived workload identities and policy-bound execution, but implementation quality varies widely. The practical question is not whether the pipeline is automated. It is whether every automation step can be traced to a controlled identity with a limited purpose and a revocable trust relationship.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF 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 | Pipeline service accounts and tokens are non-human identities that need tight governance. | |
| NIST CSF 2.0 | PR.AA | Identity and access management is central to controlling release pipeline privilege. |
| NIST AI RMF | Automated decisioning and tooling inside pipelines should be governed for risk and accountability. | |
| NIST Zero Trust (SP 800-207) | PDP/PEP | Zero trust helps limit what a compromised pipeline identity can reach. |
| MITRE ATT&CK | T1195 | Supply chain compromise patterns map well to build and release pipeline abuse. |
Inventory each pipeline identity, shrink its scope, and rotate or retire credentials quickly.
Related resources from NHI Mgmt Group
- How should security teams reduce supply chain risk in GitHub-based development pipelines?
- Why do developer workspaces create supply-chain risk when identity is misvalidated?
- Why do GitHub-based supply chain attacks create identity risk for cloud environments?
- Why do parallel build jobs create governance risk in identity tooling pipelines?
