Npm attacks have come into focus over the past several weeks; recent hits like eslint-prettier, Nx, and chalk proved how significant and damaging these events can be. The “Shai-Hulud” campaign threw in a new twist: the malicious package replicated itself, demonstrating a worm-like behavior.

Once a developer’s credentials were compromised, the malware attempted to spread automatically to other packages under their account. This creates a massive attack surface that must be considered as we continue to see malware being pushed to npm and PyPI.

Why npm keeps getting targeted

Npm’s popularity makes it a prime target for cybercriminals: millions of developers depend on it daily. Npm and PyPI have infamous installation hooks, which get automatically executed once a package is installed. This makes it very trivial for attackers to actually execute malicious payload compared to other ecosystems.

As we’ve seen from these recent attacks, the blast radius potential is massive. Even a single compromised package is able to spread malware through various organizations across the software supply chain. As noted in the paper “Small World with High Risks,” this is because 1) Highly popular packages directly or indirectly influence many other packages - often upwards of 100,000 - making it the ideal target for injecting malware. 2) Given that some maintainers influence hundreds of thousands of packages, a very small number of compromised maintainer accounts is all attackers need to inject malware into the majority.

One of the main characteristics of the npm ecosystem is the high number of transitive dependencies. For example, when using the core of the popular Spring web framework in Java, a developer transitively depends on ten other packages. In contrast, the Express.js web framework transitively depends on 47 other packages.

How npm plays out

These events follow a similar pattern. According to the Taxonomy of Attacks on Open-Source Software Supply Chains, there are typically three high-level attack vectors:

Once installation hooks are executed, malicious code runs automatically on every developer machine or CI system that pulls the package. While auditing every version is technically possible, doing so at scale is very hard in practice.

Remedying the Issue

What’s clear is that centralized gatekeeping is not a practical solution. We can’t have one party dictate that something is good or secure enough to be published and distributed. Instead, we need to make it easier for maintainers to follow best practices and for consumers to verify security.

These attacks have spurred conversations emphasizing the need of 2FA , attestations, and signing, which are key to protecting maintainer accounts and tracking artifacts’ provenance. What’s also important, however, is to make such features usable without putting additional effort on maintainers’ shoulders.

Usable security is important, however, ease-of-use and security are often at odds, especially when it comes to shortening token lifetimes and MFA. Several measures released by npm in response to Shai Hulud will indeed  mitigate future instances and thereby maintain the integrity of open source–but they will also require a bit more effort from npm developers:

The bottom line is that if you’re writing JavaScript every day, you are on the front line of npm security. Developers need to work closely with organization leaders to create guardrails against  malicious code. There are a few best practices to keep in mind, one being cooldown periods, which are supported by more and more solutions, e.g., pnpm. They help to prevent upgrading to (and downloading) versions that have been published in the last couple of days– the timeframe during which most of the malicious packages are discovered and taken-down.

It’s also important to reduce the number of dependencies used. In practice, that means choosing a single library for each use case instead of pulling in multiple tools that do the same thing, and removing dependencies that are no longer needed after refactoring. Technologies like reachability analysis/call graph analysis are helpful to identify unused software dependencies in your packages.

Lastly, being attentive and watching for red flags, specifically being wary if a small package suddenly ships a huge change, adds an install script, or changes maintainers without explanation. While critical, this step is increasingly difficult to manage at scale without proper tool support. This is exactly what is difficult to do at scale -- unless there's proper tool support. Modern AppSec solutions should provide these health indicators for all the application dependencies to ensure proper monitoring can be executed at scale.

These attacks should serve as a lesson: it’s not if your team will face risk, but when. That’s why it’s so critical for the entire open source ecosystem - from OSS maintainers and OSS consumers to third parties like registries to all apply best practices. Ultimately, focusing on reducing the probability of the compromise and minimizing its reach is the most important thing developers and security leaders can do . Understanding how these recent npm attacks  unfolded will help signal a way forward for a more secure software supply chain.