Supply chain attacks are turning CI/CD credentials into blast radius

At a glance

What this is: Boost Security’s analysis says May 2026 supply chain activity is shifting from package tampering to credential theft inside CI/CD and developer environments.

Why it matters: For IAM and NHI practitioners, the issue is that CI/CD tokens, developer credentials, and inherited pipeline trust can turn a single compromise into broad blast radius.

Context

Supply chain security fails when trusted build steps, package feeds, and developer tooling can silently inherit access to credentials that were never meant to travel that far. In this article, Boost Security argues that the real problem is not only malicious code entering the pipeline, but the way CI/CD environments concentrate privilege, secrets, and downstream trust.

That becomes an identity governance problem as soon as CI/CD tokens, service credentials, and developer sessions are reusable across repositories, signing steps, and production paths. The May 2026 wave described here is typical of a broader pattern: attackers are treating pipelines as credential reservoirs, not just software delivery systems.

Key questions

Q: What fails when CI/CD credentials are exposed through the supply chain?

A: The failure is not just secret leakage, but identity reuse at scale. Once pipeline tokens or developer sessions are harvested, attackers can publish packages, clone repositories, or reach production paths that trust the same credentials. The practical break point is that one execution context can inherit more privilege than it should ever have had.

Q: Why do stolen pipeline secrets create such a large blast radius?

A: Stolen pipeline secrets create a large blast radius because they often carry permissions that were designed for convenience, not containment. If a single token can access code, cloud infrastructure, and adjacent services, every authorised action after theft looks legitimate. The risk rises sharply when the same identity is reused across environments or left active too long.

Q: What are the signs that CI/CD trust is being misused?

A: Look for unexpected workflow changes, unfamiliar package sources, sudden token revocations, unusual publishing activity, and secrets appearing where they should never be visible. A pipeline that regularly executes third-party code with broad access, or that cannot explain who can reach signing and deployment credentials, is already outside a safe trust boundary.

Q: How should teams govern supply chain risk in CI/CD environments?

A: Use separate identities for build, sign, and deploy, and make credential scope as narrow as the task allows. Governance should cover what can execute, what can authenticate, and what can be reused after execution. If a workflow can both run untrusted code and reach production, the control boundary is too loose.

Technical breakdown

Why CI/CD credentials become high-value supply chain targets

CI/CD environments often hold more privilege than developers realise. Build systems authenticate to source control, artifact registries, cloud APIs, signing services, and deployment targets, which makes them ideal pivot points for attackers who have already entered through a compromised package, plugin, or workflow. Once a token or session is captured, the attacker does not need to keep exploiting the initial foothold. They can reuse that identity to publish malicious artifacts, clone repositories, or reach production paths that are normally separated from everyday development access.

Practical implication: Treat pipeline credentials as production-grade identities, not convenience tokens.

How malicious packages and workflow abuse extract secrets at scale

A supply chain compromise becomes far more dangerous when malicious code executes inside the same environments that store or pass secrets. The article describes credential theft through poisoned build tools, compromised actions, and trojanised packages, all of which run where secrets are already present in memory, logs, caches, or environment variables. This is why the attack surface is not just the package itself but the entire trust chain around ingestion, execution, and export. The more often code is installed or executed automatically, the more opportunities an attacker gets to harvest credentials without needing direct interactive access.

Practical implication: Restrict what executes in build and test paths, especially where secrets are exposed to runtime.

Why provenance alone does not close the blast radius

Provenance controls such as artifact signing and build attestation help with integrity, but they do not solve the problem of credential exposure once an attacker is already inside a trusted workflow. A signed malicious artifact can still be dangerous if it was produced from stolen tokens or if downstream systems automatically trust the identity that created it. That is why the article stresses hardening the pipeline itself, not just verifying the output. In practice, the trust boundary has shifted from the artifact to the credential chain that created and promoted it.

Practical implication: Pair provenance with short-lived credentials, strict pipeline scoping, and rapid token revocation.

Threat narrative

Attacker objective: The attacker wants reusable credentials that let them compromise additional packages, tamper with releases, and expand from one pipeline foothold into broader software supply chain access.

1. Entry occurs through compromised supply chain components such as malicious packages, trojanised plugins, or poisoned workflow steps that execute inside trusted developer and CI/CD environments.
2. Credential access follows when the payload harvests CI/CD tokens, developer sessions, cloud credentials, signing keys, or stored secrets from logs, memory, caches, and environment variables.
3. Escalation and lateral movement happen when those stolen identities are reused to publish packages, rewrite repositories, or pivot into production and other trusted systems.
4. Impact is broad downstream compromise, including poisoned releases, backdoored code, and platform-wide secret rotation across affected environments.

Breaches seen in the wild

• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.
• Trivy supply chain attack 2026: A PAT stolen via a Trivy workflow and a botched rotation let TeamPCP poison Trivy releases and Action tags to steal CI/CD secrets.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI/CD credentials are now part of the supply chain attack surface: once build systems authenticate to registries, repos, and cloud services, they become a standing identity layer that attackers can harvest and reuse. The article shows that supply chain compromise is no longer just about shipping bad code, it is about turning trusted pipeline identities into reusable access paths. Practitioners should govern pipeline credentials as high-value non-human identities.

Blast-radius control is now the decisive supply chain control: the key question is no longer whether a malicious package can run, but how far its stolen credentials can travel after execution. That shifts the governance emphasis toward credential scoping, short-lived access, and strict separation between build, signing, and production identities. The practitioner takeaway is to design every pipeline step as if the previous step can be compromised.

Provenance without credential containment is incomplete: signed artifacts and SLSA-style integrity measures reduce tampering, but they do not stop a stolen token from publishing, cloning, or promoting malicious software. This article reinforces a hard truth for identity teams: supply chain integrity and credential governance must be treated as a single control problem. Practitioners should align software provenance with NHI lifecycle controls.

Third-party exposure creates the supply chain trust gap: the article’s picture of widely shared tools, package ecosystems, and developer dependencies shows why third-party access is now a governance issue, not just a vendor risk issue. When external actors can touch the same pipeline paths as internal teams, offboarding, rotation, and least privilege become supply chain controls. Practitioners should inventory every external identity path that can reach CI/CD.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Key Research and Survey Results

What this signals

Supply chain attacks now need to be treated as identity events as much as code integrity events: once a CI/CD token or developer session can reach multiple systems, the compromise is no longer contained to a package repository. Practitioners should expect attackers to target the identity layer that sits underneath build automation, not just the code being delivered.

Blast-radius control needs to move upstream into issuance time: access reviews are too late when credentials are stolen during execution and immediately reused. The better control point is where tokens are created, scoped, and allowed to touch runners, registries, and production endpoints.

Third-party exposure remains the weak link in supply chain governance: when external tools and dependencies can reach internal build paths, third-party access becomes a non-human identity problem as well as a vendor risk problem. Teams should map every external identity path that can authenticate into CI/CD.

For practitioners

• Map CI/CD identities as non-human identities Inventory every token, service account, OIDC trust, and signing credential used by build, test, release, and deployment workflows. Classify each one by system, owner, purpose, and downstream reach so you can see where a single compromise would spread.
• Reduce reusable credential exposure in pipelines Replace long-lived CI/CD secrets with short-lived, task-scoped credentials wherever possible, and remove credentials from logs, caches, and build-time environment variables. Focus first on runners and actions that can reach cloud, registry, or production APIs.
• Tighten what code can execute automatically Restrict package sources, marketplace actions, and developer extensions that can run inside trusted build environments. Require review for new dependencies and workflow changes that can inherit secret access or publish artifacts.
• Harden token revocation and rotation workflows Create a rapid response path for revoking CI/CD tokens, signing keys, and developer sessions when supply chain abuse is suspected. Make sure rollback and reissue procedures are tested before an incident, not during one.
• Separate build, signing, and production trust paths Use distinct identities and approvals for packaging, signing, and deployment so one compromised workflow cannot automatically reach production. The goal is to narrow blast radius when an upstream tool or dependency is poisoned.

Key takeaways

• Supply chain compromise now centers on stolen CI/CD credentials, not just malicious code, because pipeline identities can reach repositories, registries, and production systems.
• The article describes a pattern in which one trusted execution path can feed multiple later attacks, making blast radius the main governance problem.
• Reducing risk means narrowing credential scope, separating build and deployment trust paths, and revoking pipeline identities quickly when abuse is suspected.

Key terms

• CI/CD Credential Broker: A CI/CD system that does more than build and deploy because it also stores or issues credentials for cloud and application access. In practice, this creates a hidden identity tier inside delivery infrastructure, where compromise of the pipeline can expose downstream permissions.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Software Supply Chain Trust Boundary: The software supply chain trust boundary is the point where an organization decides which software components, build systems, dependencies, and delivery steps it will trust. It defines where verification must occur. Technically, it includes source, build, signing, packaging, distribution, and update paths, plus the identities and controls that govern each stage.
• Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.

Deepen your knowledge

NHI Mgmt Group's NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners align identity controls with the operational realities of pipelines, services, and delegated access.