Shai-Hulud, npm, and modern software supply chains

In September 2025, the npm ecosystem experienced one of the most consequential software supply-chain compromises to date. A self-propagating worm, now commonly referred to as Shai-Hulud, compromised hundreds of npm packages, harvested developer and CI/CD credentials, and used those credentials to spread laterally across the ecosystem by publishing further malicious updates under the identities of legitimate maintainers. Within weeks, a second wave followed, often called “Shai-Hulud 2.0” which refined the original techniques, removed earlier bottlenecks, and dramatically increased the scale of the attack, ultimately affecting hundreds of packages and tens of thousands of GitHub repositories.

How the Attack Worked: Credential Theft and Worm-Like Propagation

Researchers have now well documented the technical mechanics of the attack. Attackers commonly gained initial access through phishing or stolen tokens, then injected malicious code into npm packages, often using lifecycle hooks such as preinstall or postinstall scripts. Once executed, the malware searched developer machines and CI environments for secrets, including npm tokens, GitHub personal access tokens, SSH keys, and cloud provider credentials, and exfiltrated them to attacker-controlled GitHub repositories. In many cases, the malware also installed or modified GitHub Actions workflows to establish persistence and continue harvesting secrets over time. The most novel aspect lies in the worm-like propagation mechanism: when the malware found valid npm credentials, it automatically published malicious versions of other packages owned by the compromised maintainer, turning normal package publishing workflows into an amplification vector.

Exploiting Trust Assumptions in Modern Software Development

What makes Shai-Hulud particularly significant is not merely its scale, but the fact that it did not rely on exploiting a single vulnerability or a novel flaw in npm itself. Instead, it exploited a set of deeply embedded assumptions that underpin modern software development. Developers assume that a package name delivers the code they expect, that legitimate maintainers author published packages, that distributed artifacts match the reviewed source code, and that CI/CD systems serve only the projects they belong to. These assumptions are not accidental; they are what make large-scale reuse of open source software possible. Yet Shai-Hulud demonstrated how easily these assumptions can be weaponized once identity and automation are compromised.

Immediate Responses: Dependency Auditing, SBOMs, and Their Limits

In the immediate aftermath of the attack, guidance from vendors and public authorities consistently emphasized dependency auditing, version pinning, credential rotation, and the use of lockfiles to identify affected components. This response was appropriate, but it is important to be precise about what these measures can and cannot achieve. Software Bills of Materials (SBOM) and Software Composition Analysis (SCA) tools effectively answer questions such as whether a system contains a given package or version, when someone introduced it, and how widely it propagated across environments. In other words, these tools play an essential role in incident response, scoping, and remediation. Without accurate dependency inventories, many organizations could not determine whether attackers affected them at all.

SBOMs as Visibility Infrastructure, Not Preventive Control

While SBOMs and SCA do not detect malicious intent in newly published packages, they play a critical role once malicious activity or a vulnerable component is identified. They do not prevent credential theft in CI/CD environments, nor do they guarantee that a published artifact faithfully reflects reviewed source code. When a compromised package version is tracked in vulnerability or threat intelligence databases, SBOMs enable organizations to quickly determine exposure across products and dependency trees, supporting containment, remediation, and impact minimization. This way, SBOMs are infrastructure for visibility and accountability, and the necessary first step towards preventive security mechanisms.

Automation, AI, and the Acceleration of Supply Chain Risk

The broader context in which Shai-Hulud occurred is one of rapidly increasing automation in software development, including the growing use of AI-assisted coding and analysis. Automation lowers the cost of publishing, updating, and integrating code, while AI tools lower the barrier to producing large volumes of code and changes quickly. These developments can meaningfully improve productivity, and there are concrete examples of AI being used to produce high quality analysis when combined with review. However, another concern is that large language models are fundamentally nondeterministic systems that do not provide semantic guarantees in the way compilers or traditional tooling do.

When Automation Scales Mistakes, Not Just Productivity

This distinction matters for supply chain security because nondeterministic systems can confidently produce changes that appear plausible while subtly violating assumptions, invariants, or security properties that are not explicit in the code itself. When such outputs are integrated into automated pipelines without sufficient review, the result is not merely faster development, but faster propagation of mistakes. In supply chain terms, this mirrors the dynamics seen in Shai-Hulud: automation magnifies both legitimate activity and abuse, and small errors or compromises can scale into systemic incidents.

Why Process-Oriented Regulation Matters: Lessons for the Cyber Resilience Act

It is in this context that regulatory initiatives such as the EU Cyber Resilience Act should be understood. The CRA does not promise vulnerability-free software, nor does it prohibit the use of open source, automation, or AI. Instead, it emphasizes secure development processes, traceability of components, vulnerability handling, and post-market responsibility. Shai-Hulud provides a concrete illustration of why this process oriented approach exists. The core failure was not the presence of a specific vulnerability, but a breakdown in identity trust, credential handling, and automated distribution mechanisms that allowed an incident to propagate faster than organizations could reason about its impact.

Introducing Friction to Improve Ecosystem Resilience

A recurring theme in post-incident analysis is the need to introduce deliberate friction into software supply chains, such as minimum release ages, stronger defaults for authentication, short-lived credentials, build attestations, and stricter controls over CI/CD workflows. These measures do not eliminate risk, but they slow propagation and create space for detection, review, and response. In practice, resilience often depends less on preventing every failure than on ensuring that failures do not immediately cascade across the ecosystem.

From Detection to Verification: Building Evidence-Based Trust

Ultimately, no single defense can stop sophisticated supply chain attacks. But visibility is the enabler of all others. Defenses must therefore go beyond detection to verification. Trusted publishing workflows, ephemeral credentials, and digital attestations like those emerged in PyPI’s Trusted Publishing initiative. and crates.io.  SBOMs and dependency scanning provide the initial map. They tell you what’s inside the box before you can determine if it’s safe. They enable proactive blocking, informed patching, and swift triage. At Bitsea, we are integrating similar concepts into our open source curation toolkit OCCTET, helping organizations track origin, changes, and risk across the software lifecycle.

Conclusion: Making Software Supply Chain Trust Explicit

Shai-Hulud is a wake-up call to build systems where trust is not just implicit, but evidence-based. You begin that journey by answering foundational questions such as what’s in your software, where it comes from, and how you maintain it.

If you need help understanding your software supply chain trust assumptions, Bitsea supports organizations in making those assumptions explicit and reviewable. This includes analyzing dependency trees and SBOMs, auditing open source components and build artifacts, and assessing compliance obligations under laws like the Cyber Resilience Act.