Why do CI/CD pipelines with standing privileges create such a large blast radius in cloud environments?

Why This Matters for Security Teams

Standing privileges in CI/CD are dangerous because pipelines are not passive systems. They authenticate to source control, secret stores, artifact registries, cloud APIs, and sometimes production environments, so one compromised job can become an infrastructure-level foothold. In cloud environments, that matters more than a simple token leak because the pipeline can chain permissions, discover more secrets, and invoke automation faster than a human can respond. The OWASP Non-Human Identity Top 10 treats over-privileged machine identities as a primary risk, and NHIMG research on the CI/CD pipeline exploitation case study shows how attackers turn build trust into broad cloud access.

CI/CD systems also create blast radius through persistence. Long-lived secrets, broad deploy roles, and cached credentials can survive beyond a single build, so compromise is not bounded to one run. The Guide to the Secret Sprawl Challenge describes how secrets spread across pipelines, runners, and service accounts until no one can say which workflow can reach which environment. In practice, many security teams encounter the blast radius only after a build runner has already minted cloud credentials and touched multiple downstream systems.

How It Works in Practice

The problem is not just that a pipeline has access. It is that the access is usually standing, reusable, and broader than the current task requires. A typical workflow may read repository secrets, assume a cloud role, push to a container registry, and trigger deployment tooling. If an attacker modifies the workflow, injects a malicious action, or steals a runner token, they inherit the same trust path.

That trust path often expands the blast radius in three ways:

• Persistent credentials can be replayed long after the original job completes.
• Broad cloud roles let one compromised pipeline move from build systems into storage, databases, or production clusters.
• Shared automation identities make it hard to tell which action was legitimate and which was attacker-driven.

Current guidance suggests replacing standing privileges with short-lived, task-specific access, enforced through workload identity and runtime policy evaluation. For cloud-native pipelines, that means using ephemeral tokens, tightly scoped service accounts, and just-in-time access for the exact deployment step. In implementation terms, teams should prefer identity primitives that prove what the pipeline is, not what password it knows, such as OIDC-based federation or SPIFFE-style workload identity. The operational goal is to make each build or deployment request independently authorized rather than permanently trusted.

The Ultimate Guide to NHIs aligns with the same principle: machine identities should be scoped, revocable, and observable across the full automation chain. These controls tend to break down when legacy deployment scripts depend on reusable admin tokens because the pipeline then becomes a durable bridge into the rest of the cloud estate.

Common Variations and Edge Cases

Tighter pipeline privilege often increases delivery friction, so organisations have to balance velocity against containment. That tradeoff is real, especially where teams manage many environments, frequent releases, or third-party build integrations. Best practice is evolving, but there is no universal standard for exactly how much permission a pipeline should receive; the safe answer depends on the deployment model, rollback design, and how much automation touches production.

Two common edge cases deserve attention. First, break-glass deployment tokens are sometimes justified for incident response, but they should be isolated, heavily monitored, and time-bound, not left as routine defaults. Second, multi-stage pipelines may need different identities for build, test, and deploy. Collapsing all stages into one broadly privileged identity is convenient, but it creates unnecessary lateral movement opportunities if any stage is compromised.

NHIMG’s research on the 2026 Infrastructure Identity Survey found that 70% of organisations grant AI systems more access than a human performing the same job, which is a useful warning sign for CI/CD too: automation tends to be over-trusted when teams optimise for speed. The practical fix is to segment identities by task, shorten token lifetimes, and require policy checks at request time rather than assuming a pipeline is safe because it started from trusted code.

Related resources from NHI Mgmt Group

• Why do exposed secrets in CI/CD pipelines create such a large blast radius?
• Why do CI/CD secrets create such a large blast radius in supply chain attacks?
• Why do exposed NHI secrets create such a large blast radius in cloud environments?
• Why do malicious CI/CD workflows create such a large blast radius?