According to a recent Changelog episode with Nicholas Zakas, over 2 million npm packages exist in an ecosystem that’s essentially one coordinated attack away from catastrophic failure. That’s not hype. That’s a maintainer of one of the most widely-used open source projects in the world saying what we’ve all quietly feared.
Zakas, who’s spent years keeping ESLint running, has earned the credibility to critique npm’s security posture. And his verdict? npm security isn’t getting the resources it needs, and GitHub’s recent response—while a step in the right direction—is cosmetic compared to what actually needs to happen.
Why npm Feels Like Broken Infrastructure
Here’s the thing about npm: it’s not just a package manager. It’s the central nervous system of JavaScript development. Every React app, every Node backend, every build tool you’ve ever touched depends on it. And yet—and this is the wild part—the security model feels like it was designed in 2009 and never substantially rebuilt.
The attack surface is enormous. Pre and post-install hooks (those scripts that run when you install a package) are basically an open invitation to malicious actors. A compromised dependency of a dependency can silently execute code on your machine. There’s no cryptographic verification that the person publishing a package is actually who they claim to be.
“What they’re not doing is the hard work of actually securing the supply chain at a fundamental level,” Zakas explained on the episode, pointing to GitHub’s focus on trusted publishing as incomplete without deeper systemic changes.
Trusted publishing—GitHub’s recent security push—helps, but it’s like putting a security camera in your front door while leaving the back window open. Yes, it verifies that code comes from a real person or organization. No, it doesn’t prevent malicious actors from becoming those people by compromising their accounts, nor does it stop supply chain attacks where a legitimate package gets updated with malicious code.
Is npm Still Actually Safe to Use?
When a creator of one of the world’s most-downloaded linting tools starts questioning whether npm is still prudent to use, that’s a red flag (or several red flags, actually).
Zakas didn’t say “abandon npm tomorrow.” That’s not realistic. Millions of projects depend on it, and the ecosystem isn’t going anywhere overnight. But he’s clearly thinking through the uncomfortable questions: What happens when—not if, but when—there’s a coordinated attack that compromises multiple high-value packages? How many people at GitHub are actually working on npm security?
The staffing question is its own crisis. A package manager serving millions of developers and trillions of weekly downloads operates with what feels like a skeleton crew. That’s not a criticism of those individuals; they’re doing extraordinary work. It’s a criticism of the incentive structure. npm isn’t primarily a profit center for GitHub. It’s a resource drain that they maintain because the entire JavaScript ecosystem would collapse without it.
That’s the misalignment Zakas kept circling back to: GitHub profits from GitHub Actions, from enterprise tools, from cloud services. npm? npm is infrastructure they have to keep the lights on, but it doesn’t generate revenue. So security improvements feel like they’re always behind the curve, always catching up to the latest attack vector rather than staying ahead.
Why JSR Isn’t the Answer (Yet)
Zakas was blunt about the alternatives. JSR (the JavaScript Registry being built by the Deno team) gets hype, sure. It has some genuinely interesting ideas—verified publishers, better supply chain security by design. But it’s a greenfield project competing against 20 years of network effects. Deno’s trying to build a better ecosystem, not just a better registry.
The problem isn’t that JSR is technically inferior. The problem is that npm has gravitational pull. Every developer knows npm. Every tool integrates with npm. Every business runs on npm. Switching isn’t a technical problem; it’s a coordination problem. And coordination problems are exponentially harder to solve than technical ones.
What’s interesting is that Zakas seems almost resigned to the status quo—npm will remain dominant because alternatives can’t overcome network effects, but npm’s security model will remain fundamentally incomplete because the incentives don’t align for someone to actually fix it properly.
The Real Issue: Who Bears the Risk?
Here’s where it gets dark.
When a package gets compromised, the harm is distributed. Developers discover it weeks or months later. Companies get breached. Users get hacked. The actual publisher might not even know their credentials were compromised. But npm itself? It mostly escapes unscathed. The cost of insecurity is externalized to everyone using npm, not to the people running it.
That’s the structure that creates the misalignment. GitHub has zero incentive to spend engineering resources on hardening npm’s supply chain because they don’t pay the price when something goes wrong. You do. Your company does. Your users do.
Other ecosystems handle this differently. Zakas touched on how other languages and their package managers have different ownership structures, different revenue models, different incentive alignments. But JavaScript? JavaScript is stuck with a system built by a company that’s now owned by Microsoft, which views it as infrastructure, not a product.
What Actually Needs to Happen
Zakas had ideas. Verified publishers help. Cryptographic signing of packages helps. Eliminating or sandboxing pre/post-install hooks would be transformative. Increasing staffing and security resources is table stakes—non-negotiable.
But none of that happens without pressure, without the developer community collectively saying “this is unacceptable.” And that pressure is hard to build when the ecosystem is too integrated to abandon and too fragmented to coordinate.
The uncomfortable truth? npm’s security will likely remain inadequate until something catastrophic happens. A major breach that compromises millions of developers. A worm that spreads through dependencies and makes international headlines. That’s when the incentives shift. That’s when GitHub gets permission to spend whatever it takes.
Until then, npm security will be like many infrastructure problems—underfunded, under-resourced, and held together by the dedication of people who care deeply but can’t move mountains alone.
Zakas isn’t panicking. He’s thinking three moves ahead. And if an ESLint maintainer is thinking three moves ahead about npm’s security, the rest of us probably should be too.
🧬 Related Insights
- Read more: Kubescape 4.0 Brings Enterprise Stability—and Now Your AI Can Debug Your Kubernetes
- Read more: GitLab’s Package Repository Overhaul: What DevOps Teams Must Do Before September 2026
Frequently Asked Questions
Is npm really as insecure as people say? Npm has genuine security vulnerabilities in its architecture—unverified publishers, pre/post-install hooks that can execute arbitrary code, and limited cryptographic verification. These aren’t theoretical. They’ve been exploited repeatedly. That said, millions of projects use npm daily without incident. The risk exists on a spectrum, but the potential for a large-scale supply chain attack is real.
Will JSR replace npm? Not in the near term. JSR has better security design, but npm’s dominance comes from network effects, not just technical merit. Developers, tools, and businesses are invested in npm. A switch would require massive coordination. JSR might capture new projects or specific ecosystems, but npm will likely remain the default for years.
What should developers do right now? Keep npm updated. Use lock files and verify your dependencies. Enable GitHub’s trusted publishing if you publish packages. Audit your dependency tree regularly. And if you’re building something new, consider whether JSR or other alternatives make sense for your specific use case. But don’t panic—the ecosystem isn’t collapsing. Yet.
