NPM attacks and the security of software supply chains

If you needed another reminder that our software supply chains are only as strong as their smallest link, the JavaScript ecosystem delivered it. In early September, attackers phished the NPM account of “Qix,” a prolific maintainer, then pushed tainted releases of 18 popular packages: ansi-styles, debug, chalk, supports-color, and others, which are collectively responsible for more than 2 billion weekly downloads. The malware wasn’t particularly sophisticated, and the window of exposure was brief (roughly two hours) before the maintainer and registry intervened. Even so, the situation raises uncomfortable questions about open source’s supply chain risk.

On the positive side, the community did what open source communities often do. They spotted the anomalies fast and neutralized the problem before it metastasized. I’ve argued for years that the process of open source—transparency, review at scale, the habit of fixing in the open—is an optimal guarantor of security.

That said, it should not be so easy to hijack code that lands in millions of production environments every week. Even with two-factor authentication (2FA) more common today, a convincing phishing email can still turn a popular package into a Trojan horse. As JFrog’s CTO said, in regards to the incident, this is the ugly reality of a JavaScript ecosystem in which “half of the codebase is dependent on single-line utilities maintained by a single developer.” That’s not a dunk on small, composable libraries; it’s a sober assessment of risk.

Just days after “Qix,” the NPM ecosystem faced something arguably more menacing: “Shai-Hulud,” a self-replicating worm that spread between packages by stealing author tokens and seeding back doors through hidden CI (continuous integration) workflows. It’s a supply-chain attack designed to propagate as it compromises. The campaign touched hundreds of packages, underscoring that phishing one maintainer isn’t a one-off fluke; it’s an attack pattern.

We’ve been here before

We’re now far enough into the “supply chain security” era that this feels familiar. In 2022, I wrote that developers “have a supply chain security problem” because it’s simply too efficient for attackers to compromise a dependency once and pivot into every app that transitively depends on it. This isn’t something easily fixed by money either, because adversaries innovate, attack surfaces explode, and any static prescription underperforms a dynamic threat.

We need, in other words, process improvements to strengthen security, not one-off cash donations.

That’s not to say funding is irrelevant—far from it. In fact, the NPM incident is an indictment of how under-resourced much of our critical open source is. Far too often, underpaid (or unpaid) maintainers are doing the unsexy but essential work for open source that keeps the internet upright. It’s not glamorous. It’s essential. And it’s exactly where most organizations that depend on open source fail to invest.

Is the answer to improve funding mechanisms for open source? Sort of. Consider Open Policy Agent. As a project, OPA thrived: graduated by the Cloud Native Computing Foundation and embedded across Kubernetes clusters, microservices, and gateways as a standard policy engine. As a business, however, the story is more complicated. Styra, the company that commercialized OPA, raised significant capital to build enterprise tools, but earlier this month, multiple reports indicated Apple hired OPA’s cofounders and several core engineers. OPA remains open under CNCF governance, but Styra’s commercial pathway looks uncertain, and customers are evaluating alternatives. Great project, hard business.

This is not unique. As Graham Neray, CEO of Oso, explained to me:

OPA is widely used, so you expect to see it work out—you want to see that work out. The reality is you can count on two hands the number of commercially successful open source businesses operating at scale. Even among those, all have had questions about their commercial viability at one point or another. Contrary to popular belief, there are no rules for what works in commercial open source. This stuff is hard.

History bears him out. There are successes—Red Hat (acquired by IBM), Elastic, MongoDB, Cloudera, MuleSoft, Confluent, Temporal, HashiCorp (also acquired by IBM)—but each navigated awkward trade-offs on licensing, cloud competition, or monetization models. There’s no single “do this and win” playbook.

Even where there’s funding, it doesn’t always land where the risk is. In 2022 I noted that OpenSSF’s multi-point plan was commendable, but generalized funding can’t paper over the reality that attack surfaces change faster than checklists. The most durable wins come from standards for provenance, routine signing, predictable response, and the plumbing that makes “secure by default” boring.

What works and what still doesn’t

Back to NPM. Why did this compromise “go out with a whimper”? Partly because the adversary deployed amateurish malware and got caught quickly. But there’s also evidence the ecosystem’s guardrails are better than they were a few years ago:

Two-factor authentication. GitHub began requiring 2FA for maintainers of the most popular NPM packages in 2022 and later expanded 2FA requirements to all code contributors by the end of 2023. That doesn’t make phishing impossible but it does raise the cost.

Provenance and signing. NPM now supports Sigstore-powered provenance so publishers can attest to where and how their packages were built, and consumers can verify the chain. This is becoming table stakes across ecosystems.

Ecosystem detection. Security vendors and community researchers (JFrog, Wiz, Checkmarx, and others) now actively monitor for anomalous releases and publish indicators of compromise quickly. In the NPM case, that community vigilance constrained dwell time.

Despite all this, one convincingly spoofed email still let an attacker alter a dependency tree consumed by tens of thousands of apps. The Shai-Hulud worm shows that once an author token is stolen, malware can spread laterally through other packages and CI systems—even when the initial malware is simple. That’s the nightmare scenario for anyone running a build pipeline.

Such vulnerability will continue to be an issue wherever we expect under-resourced maintainers to hold up the internet on their shoulders. Funding helps make the secure way the easy way: paying for release automation, reproducible builds, key management, test harnesses, and vulnerability triage. In other words, funding facilitates the glue work that turns the OpenSSF’s checklists into muscle memory. Money is most effective when it accelerates a coordinated process rather than betting on a silver bullet.

If you’re a decision-maker, your best move isn’t to write a philanthropic check and call it done. It’s to treat open source like a supplier you actively manage. Contract for support where it makes sense, sponsor the maintenance you rely on, adopt the provenance and 2FA controls your ecosystems now support, and design your build pipelines to assume packages (and people) will eventually fail.

These NPM episodes should make us grateful for the speed and transparency of open collaboration. It should also make us honest about how much we depend on thinly resourced maintainers and the need to fund and operationalize the guardrails we already know we need.

TL; DR? If you depend on open source, act like it.