Open source supply chain attacks are now a daily build risk

At a glance

What this is: StepSecurity’s year-long review shows open source supply chain attacks have become frequent, self-propagating, and tightly linked to credential theft in build pipelines.

Why it matters: IAM, PAM, and NHI teams need to treat developer tokens, GitHub Actions credentials, and CI runner secrets as high-value identities because supply chain compromise is now an identity problem as much as a software problem.

By the numbers:

• Over the last 12 months, the StepSecurity threat intelligence team tracked and alerted on 56 distinct supply chain attacks.
• In March 2026 the rate jumped to 13 incidents in a single month and has stayed high since: 9 in April, 9 in May, 10 in June, 6 in July.
• In March 2026, the threat actor Team PCP ran a five day campaign, March 19 to 24, built on a simple loop.

👉 Read StepSecurity's analysis of open source supply chain attacks in 2026

Context

Open source supply chain attacks now target the trust boundary between developers, registries, and CI/CD runners. The core problem is not simply malicious code, but malicious code delivered through trusted update paths that execute before production controls can intervene.

For identity and access teams, that means package ecosystems, GitHub Actions, and build runners have become identity-bearing attack surfaces. The same governance gaps that affect NHI sprawl, token lifecycle control, and secrets exposure now apply inside software delivery pipelines, where a single compromised credential can cascade across many repositories and environments.

Key questions

Q: What breaks when a compromised package executes during import in CI/CD pipelines?

A: Import-time execution collapses the usual separation between dependency loading and code execution. Once the package runs on import, it can read environment variables, load companion payloads, and start secondary behaviour before most scanners or approval gates have any chance to intervene. The control failure is trusting package installation or import as a safe, passive step.

Q: Why do supply chain attacks matter to NHI governance?

A: Because many supply chain compromises succeed through non-human identities, such as integrations, tokens, and service accounts, rather than through a user login. NHI governance determines whether those identities are scoped narrowly, rotated, monitored, and removed when no longer needed. Without that control, supplier compromise becomes enterprise compromise.

Q: How do security teams know whether secrets in CI/CD are actually controlled?

A: Look for three signals: how many secrets a workflow can reach, how long those secrets remain valid, and whether any of them can publish or sign artefacts. If a build job can touch long-lived credentials or production systems, the environment is not controlled. The objective is to reduce reachable secrets and shorten exposure windows.

Q: Who is accountable when a trusted upstream package is poisoned?

A: Accountability usually spans the publishing organisation, the platform team that allowed persistent release credentials, and the security team that failed to govern supply chain trust end to end. Frameworks such as NIST CSF and NIST SP 800-53 expect access control, monitoring, and lifecycle management for high-risk identities and release paths.

Technical breakdown

Why malicious packages are different from vulnerable packages

A vulnerable package contains a flaw that might be exploited later if the right code path is reachable. A malicious package is the attack itself. It runs at install time, often in a developer workstation or CI runner, and can steal secrets immediately without waiting for production execution. That difference changes the defensive model: software composition analysis is useful for vulnerable dependencies, but it is too late for code that is already executing during build or test. In supply chain attacks, the important control point is execution-time trust, not post-deployment scanning.

Practical implication: block untrusted packages before install and monitor for execution-time secret access in developer and CI environments.

How worms amplify credential theft across package ecosystems

A supply chain worm uses one stolen credential to compromise the next maintainer, package, or workflow, then repeats the process automatically. That creates a compounding attack pattern where one infected version can seed many downstream compromises across registries such as npm, PyPI, RubyGems, Composer, and crates.io. Mutable tags make the problem worse because a maintained reference can be silently repointed to malicious code. The mechanism is closer to credential propagation than classic malware distribution, which is why package trust, maintainer identity, and token protection all matter at once.

Practical implication: enforce immutable release references, harden maintainer accounts, and assume one exposed token can become many compromised packages.

Why CI/CD runners are a high-value identity target

CI/CD systems hold short-lived tokens, cloud keys, signing material, and repository credentials in memory while jobs run. Attackers increasingly ship stealers that execute inside the runner, dump those secrets, and exfiltrate them before the job completes. Once an attacker has pipeline credentials, they can push malicious workflows, move into adjacent repositories, or harvest additional secrets from other builds. This is an identity problem because the runner is acting on behalf of many high-trust workloads at once, often with more privilege than a human user would ever receive.

Practical implication: reduce runner privilege, isolate build identities, and add egress controls that prevent stolen secrets from leaving the pipeline.

Threat narrative

Attacker objective: The attacker wants to convert trusted software distribution paths into credential harvesting infrastructure that can propagate compromise across many organisations at once.

1. Entry begins when an attacker compromises a trusted package, poisoned GitHub Action, or maintainer account and delivers malicious code through an accepted update path.
2. Credential harvested occurs when the malicious code executes inside a developer machine or CI runner and dumps tokens, cloud keys, or signing secrets from memory.
3. Escalation follows when stolen credentials are reused to repoint tags, publish additional malicious versions, or plant workflows across repositories the victim can access.
4. Impact is ecosystem-wide compromise of build systems, with secrets theft, repository takeovers, and downstream package infections spreading beyond the initial target.

Breaches seen in the wild

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

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 compromise is now an identity governance problem, not just a software trust problem. The report shows attackers are targeting the credentials that let packages, actions, and runners act with authority. That shifts the control question from 'is the package safe?' to 'which identities can this pipeline use, and how are they bounded?' Practitioners should treat build identities as governed assets, not background infrastructure.

Mutable trust references create a standing privilege window for attackers. When tags can be repointed or maintained credentials can be reused without lifecycle control, the ecosystem effectively grants persistent authority to whoever controls the reference. That is a classic NHI failure mode: trust persists longer than the legitimate task requires. The named concept here is trusted release drift, where legitimate update paths become attacker-controlled execution paths. Practitioners should tighten release immutability and maintainer authentication.

CI/CD environments now resemble privileged agent estates. Runners, workflow tokens, and package hooks all act on behalf of the organisation, often with broad reach into code, cloud, and signing systems. That makes secrets management, token scoping, and runtime monitoring central to governance. The article reinforces OWASP NHI guidance on credential lifecycle discipline and aligns with the MITRE ATT&CK view of credential access and lateral movement as the core threat pattern. Practitioners should align pipeline controls to the same governance standard they would apply to any privileged non-human identity.

Worm behaviour changes the risk model from single compromise to compounding exposure. Once one maintainer or token can seed many downstream packages, incident response and offboarding assumptions break down. The right unit of governance is no longer a repository or a single package, but the full chain of identities that can publish, install, or execute code. Practitioners should re-evaluate how much blast radius any one developer or automation account can reach.

AI tooling expands the attack surface of software supply chains. The report’s references to AI-enabled abuse and AI infrastructure packages show that model-adjacent tooling now inherits the same identity and secrets risks as traditional developer tooling. As organisations embed AI into delivery pipelines, they should expect the same token theft patterns to affect model calls, orchestration layers, and agent-facing automation. Practitioners should govern AI-connected build paths as part of the broader NHI estate.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, according to The State of Secrets in AppSec.
• 75% of organisations express strong confidence in their secrets management capabilities, even as leaked secrets still persist for weeks.
• That gap between confidence and remediation speed makes 52 NHI Breaches Analysis a useful next step for understanding how credential exposure becomes breach amplification.

What this signals

Trusted release drift: when update paths remain mutable, governance has to treat package distribution as a privilege boundary. For teams that rely on CI/CD, the practical issue is not whether a dependency is popular but whether its authority can be repurposed after compromise. Aligning with the OWASP Non-Human Identity Top 10 is a sensible way to connect package trust, token lifecycle, and blast-radius control.

The remediation gap matters because exposed secrets age into additional compromise opportunities. If the average leaked secret still takes 27 days to remediate, attackers have ample time to reuse tokens, repoint tags, or plant workflows across repositories. That is why build environments need both MITRE ATT&CK Enterprise Matrix style detection and identity-level containment, not just dependency scanning.

For practitioners, the shift is toward governed execution, not only governed code. If the build system can execute untrusted content, then pipeline identities need the same lifecycle discipline as other privileged non-human identities, including expiry, scoping, and revocation. The most durable control is to make secret theft non-operative by combining runner egress restrictions with strong identity controls.

For practitioners

• Inventory every pipeline identity and secret source Map which package managers, GitHub Actions, runners, and deployment jobs can access cloud keys, signing keys, and repository tokens. Treat each as a non-human identity with an owner, scope, and expiry.
• Restrict mutable release trust Replace tag-based trust with immutable versions, verified provenance, and explicit approval for package and action updates. Where tags remain necessary, monitor for repointing and block unexpected publisher changes.
• Contain secret exfiltration at the runner Apply egress restrictions and secret-detection policies to CI/CD runners so a malicious dependency cannot call out with dumped credentials. Pair this with least-privilege tokens and short-lived credentials for build jobs.
• Separate maintainer authority from build authority Reduce the blast radius of a compromised maintainer account by limiting which repositories, actions, and registries a single identity can touch. Use strong authentication, scoped publishing rights, and revocation playbooks for maintainer tokens.
• Test supply chain assumptions against worm-style propagation Run tabletop scenarios that assume one compromised token can infect multiple packages or repositories. Validate how quickly your organisation can revoke credentials, halt publishing, and detect repointed tags across ecosystems.

Key takeaways

• Open source supply chain attacks now behave like identity attacks because attackers are targeting the secrets and tokens that make trusted automation work.
• The report’s 56 incidents in 12 months, plus the jump to a roughly three-day attack cadence, show that this is now a recurring operational risk rather than an edge case.
• Practitioners should focus on immutable trust, short-lived build identities, and runner-level exfiltration controls to reduce the blast radius of the next compromise.

Key terms

• Trusted Release Drift: Trusted release drift is the condition where a legitimate update path can be repurposed after compromise. In supply chain attacks, tags, package versions, and workflow references stay trusted even after the underlying maintainer account or token has been stolen, letting attacker-controlled code inherit that trust.
• Build identity: The set of credentials, tokens, keys, and permissions used by CI/CD systems, runners, and developer tooling. Build identity is often overlooked, yet it can expose secrets, alter repositories, and propagate compromise into downstream software if not tightly scoped and monitored.
• Secret Exfiltration Path: Any route by which sensitive material can leave an environment after it has been read, including shell commands, web requests, diagrams, logs, or rendered outputs. In AI-assisted workflows, the exfiltration path can be created by the assistant itself if output controls are too permissive.
• Mutable Tag Risk: A weakness that appears when a version tag can be moved to a different commit after consumers have already trusted it. In supply chain terms, the tag is treated like a fixed reference even though the underlying code can change, which undermines reproducibility and provenance.

What's in the full report

StepSecurity's full report covers the operational detail this post intentionally leaves for the source:

• Month-by-month incident timeline from August 2025 through August 2026 with the specific ecosystems affected
• Per-campaign breakdowns for Shai-Hulud, Team PCP, Miasma, and other worm-style attacks
• Examples of how malicious packages stole CI/CD secrets from runner memory and propagated further compromise
• Runtime detection and blocking controls used to catch poisoned packages, repointed tags, and outbound exfiltration

👉 StepSecurity's full report covers the timeline, worm behaviour, and CI/CD secret theft patterns in more 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 connect identity governance to operational security decisions across modern environments.