Securing npm is table stakes (Interview)

What It Covers

Nicholas Zakas, creator of ESLint, critiques GitHub's insufficient response to NPM security breaches. In September 2025 alone, 500 packages were compromised through credential theft and malicious pre/post-install scripts. He proposes specific solutions including anomaly detection, forced major version bumps for script additions, and questions whether alternatives like JSR or Volt can compete with NPM's massive scale and inertia.

Key Questions Answered

• •Pre/Post-Install Script Vulnerability: Malicious actors compromise NPM packages by adding pre-install or post-install scripts that execute immediately upon download, running tools like TruffleHog to steal secrets and credentials from developer machines. These scripts were originally designed for compiling native C++ modules but now represent the primary attack vector. Forcing a major version bump (not minor/patch) when scripts are added would prevent automatic installation and slow attackers significantly.
• •Trusted Publishing Limitations: GitHub's OpenID Connect trusted publishing generates one-time tokens during workflow execution, eliminating stored credentials. However, it lacks two-factor authentication, prompting the OpenJS Foundation to recommend against using it for critical packages. If attackers gain GitHub repository access, they can publish packages undetected. The system also locks maintainers into GitHub/GitLab platforms, excluding companies using private internal repositories for publishing.
• •Token Rotation Burden: GitHub's shift to fine-grained tokens with 90-day expiration dates places significant operational burden on maintainers managing hundreds of packages. No batch operation tools existed at launch, requiring individual package updates with multiple two-factor authentication approvals. This approach pushes security responsibility onto maintainers rather than implementing platform-level protections like credit card companies use with anomaly detection and fraud monitoring systems.
• •Registry Scale Economics: NPM processes over 200 million downloads monthly for packages like ESLint alone, creating massive bandwidth costs that make registries unprofitable. NPM Inc. sold because they couldn't afford operations. JSR from Deno started strong with security-first design but faded as the startup needed revenue. Python's PyPI survives through foundation donations from Google, AWS, and Fastly providing $10,000 monthly hosting, but NPM's scale exceeds this model.
• •JSR Compatibility Failures: JSR implemented strong security including no pre/post-install scripts, reserved namespace protection requiring verification, and trusted publishing from launch. However, mixing JSR packages with NPM packages in publishable projects doesn't work. ESLint developers attempted using JSR standard library packages but had to copy source code directly into their repository instead. JSR only functions for applications, not for packages being published back to NPM.
• •Credit Card Fraud Model: NPM should implement transaction-level anomaly detection like credit card companies, analyzing each package publish for unusual patterns before distribution occurs. Credit cards use CVC codes, chips, and PINs (consumer protection) plus real-time fraud detection (platform protection). GitHub has capability to analyze packages during upload but only applies it reactively after identifying attack patterns, not proactively preventing initial distribution to millions of CI systems and developer machines.