Why do CI/CD secrets create such a large blast radius in supply chain attacks?

CI/CD secrets are often shared across build, publish, and cloud tasks, so one exposed token can touch many systems at once. In this incident, the same compromise path reached GitHub, npm, AWS, GCP, Azure, Vault, SSH, and database credentials. That makes token scope and runner isolation central to blast-radius reduction.

Why This Matters for Security Teams

CI/CD secrets are dangerous because they are not just passwords in transit. They are the credentials that let build systems publish packages, sign artifacts, assume cloud roles, query vaults, and reach deployment targets. Once a secret is reused across build, test, release, and runtime tasks, compromise stops being a single account issue and becomes a supply chain issue. Current guidance from OWASP Non-Human Identity Top 10 and NHIMG’s CI/CD pipeline exploitation case study both point to the same pattern: token scope and runner trust boundaries define the blast radius more than the initial foothold.

The practical problem is that pipelines often run with broad, durable credentials because they are convenient for automation. That creates a hidden coupling between unrelated systems, so one leaked token can become a chain of downstream access. NHIMG research in The State of Secrets Sprawl 2026 shows how persistent and widely distributed secrets can be, which is why revocation and isolation matter as much as detection. In practice, many security teams encounter the full blast radius only after a runner, package workflow, or release job has already touched multiple environments.

How It Works in Practice

The blast radius grows when secrets are treated as reusable infrastructure rather than task-specific proof. A build job may need access to a package registry, a signing key, a cloud role, and a vault path. If the same credential can satisfy all of those requests, an attacker who steals it can move laterally without needing to break additional controls. That is why static secrets and shared service accounts are so risky in pipelines: they collapse separation of duties into one token.

Better practice is to narrow each secret to one workflow step, one runner, one repository, or one environment. Short-lived credentials reduce the time window, while workload identity proves what the runner or agent is before access is granted. Standards and implementation guidance increasingly point toward ephemeral tokens, identity federation, and policy evaluated at request time rather than pre-issued standing access. For example, CISA cyber threat advisories consistently emphasize credential theft and token abuse as common intrusion paths, while NHIMG’s 52 NHI Breaches Analysis shows how non-human credentials are repeatedly used as the pivot point in real incidents.

• Issue per-job, ephemeral credentials instead of reusing one long-lived pipeline token.
• Bind secrets to runner identity, environment, and task scope.
• Separate build, publish, and deployment privileges so compromise in one stage does not expose all stages.
• Revoke on completion and verify that downstream systems do not cache the original credential.
• Log every secret access event so anomalous cross-system use can be detected quickly.

These controls tend to break down when self-hosted runners are shared across projects, because the runner itself becomes the trust boundary and any secret available to that host may be reachable by multiple pipelines.

Common Variations and Edge Cases

Tighter secret scoping often increases operational overhead, requiring organisations to balance lower blast radius against more complex pipeline design. That tradeoff is real, especially when teams rely on monolithic release jobs or legacy deploy tooling. There is no universal standard for this yet, but current guidance suggests treating release credentials as the most constrained class because they can directly affect production signing, package publication, and infrastructure control.

Edge cases matter. Some teams use OIDC federation for cloud access but still store long-lived registry keys in secrets managers, which leaves the weakest secret as the true attack path. Others isolate runners but let jobs fetch broad vault policies at runtime, which recreates the same problem with a different control plane. The best answer is not simply “use a secrets manager.” It is to map every secret to the exact privilege it enables and remove any credential that can be replayed across systems. NHIMG’s Guide to the Secret Sprawl Challenge and the Shai Hulud npm malware campaign show how quickly exposed pipeline secrets can become multi-system access paths once attackers chain them together.

In mixed environments, the hardest cases are ephemeral containers, shared runners, and nested workflows, because credential lifetimes and execution boundaries no longer line up cleanly.

Related resources from NHI Mgmt Group

• Why do npm supply chain attacks create such a large blast radius?
• Why can a single SaaS app create such a large blast radius?
• Why do SaaS supply-chain attacks create a larger blast radius than direct account compromise?
• Why do supply-chain attacks create such a large IAM and NHI risk?