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

At a glance

What this is: This is Boost Security’s analysis of a May 2026 supply chain attack wave, with the key finding that compromised CI/CD and developer credentials are now the main multiplier for downstream poisoning.

Why it matters: It matters because IAM, PAM, and NHI governance teams need to treat developer tokens, pipeline secrets, and third-party build actions as shared attack surface, not isolated tooling details.

By the numbers:

• 27 days
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read Boost Security's analysis of the May 2026 supply chain attack wave

Context

Supply chain security fails fast when trust is extended to build tools, package registries, and CI/CD jobs without strong credential boundaries. In practice, the problem is not only malicious code, but the secrets that let attackers move from one compromised workflow to the next, including developer tokens, signing keys, and cloud access.

This article sits squarely at the intersection of supply chain security and NHI governance because the assets being abused are machine credentials rather than human accounts. The pattern described here is typical of modern pipeline compromise, where one stolen secret can enable repository tampering, package poisoning, and production pivoting.

The first-order governance question is how much standing trust a software factory still grants to actions, plugins, runners, and developer workstations. Once those identities are treated as high-value NHIs, the control problem becomes lifecycle, scope, and blast-radius management, not just code review.

Key questions

Q: Why do compromised CI/CD credentials make supply chain attacks much worse?

A: CI/CD credentials often sit at the centre of publish, build, and deployment workflows, so one stolen token can reach many repositories and environments. If those credentials are not scoped, rotated, and monitored like privileged identities, attackers can use them to publish malicious packages, access secrets, and spread laterally across trusted automation.

Q: Why do developer workstations increase supply-chain risk so quickly?

A: Developer workstations concentrate source code, cloud credentials, CI/CD secrets, SSH keys, and repository permissions in one place. When an attacker compromises that endpoint, the impact is not limited to the laptop itself. The stolen identity material can be reused to modify code, access services, and push compromise downstream into customers and production pipelines.

Q: What do security teams get wrong about identity provenance?

A: They often treat provenance as metadata instead of a control boundary. If users cannot see which fields are verified, self-asserted, or unavailable, the verifier cannot make a sound trust decision. Provenance has to be visible at the point of release, not buried in logs or back-end records.

Q: Who is accountable when a compromised build identity poisons downstream software?

A: Accountability usually sits with both platform owners and application owners because the failure spans identity governance, pipeline hardening, and release approval. The right control lens is to treat build identities as governed NHIs with explicit ownership, revocation paths, and audit coverage. If no owner can rotate or retire them, the risk is already unmanaged.

Technical breakdown

How CI/CD credential theft turns one compromise into many

CI/CD pipelines concentrate trust. A compromised action, plugin, or build step can expose tokens already present in the runner environment, then use those tokens to write to repositories, publish packages, or access cloud services. This is why supply chain attackers increasingly target the build system itself, not just the artifact. The technical issue is that pipeline identities often inherit broad permissions and short-lived execution still leaves behind reusable secrets in logs, caches, and environment variables.

Practical implication: move high-value credentials out of pipeline runtime paths and limit every runner to the minimum token scope needed for one job.

Why credential harvesting in developer environments is so effective

Developer endpoints are rich credential reservoirs. Saved browser sessions, SSH keys, cloud CLI tokens, package manager tokens, and password vault exports can all be harvested once malware or a malicious extension reaches the workstation. From there, attackers do not need to break the application directly. They reuse trusted identities to sign packages, approve releases, or open a second intrusion path through infrastructure that already trusts the developer.

Practical implication: treat developer workstations as privileged identity endpoints and isolate build and release credentials from general user sessions.

Why provenance alone does not stop supply chain abuse

Build provenance helps prove where software came from, but it does not automatically stop a trusted pipeline identity from being abused. Attackers can still poison approved workflows if they steal the right credentials, exploit token reuse, or compromise signing steps. Provenance is therefore a verification layer, not a lifecycle control. It needs to be paired with secret containment, short-lived access, and explicit release approval boundaries.

Practical implication: pair provenance controls with secret rotation, signing key protection, and narrow pipeline identity scope.

Threat narrative

Attacker objective: The attacker wants trusted software distribution channels and the credentials behind them, so one compromise can spread malware, backdoors, and access to many downstream targets.

1. Entry begins with compromise of a CI pipeline, developer workstation, or malicious package update that reaches trusted build infrastructure.
2. Credential access follows as attackers harvest tokens, SSH keys, cloud credentials, password vault data, and other secrets exposed during build or runtime execution.
3. Escalation occurs when those credentials are reused to tamper with repositories, publish malicious versions, or pivot into production and signing systems.
4. Impact is downstream software poisoning at scale, along with broader credential compromise across repositories, CI/CD platforms, and cloud environments.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Supply chain security has become an identity problem disguised as a code problem. The article shows that attackers are not only poisoning packages, they are harvesting the machine identities that make software delivery possible. Once CI tokens, developer SSH keys, and cloud credentials are in play, the attack shifts from artifact integrity to identity governance. Practitioners should treat build identities as governed NHIs with lifecycle, scope, and offboarding requirements.

Secret sprawl is now a measurable blast-radius multiplier. The more places secrets live, the more opportunities attackers have to capture one useful credential and fan out across environments. This is why secret rotation alone is insufficient if tokens remain embedded in runners, browser sessions, and developer tooling. The governance failure is assuming a single control point can protect a distributed identity estate. Practitioners should centralise secret policy across endpoint, SCM, and CI/CD layers.

Pipeline trust needs explicit boundaries, not inherited convenience. Modern software factories often grant actions, plugins, and build jobs more access than they need because automation was designed for speed. That design choice becomes brittle when attackers can write to repositories, inject code into trusted jobs, or abuse signing workflows. The named concept here is pipeline identity sprawl: too many semi-trusted execution identities with too much latent privilege. Practitioners should narrow every pipeline identity to one bounded task.

Provenance and detection are only as strong as the credential boundary underneath them. The article’s timeline shows that even strong build attestations can coexist with token theft and package abuse if secrets are reachable during execution. Frameworks such as OWASP Non-Human Identity Top 10 and MITRE ATT&CK are useful here because they force teams to map where credential access, lateral movement, and release tampering actually occur. Practitioners should align provenance with identity containment, not substitute one for the other.

Security teams should stop treating developer tooling as a low-risk zone. The article’s repeated emphasis on extensions, package managers, vaults, and CLI tokens reflects a broader shift in attacker tradecraft toward identity-rich tooling. That means governance, monitoring, and revocation processes must cover the software factory end to end. Practitioners should assume compromise paths begin where developers work, not only where applications run.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• For related analysis: The ratio of machine identities to human identities now exceeds 100:1 in many enterprise environments, which is why Top 10 NHI Issues remains relevant as the identity layer expands.

What this signals

Pipeline identity sprawl is becoming a governance issue that crosses AppSec, IAM, and PAM. When build jobs, developer workstations, and package registries all carry reusable credentials, the programme needs one policy view for issuance, scope, and revocation instead of fragmented owner-by-owner decisions.

The practical next step is to align supply chain controls with identity controls already used elsewhere in the enterprise. Mapping these paths against the MITRE ATT&CK Enterprise Matrix helps teams see where credential access turns into lateral movement, while the OWASP Non-Human Identity Top 10 gives a useful lens for secret sprawl and overprivilege.

As supply chain attacks increasingly target the software factory itself, security teams should expect more pressure to shorten secret lifetime, constrain release identities, and monitor developer tooling as a privileged environment. The programmes that move first will be the ones that treat token containment as a resilience control, not a hygiene task.

For practitioners

• Inventory every credential-bearing software factory identity Map service accounts, GitHub tokens, signing keys, package manager tokens, and cloud credentials across developer endpoints, SCM, CI/CD, and release systems so owners can see where trust is actually concentrated.
• Reduce runner privilege to single-job scope Issue short-lived credentials only for the specific build or release step that needs them, and block reuse across jobs, repositories, or environments.
• Separate developer and release identities Keep workstation credentials, package publishing rights, and signing permissions in distinct identity paths so one compromised endpoint cannot immediately publish or sign software.
• Harden inbound package and action ingestion Inspect every new dependency, GitHub Action, VS Code extension, npm package, or PyPI artifact before it can execute in runners or on developer endpoints, with explicit allowlists for trusted sources.
• Build revocation playbooks for secret theft events Predefine how to rotate tokens, invalidate sessions, and suspend pipeline identities when a repo, extension, or workstation is suspected of compromise, because delay turns one stolen secret into many.

Key takeaways

• This supply chain wave shows that credential theft inside the software factory can be more damaging than the initial package compromise.
• The scale of the problem is amplified by long secret-remediation times and developer behaviour gaps that attackers are built to exploit.
• Teams that separate developer, build, and release identities will shrink blast radius faster than teams that only harden individual tools.

Key terms

• Pipeline Identity Sprawl: Pipeline identity sprawl is the accumulation of workflow permissions, service tokens, machine accounts, and event triggers across software delivery systems. It creates hidden privilege relationships that are often managed more loosely than human access and are therefore easier for attackers to abuse.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Software Factory: The end-to-end delivery environment that turns source code into released software, including repositories, CI/CD systems, build runners, signing services, and deployment automation. In security terms, it is a high-trust identity zone that needs strong lifecycle and privilege boundaries.

What's in the full article

Boost Security's full blog covers the operational detail this post intentionally leaves for the source:

• Timeline details on the May 2026 supply chain attacks and the sequence of affected ecosystems.
• Specific examples of compromised packages, CI platforms, and developer tooling mentioned in the article.
• The article's own recommended defensive measures for pipeline hardening and secret exposure reduction.
• The list of organizations named as early victims and what was compromised in each case.

👉 The full Boost Security post covers the timeline, affected tools, and attack patterns in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is designed for practitioners who need to govern trusted automation across modern security programmes.