How to spot software supply chain attacks and stop worms-before it's too late

Nataniil/DigitalVision Vectors/Getty Images

Follow ZDNET: Add us as a preferred source on Google.

ZDNET's key takeaways

• Shai-Hulud is the worst-ever npm JavaScript attack.
• This software supply chain worm attack is still ongoing.
• Here are some ways you can prevent such attacks.

For those of you who aren't Dune fans, Shai-Hulud are the giant sandworms of the desert planet Arrakis. You do not want to get in their way. Now, it's also the name of a self-replicating worm that compromised at least 180 npm packages, and perhaps as many as 500 of them.

This is a major security crisis for anyone who programs in JavaScript and the JavaScript runtime environment Node.js. JavaScript, by the way, is one of the most popular programming languages. This supply chain attack hits pretty much all JavaScript developers.

Also: This 2FA phishing scam pwned a developer - and endangered billions of npm downloads

That's because Node Package Manager (npm) is JavaScript's default package manager and software registry. It enables developers to install, manage, and share packages -- prebuilt pieces of reusable code called modules -- that their JavaScript or Node.js projects depend on. Npm is the largest such open-source package library. Essentially, everyone who uses JavaScript uses it.

Npm also has a horrible security track record. Month after month, year after year, hackers have successfully inserted malicious code into npm modules. This, in turn, means that corrupted code is automatically introduced into JavaScript-based programs used by end users.

The most recent example of this was a week ago, when a phishing attack compromised 18 packages that were downloaded two billion times a week. This week's attack is much worse. How bad? We don't know exactly. The security experts are still working it out, and while the worm has slowed down, it hasn't stopped yet.

How a software supply chain attack works

A software supply chain attack happens when an attacker compromises software during its development by inserting malicious code into its components before it reaches end users. Instead of attacking programmers or users directly, attackers exploit vulnerabilities in trusted third-party vendors, libraries, or development tools that developers rely on. When compromised software or updates are delivered, often automatically, to customers, the malicious payload can impact many victims simultaneously.

Also: Your password manager is under attack: How to defend yourself against a new threat

These attacks are hazardous because:

• They leverage trusted relationships, enabling attackers to bypass direct security controls.
• One successful compromise can affect thousands or millions of users, as their software includes tainted dependencies or code.
• Modern organizations often use hundreds of third-party libraries or services, meaning a single breach in the chain may have exponential effects.

As an end user, you don't see this until it blows up in your face when you update a program or service you use every day, and it suddenly goes wrong. Or, as is far more likely, it starts mining Bitcoin on your server, starts stealing your company's customer data, or installs ransomware.

Shai-Hulud Attacks

For instance, in this case, the package tinycolor was one of the first compromised programs to be spotted. All it does is change a program's colors. That's it. It's downloaded, on average, 2.2 million times per week to be used in tens of thousands of programs.

The infected version of tinycolor, and all the other packages, were automatically pulled into -- we have no idea how many -- programs. Once there, they deployed a malicious package with a worm. While they were installing, a script scanned the environment for secrets such as npm tokens, GitHub credentials, and cloud service application programming interface (API) keys, such as those for AWS and Google Cloud.

Also: The best password managers for businesses in 2025: Expert tested

It then used these secrets to pass them on to attacker-controlled endpoints. Then they created public GitHub repositories containing the stolen data, all labeled "Shai-Hulud."

Using these secrets, especially the stolen npm tokens, the worm then authenticated as each compromised developer, scanned for other npm packages they maintained, injected its code, and published new, malicious versions. This way, the worm kept spreading and spreading and... well, you get the idea.

This led to exponential spread, affecting immensely popular libraries with billions of weekly downloads and hitting projects belonging to companies such as the security company CrowdStrike.

Keep in mind the name of the company's game is protecting companies from such breaches. It also comes just a year after a CrowdStrike update infamously crashed tens of millions of Windows PCs, leading to the largest wave of Blue Screens of Death ever.

Also: 7 password rules security experts live by in 2025 - the last one might surprise you

Adding insult to injury, the malware often installed the open-source Trufflehog tool to hunt for further secrets and private GitHub repositories. Once it found these private repositories, it created public clones of them. Then, as a security company, ReversingLabs put it, "Each newly created package is modified with a postinstall action that will execute the malicious bundle.js when an unsuspecting user downloads the compromised package. This is repeated in perpetuity as the worm finds new developers to infect, and then uses them to spread even further." And on and on it went.

The total scope of the outbreak is still unknown. At least 700 GitHub repositories have had secrets exposed due to the worm's actions.

Also: Your Android phone's most powerful security feature is hidden and off by default - turn it on now

How bad is it really? Developer security company Chainguard CEO Dan Lorenc wrote on LinkedIn, "This wave of npm attacks feels different... I'm hearing from more than a few companies freezing development/ingest until they get this sorted out." That is not business as usual.

Npm maintainers and affected companies are scrambling to remove malicious packages, rotate credentials, and warn the developer community. Security vendors such as Palo Alto Networks, Trend Micro, and CrowdStrike have issued emergency guidance, recommending strong credential security, immediate token rotations, and malware scans for any systems that may have installed npm packages in recent days.

How to prevent software supply chain attacks

Software supply chain attacks have become commonplace. They're not new. We've been slow to recognize how dangerous these attacks are. We should have learned our lesson in 2020, when we discovered Russian-linked attackers breached SolarWinds and penetrated thousands of SolarWinds customers via malicious code injected into the company's network monitoring software.

We didn't. So, here's how you can slow down supply chain attacks, if not prevent them entirely.

Also: 3 reasons VPN use is set to explode worldwide - and that might apply to you

For starters, here's the cold, hard truth. If you're a developer, you can't blindly trust your dependencies anymore. Period. End of statement. Yes, I know Linus' Law, "Given enough eyeballs, all bugs are shallow," and you do. But it only works if there are enough eyeballs. You can drop the naive notion that open source means secure software. In the best case, that's true, but blindly trusting in programs from npm or any other public software repository is just asking for trouble.

So, accept that open-source dependencies are now a core part of your risk profile. Start treating software consumption seriously: Set policy, track everything you use with a living software bill of materials (SBOM), and keep those components on a short leash.

Also: Navigating AI-powered cyber threats in 2025: 4 expert security tips for businesses

You must also stop updating your components automatically to whatever the newest version is. Instead, only update to up-to-date, supported versions. As the OpenSSF put it in the Open Source Consumption Manifesto, you must understand the real risks of blindly using open-source code.

Let's get practical and specific.

1. Harden development and build environments

• Limit access to development tools and build systems to only those who need them. That means enforcing strong and multifactor authentication everywhere.
• Keep all Continuous Integration and Continuous Delivery (CI/CD) infrastructure fully patched, and run builds on clean, isolated environments (such as containers or ephemeral Virtual Machines (VMs)).
• Audit and lock down access to secrets, like API keys and tokens, so they're never exposed in repositories or logs. And, when I say "never," I mean never.

2. Map and manage all dependencies

• Maintain an SBOM for every project; track all dependencies. Yes, all of them -- yes, direct and transitive.
• Only use well-maintained, trusted open-source packages. Check provenance and vendor reputation before adding new components.
• Automate periodic scanning for vulnerabilities with Software Composition Analysis (SCA) tools. Remove or patch flagged dependencies immediately.

3. Secure the CI/CD pipeline

• Integrate static, dynamic, and interactive security scans into CI/CD pipelines so every commit and pull request is automatically tested for vulnerabilities.
• Use role-based access control (RBAC) for build and deployment resources. Regularly audit permissions according to least privilege.
• Sign, verify, and periodically review all software artifacts, ensuring updates come from trusted sources and build reproducibility is maintained.

4. Monitor, educate, and respond

• Deploy real-time threat intelligence feeds and monitor for anomalies in build pipelines, repositories, and application behavior.
• Provide ongoing training for developers on secure coding, social engineering, and supply chain attack awareness.
• Test your response plan by simulating breaches and running incident drills, ensuring you're ready to react swiftly when threats arise. Note, I said "when," not "if" -- "when."
• Audit everything. If there's a sniff of a Common Vulnerabilities and Exposures (CVE), don't wait to respond. Test, patch, and, if need be, quarantine the affected code.

5. Collaborate upstream and downstream

• Engage with upstream maintainers and vendor support for rapid fixes. Don't wait for public exploits to appear. Open source only works well when we all work on it. You can't just assume all's well upstream.
• Assess suppliers, partners, and critical third-party tools for compliance with supply chain security best practices. Require SBOMs and regular security reviews.

By following these steps and embedding security into every phase of your software development, you'll dramatically lower your exposure to software supply chain attacks. The way they're coming so fast and often, you may still face them, but at least you'll have lessened your exposure. Good luck. We're all going to need it.