NPM Security Crisis and Infrastructure Neglect
Nicholas C. Zakas analyzes the critical security vulnerabilities in the NPM registry, arguing that GitHub's current response shifts burden to maintainers without solving systemic risks. The discussion highlights the failure of alternatives like JSR and proposes actionable security frameworks for package distribution.
The NPM Security Crisis
The JavaScript ecosystem faces a critical security inflection point. In September 2025 alone, 500 packages were compromised on NPM, primarily through credential theft and the injection of malicious pre-install scripts. These attacks are not isolated incidents but part of a broader pattern where attackers probe the ecosystem for high-impact targets. The current security posture relies heavily on individual maintainer vigilance, a strategy that is unsustainable at the scale of NPM, which hosts over 3.1 million packages.
GitHub's Insufficient Response
GitHub's recent updates, including fine-grained tokens and trusted publishing, shift the burden of security onto maintainers without addressing systemic vulnerabilities. Trusted publishing, while eliminating static tokens, lacks two-factor authentication and creates vendor lock-in. Furthermore, the lack of batch operations for token rotation forces maintainers to manage hundreds of packages manually, increasing the risk of human error. This approach treats the symptom of credential theft rather than the disease of unmonitored package distribution.
The Failure of Alternatives
Efforts to create alternatives to NPM, such as JSR by Deno, have largely stalled. JSR suffered from a lack of sustainable funding, poor compatibility with existing NPM packages, and a decline in community support. The JavaScript ecosystem lacks a viable second option, leaving developers with no choice but to rely on NPM despite its security shortcomings. This monopoly position reduces the incentive for GitHub to prioritize security improvements, as the registry is viewed as a cost center rather than a revenue driver.
Strategic Recommendations
To secure the ecosystem, the industry must move beyond reactive measures. Implementing registry-level anomaly detection, similar to credit card fraud prevention, is essential. Additionally, requiring major version bumps for packages that add install scripts would significantly slow down the propagation of malicious code. Verified publisher identities and restricted permissions for new packages would further harden the supply chain. Ultimately, the sustainability of NPM depends on finding a funding model that supports robust security infrastructure, whether through paid services or foundation-based governance.
Key insights
-
NPM security is currently dependent on individual maintainer vigilance, which is unsustainable given the scale of the ecosystem and the sophistication of attacks. The lack of registry-level anomaly detection allows malicious packages to propagate before detection.
Impact: Increases the risk of widespread supply chain attacks, potentially leading to significant financial losses and reputational damage for enterprises relying on JavaScript.
-
GitHub's trusted publishing feature, while improving token security, lacks two-factor authentication and creates vendor lock-in. This limits its effectiveness for organizations not using GitHub or GitLab and introduces new single points of failure.
Impact: Reduces the flexibility of maintainers and may discourage adoption of more secure publishing methods, leaving the ecosystem vulnerable to account takeover attacks.
-
The failure of JSR and other NPM alternatives highlights the difficulty of sustaining a package registry without a clear revenue model. The lack of a viable competitor reduces the incentive for GitHub to invest in security improvements.
Impact: Consolidates power in the hands of a single entity, potentially leading to slower innovation and security responses, and increasing the systemic risk for the entire JavaScript ecosystem.
-
Pre-install and post-install scripts are a major vector for malware, allowing attackers to execute arbitrary code during package installation. Current mechanisms do not adequately restrict or monitor these scripts, making them a critical vulnerability.
Impact: Enables rapid propagation of malware across the ecosystem, with potential for significant damage to user data and system integrity.
-
The operational costs of running the NPM registry are high, and the lack of a sustainable funding model leads to under-resourcing. This results in slow responses to security issues and a backlog of necessary improvements.
Impact: Leads to a degraded security posture and slower innovation, potentially driving developers to seek alternative ecosystems or accept higher risks.
Action items
-
Implement registry-level anomaly detection to identify and block suspicious package installations before they reach end-users. This should include monitoring for unusual download patterns and script execution.
Impact: Reduces the window of opportunity for attackers to propagate malicious packages, significantly improving the overall security of the ecosystem.
-
Require a major version bump for any package that adds pre-install or post-install scripts. This ensures that users are aware of the potential security implications and must explicitly opt-in to the new version.
Impact: Slows down the propagation of malicious code and gives security teams more time to identify and remove compromised packages.
-
Develop and promote verified publisher status, linking package publishing rights to authenticated human identities. This would require multi-factor authentication and regular identity verification.
Impact: Reduces the risk of account takeover attacks and increases trust in the integrity of published packages.
-
Explore sustainable funding models for the NPM registry, such as paid security services or enterprise tiers. This would provide the resources needed to implement and maintain robust security infrastructure.
Impact: Ensures the long-term sustainability of the registry and enables continuous investment in security improvements.
-
Restrict the use of pre-install and post-install scripts for new packages, grandfathering existing packages but prohibiting new ones from using them. This would force developers to use safer, explicit setup methods.
Impact: Reduces the attack surface for new packages and encourages the development of more secure installation practices.
Quotes
“In September alone, there were 500 packages that were compromised on NPM.”
“Trusted publishing is basically, you go into NPM, and for your individual package, you say, I want to enable trusted publishing from this source code repository specifically.”
“I think that for a registry to have a chance to compete with npm, I think it has to come from a company or a person starting a company that is already trusted by the community.”