[RRFC] Extend npm audit to detect supply chain compromise signals beyond CVEs

[ranjithrajv]

Motivation ("The Why")

The axios compromise on March 31st exposed a gap that npm audit can't close on its own. A threat actor hijacked the primary maintainer's npm account and published two backdoored versions within 40 minutes — each with a previously undeclared dependency running a RAT via post-install. There was no CVE at the time of publish. The advisory database had nothing to flag.

This isn't isolated. In 2025 alone, 45,777 CVEs were reported averaging 130 per day, and multiple npm supply chain attacks hit packages with billions of weekly downloads. A growing share of these attacks arrive before a CVE exists — through account takeovers, dependency injection, and post-install abuse.

Example

A developer runs npm install after a routine package.json update. One dependency received a patch version bump overnight. The bump introduced a new post-install script and was published by an account that had never touched the package before. npm audit returns clean. The machine is compromised within seconds of install completing.

How

Current Behaviour

npm audit queries the advisory database for known CVEs against the resolved dependency tree. It returns clean if no CVEs exist, regardless of other signals.

Desired Behaviour

npm audit (or a new npm audit --provenance / npm audit --supply-chain flag) additionally checks:

• Whether the publish account for each installed version has previously published that package
• Whether new post-install or install scripts were introduced in the installed version vs. the prior one
• Whether new transitive dependencies were introduced that weren't present in the prior version
• Whether the installed version has a valid SLSA provenance attestation, especially for packages that previously carried one

These checks don't require a new database — npm already has publish history and provenance metadata. Surfacing them at audit time gives developers a signal before a CVE is ever filed.

References

• Microsoft Security Blog — Mitigating the Axios npm supply chain compromise
• The Hacker News — Axios Supply Chain Attack Pushes Cross-Platform RAT
• Palo Alto Networks — Widespread npm Supply Chain Attack Puts Billions of Weekly Downloads at Risk
• Related: [RRFC] npm audit fix should consider package source in alert delivery #739

[ljharb]

How do you propose npm do such detections, considering that's a large value proposition of many SCA businesses?

Provenance metadata isn't helpful at all in a security context; it is perfectly legitimate for a maintainer to decide to stop using provenance, and/or OIDC/trusted publishing. Virtually nobody both adheres to and also programmatically communicates SLSA.

Additionally, simply having a different maintainer publish a version is not a reliable signal, and adding or removing transitive deps is DEFINITELY not a signal at all.

The "change in install scripts" one is the only thing that would be valuable in that list, imo.

[everett1992]

Whether new post-install or install scripts were introduced in the installed version vs. the prior one.

This seems useful, but easy to side-step. axios@1.14.1 didn't itself add a postinstall script, one of it's transitive dependencies did. I don't know if that package always had postinstall scripts, or if it was a fresh package. So we'd also want to detect new transitive dependencies with postinstalls.

Audit runs after install, which would be tool late if any malicious postinstall script ran, unless you run with --ignore-scripts.

Whether the publish account for each installed version has previously published that package

This would be a high-noise signal, even with manual review.

• false positive: just another maintainer publishing
• false negative: regular maintainer credentials compromised

Would this have flagged any of the high-profile issues (Axios, CanisterWorm, Shai Hulud)?

Whether new transitive dependencies were introduced that weren't present in the prior version

This seems like it can be valuable with manual review but I don't think you can get an automated binary signal from new transitive deps.

Whether the installed version has a valid SLSA provenance attestation, especially for packages that previously carried one

While this can have false positives, and most packages don't track SLSA, this is a signal that I would want to fail an install and require a human in the loop. I'd also flag changes to trusted publishing.