Why do malicious CI/CD workflows create such a large blast radius?

Because build pipelines often sit at the intersection of source code, package publishing, and cloud access. If one trusted workflow can read multiple credentials, the attacker can reuse those secrets across registries, environments, and downstream automation. The blast radius is large because the identities are already pre-authorised.

Why This Matters for Security Teams

Malicious CI/CD workflows are dangerous because build systems are trusted by design and often sit directly on the path from source control to production release. Once a workflow can read package tokens, cloud credentials, signing keys, or deployment secrets, the attacker inherits that trust and can move across registries, environments, and automation boundaries. That is why supply chain incidents tend to spread faster than ordinary account compromise. NIST’s Cybersecurity Framework 2.0 emphasizes managing risk across the full lifecycle, but CI/CD often remains the least visible control plane.

NHIMG’s CI/CD pipeline exploitation case study shows how quickly a trusted workflow can become a credential distribution point rather than just a build step. The practical mistake is assuming pipeline identity is narrow or ephemeral when, in many organisations, it is neither. In practice, many security teams encounter the real blast radius only after secrets have already been replayed into multiple systems.

How It Works in Practice

The blast radius grows because CI/CD identities are usually pre-authorised for speed. A workflow may have read access to source, permission to fetch dependencies, rights to publish artifacts, and access to cloud or Kubernetes credentials. If an attacker injects malicious steps, modifies an action, or compromises a dependency, the workflow itself becomes the execution vehicle.

The most reliable way to reduce this risk is to treat pipeline access as a workload identity problem, not just a secrets problem. Current guidance suggests combining short-lived workload identity, just-in-time credential issuance, and policy evaluation at request time. That means the workflow proves what it is using cryptographic identity, then receives narrowly scoped secrets only for the task at hand. Static tokens should be replaced wherever possible with ephemeral credentials that expire quickly and are revoked automatically when the job ends.

Operationally, this usually includes:

• Separating build, test, sign, and deploy identities instead of using one broad runner role.
• Issuing time-bound credentials per job rather than storing long-lived secrets in pipeline variables.
• Restricting token scope so a compromised workflow cannot publish to every registry or environment.
• Evaluating policy at runtime based on repository, branch, environment, actor, and artifact lineage.

That approach aligns with the patterns discussed in NHIMG’s Guide to the Secret Sprawl Challenge and with NIST Cybersecurity Framework 2.0 principles for reducing privilege and improving recovery. It also matches the direction of modern supply chain hardening, where the trust decision happens at execution time rather than at pipeline creation. These controls tend to break down when runners are shared across projects and the same identity can reach both build systems and production secrets, because compromise in one job immediately becomes compromise everywhere.

Common Variations and Edge Cases

Tighter pipeline controls often increase deployment friction, requiring organisations to balance delivery speed against containment. That tradeoff becomes sharper in monorepos, multi-tenant runners, and release automation that spans several cloud accounts. There is no universal standard for every CI/CD pattern yet, so best practice is evolving around least privilege, environment separation, and ephemeral secret delivery rather than one fixed template.

One common edge case is a “trusted” internal action or reusable workflow. Internal does not mean safe if the action can be updated without review or can transitively pull in unpinned code. Another edge case is secret rotation without revocation. NHIMG research in the 2024 State of Secrets Management Survey found that the average time to mitigate a leaked secret is 36 hours, which is long enough for a compromised pipeline token to be replayed widely if it is not automatically scoped and expired.

Where multiple registries, signing systems, and deployment targets are chained together, the blast radius is not just the first secret stolen but every downstream system that trusts the same workflow identity. The strongest control is to assume each job may be hostile and limit what it can reach by design.

Related resources from NHI Mgmt Group

• Why can a single SaaS app create such a large blast radius?
• Why do CI/CD secrets create such a large blast radius in supply chain attacks?
• Why do exposed secrets in CI/CD pipelines create such a large blast radius?
• Why do stolen CI tokens and publishing tokens create such a large blast radius?