The npm Heist: How Supply Chain Attacks Work (and Why pnpm Stops Most of Them)
The npm ecosystem has become a major attack surface, with over 454,600 new malicious packages detected in 2025 and high-profile compromises like Axios, Mini Shai-Hulud, and Red Hat-related packages in 2026. Attackers typically phish maintainer credentials, publish a malicious version, and execute payloads via lifecycle scripts or exotic transitive dependencies, often before the community can react. pnpm doesn’t use a different registry but adds a protective policy layer via pnpm-workspace.yaml that evaluates packages before any code runs. Four key rules dramatically reduce risk: minimumReleaseAge blocks packages published in the last 24 hours, stopping fresh backdoors; blockExoticSubdeps prevents transitive dependencies from git URLs or raw tarballs; allowBuilds restricts which packages may run lifecycle scripts; and trustPolicy: no-downgrade ensures new dependencies must be explicitly trusted before scripts execute. A recommended config includes minimumReleaseAge: 1440, blockExoticSubdeps: true, strictDepBuilds: true, trustPolicy: no-downgrade, and a small allowBuilds list. Combined with committing and pinning pnpm-lock.yaml and running pnpm audit on every PR, these measures significantly raise the security bar for JavaScript supply chains.
