The npm registry, home to over 2 million JavaScript packages and the backbone of the modern web development ecosystem, had a rough 2021 and early 2022. Between the ua-parser-js hijack, the coa and rc compromises, the Heroku/Travis CI OAuth token theft, and an endless stream of malicious packages, the security of npm was under intense scrutiny. By October 2022, GitHub (npm's parent organization since 2020) had shipped a substantial set of security improvements that began to address the ecosystem's most critical vulnerabilities.
The Problem Space
npm's security challenges are rooted in its scale and architecture:
- Over 2 million packages with complex interdependencies
- Tens of billions of downloads per week
- Hundreds of thousands of maintainers with varying security practices
- No package signing by default
- Account takeover as a persistent threat vector
A single compromised maintainer account can push malicious code to a package that reaches millions of downstream applications within hours. The ua-parser-js incident in October 2021 demonstrated this perfectly: the attacker compromised the maintainer's npm account and published versions containing cryptocurrency mining malware and password-stealing trojans. The package had 8 million weekly downloads.
What npm Changed in 2022
Mandatory MFA for High-Impact Packages
In February 2022, npm began requiring two-factor authentication for maintainers of the top 100 packages by dependency count. By March, this expanded to the top 500 packages, and by the end of 2022, the threshold continued to lower.
This was a critical and long-overdue change. Before this mandate, MFA adoption among npm maintainers was abysmally low — estimates suggested less than 10% of maintainers had enabled it. Given that account takeover was the primary vector for package hijacking, mandatory MFA for high-impact packages directly addressed the highest-risk attack surface.
Enhanced Login Verification
npm introduced enhanced login verification that requires email-based confirmation for logins from new devices or IP addresses. This adds a layer of defense even for accounts without MFA, since an attacker with stolen credentials would also need access to the maintainer's email.
Sigstore-Based Package Provenance
In April 2022, npm announced a collaboration with Sigstore to bring build provenance to npm packages. By October, this was taking shape as a system where packages built in GitHub Actions could include a cryptographic provenance statement linking the published package to its source repository and build workflow.
This addresses one of the most fundamental trust problems in package management: how do you verify that a package was actually built from the source code it claims? Without provenance, you're trusting that the person who uploaded the package built it from the repository you can inspect. With Sigstore-based provenance, you get cryptographic evidence linking the published artifact to a specific commit and build process.
Improved Malware Detection
npm enhanced its automated malware detection capabilities, combining static analysis of package contents with behavioral analysis of installation scripts. While the specifics of these detections aren't publicly documented (to avoid giving attackers a roadmap for evasion), npm reported removing thousands of malicious packages through these automated systems.
Granular Access Tokens
npm expanded support for granular access tokens that can be scoped to specific packages and operations. Instead of giving a CI/CD system a token that can publish any package the maintainer has access to, teams can now create tokens that only allow publishing specific packages, with IP address restrictions and expiration dates.
This limits blast radius: if a CI/CD token is compromised (as happened in the Heroku/Travis CI incident), the attacker can only affect the specific packages that token was authorized for.
npm Audit Improvements
The npm audit command received improvements in accuracy and signal-to-noise ratio. The audit system now better distinguishes between vulnerabilities in runtime dependencies versus development-only dependencies, and provides clearer guidance on remediation paths.
What Still Needed Work
Despite significant progress, several gaps remained:
MFA coverage was still limited. While the top packages were protected, the vast majority of npm's 2 million packages still had no MFA requirement. An attacker could still compromise accounts for less popular but widely-used transitive dependencies.
Provenance adoption was in early stages. Sigstore-based provenance was available but not yet widely adopted. Most packages still had no provenance information, and the tooling for consumers to verify provenance was immature.
Namespace squatting remained unsolved. npm's flat namespace meant that anyone could register package names similar to popular packages (typosquatting) or claim names that matched internal corporate packages (dependency confusion). While npm had policies against malicious intent, the technical architecture still made these attacks easy to attempt.
No package signing standard. Unlike Linux distribution packages (which have had GPG signing for decades), npm packages still lacked a widely-adopted signing mechanism. Sigstore-based provenance was a step in this direction, but it specifically tied to GitHub Actions builds rather than providing a general-purpose signing framework.
Impact on the Ecosystem
The cumulative effect of these improvements was measurable:
- Account takeover incidents for high-impact packages dropped significantly after mandatory MFA
- Automated detection systems were removing malicious packages faster, often within hours of publication
- Granular tokens reduced the blast radius of CI/CD credential compromises
- The Sigstore integration laid groundwork for a future where package provenance is the norm rather than the exception
What Package Consumers Should Do
As a consumer of npm packages, these registry-level improvements help but don't eliminate your responsibility:
- Use lockfiles religiously.
package-lock.jsonensures you get the exact versions you've tested, not whatever is latest. - Enable npm audit in CI. Block builds that introduce known vulnerable dependencies.
- Review dependency updates. Don't blindly accept version bumps — review changelogs and diffs, especially for security-sensitive packages.
- Minimize your dependency surface. Every dependency is an attack surface. Regularly audit whether you actually need each dependency.
- Pin to specific versions. Avoid ranges that could pull in compromised versions automatically.
- Check provenance when available. As Sigstore-based provenance becomes more common, verify it for critical dependencies.
How Safeguard.sh Helps
Safeguard.sh integrates with npm and other package registries to provide comprehensive dependency security. Our platform goes beyond npm audit by analyzing transitive dependencies, checking for known malicious packages, verifying available provenance information, and assessing maintainer security posture. With continuous monitoring and policy enforcement, Safeguard.sh ensures that your JavaScript supply chain benefits from npm's security improvements while filling the gaps that remain.