Being the Dune groupie that I am, I couldn’t pass up the chance to comment on the so-called “Shai-Hulud” NPM attacks. What a clever name for a worm attack. But as the saying goes, “The spice must flow,” so let’s sift through what’s really going on — and what it means for software supply chain security.

Why Open Source Package Managers are a Security Battleground

Let’s get something straight: NPM (Node Package Manager) isn’t just a convenience for JavaScript devs — it’s the central nervous system for millions of modern applications. With a single `npm install`, developers wire in mountains of code, trusting the crowd to get it right and keep it clean. However, every dependency presents a fresh surface for attack, and attackers have taken note.

NPM’s magnitude — literally millions of packages—makes it a uniquely juicy target. Decentralized oversight and an always-on firehose of new packages mean malicious actors only need to get lucky once. If your organization’s devs aren’t verifying what’s in those packages and where they came from, you’re flirting with disaster. And let’s be honest, most teams aren’t.

Surge in Supply Chain Attacks: The Shai-Hulud Worm Joins a Growing List

If it feels like supply chain attacks are ramping up, you’re not imagining things. Recent incidents have shown how vulnerable our open source dependencies are: from typosquatting and hijacked maintainer credentials to confusion attacks deliberately manipulating dependency resolution. The Shai-Hulud incident — the third NPM-centric supply chain breach in as many months — is just the latest wake-up call.

Unlike previous attacks aimed at a single package or publisher, Shai-Hulud operates as a self-replicating worm. It doesn’t just grab a foothold; it spreads. Targeting multiple high-profile packages — including, but not limited to, CrowdStrike-branded modules — this malware copies itself across projects, steals identity credentials and quickly multiplies the blast radius. Other companies were affected as well, showing this worm’s ambition goes far beyond any single vendor.

Expert Analysis: Time for a Fundamental Software Supply Chain Security Shift

Matt Saunders, VP of DevOps at Adaptavist, puts it bluntly:

While keeping dependencies up-to-date to get security fixes is critical, this same stance leaves companies vulnerable to introducing Trojan horses, as this incident shows. It’s not enough to just ‘pin’ versions of software… This also needs to be combined with cryptographic checks to ensure that we’re getting what we think we’re getting when downloading code. Furthermore, with AI introducing new and sneaky ways of shipping malicious code, simply scanning for known vulnerabilities isn’t enough to catch them all. Using an external manifest of known ‘blessed’ versions is the only way to go. Fortunately, the technology exists for open-source maintainers and distributors to add the necessary scrutiny to their releases through notarizing their code and shipping a software bill of materials (SBOM). In the wake of attacks like this, the importance of having SBOMs in place becomes even more imperative. Seeing these worms self-replicate also shines a light on build environments… We can expect to see more scrutiny around these, with zero-trust principles applied more widely to prevent malicious code from spreading further.

And as Mitch Ashley of The Futurum Group warns:

2025’s NPM supply-chain attacks are a stark reminder that open-source infrastructure is now part of every organization’s critical supply chain. This wave of self-replicating malware underscores the need for stronger developer security hygiene, broader adoption of SBOMs and automated dependency scanning, and, most urgently, multi-factor authentication and signed package publishing across the JavaScript ecosystem. Without these controls, expect more of the same.

Protecting Your Organization: Supply Chain Security Action Plan

Let’s be candid: The days of “Just trust your dependencies” are long gone. Here’s what actionable supply chain security looks like in 2025 and beyond:

• Don’t rely on default settings or the latest versions alone. Always verify the provenance and integrity of every package.
• Automate SBOM creation and validation. Require maintainers and suppliers to provide notarized code and regularly updated Software Bill of Materials.
• Adopt zero-trust for build environments. Limit permissions, monitor access closely and watch for lateral movement — worms love wide-open sandboxes.
• Mandate multi-factor authentication (MFA) and signed package publishing for any interaction with public repositories.
• Continuous monitoring and automated dependency scanning are non-negotiable — not just for known CVEs, but for unexpected behavior and outlier patterns.

Hard Truths and the Path Forward

If the last three NPM attacks have taught us anything, it’s that compromise is a when, not an if. We must approach software supply chain security with the same seriousness we give to anything else in our critical infrastructure — no more blind trust in the crowd, no more “set it and forget it.”

The “spice” of modern software — the speed, the agility, the near-instant innovation — will only keep flowing if we’re willing to get serious about supply chain defense. Secure your builds, verify your sources, and remember: In the desert of open source, worms grow fast — and they’re coming for you.