npm Package Security Scanning: A Practical Guide
TL;DR · the short version
The npm registry is one of the most-attacked software supply chains - via known-vulnerable dependencies, typosquatting, and malicious packages, including compromised maintainer accounts. Scanning addresses three risks: known vulnerabilities in the versions you use, malicious or suspicious packages (obfuscated code, data-exfiltrating install scripts, typosquats), and provenance/integrity. A good approach combines vulnerability scanning, malicious-package checks, lockfile/integrity verification, and CI integration to catch problems before they ship.
The npm registry powers most of modern web development, which also makes it one of the most-attacked software supply chains. Scanning npm packages for security risk is now table stakes — but "scanning" has to mean more than checking for known CVEs, because the incidents that hurt most involve malicious packages and compromised updates that no vulnerability database has catalogued yet.
The three risks to scan for
- Known vulnerabilities: CVEs in the exact versions you use, including transitive dependencies.
- Malicious / suspicious packages: obfuscated code, install scripts that exfiltrate data, and typosquats imitating popular package names.
- Provenance & integrity: is this package genuinely from the expected source and unchanged? Lockfile integrity hashes and signed provenance help answer this.
How npm supply-chain attacks work
The recurring vectors are typosquatting (a malicious package named like a popular one), dependency confusion (a build pulls a public package instead of your intended private one), and maintainer-account compromise (an attacker pushes a malicious update to a legitimate package that everyone auto-pulls). Malicious code frequently hides in install scripts that run during npm install — which is why post-install behaviour is a key thing to scan and control.
Is npm audit enough?
No. npm audit checks known vulnerabilities — necessary but not sufficient. It will not catch a brand-new malicious package, a typosquat, or a fresh compromised update. Add malicious-package/behaviour scanning and provenance verification on top.
Build it into your workflow
- Run dependency + malicious-package scanning in CI on every pull request.
- Fail builds on high-severity findings.
- Pin and verify dependencies with a committed lockfile (integrity hashes).
- Disable or sandbox install scripts for untrusted packages.
Scan a package now with the npm Scanner → or the broader Package Scanner, and see a real npm compromise dissected in the Shai-Hulud provenance analysis. For static analysis, DAST and secret scanning beyond npm, see free AppSec tools that need no free trial.
Frequently asked questions
What to scan for? Known vulnerabilities, malicious/suspicious packages (typosquats, exfiltrating install scripts), and provenance/integrity.
How are attacks carried out? Typosquatting, dependency confusion, and maintainer-account compromise — often via install scripts.
How to integrate? Scan in CI, fail on high severity, pin/verify with a lockfile, sandbox install scripts.
Is npm audit enough? No — it catches known CVEs but not new malicious packages, typosquats or fresh compromises.
Frequently asked questions
What should npm package scanning look for?
Three things: known vulnerabilities (CVEs) in the specific versions your project depends on, including transitive dependencies; malicious or suspicious package indicators (obfuscated code, suspicious install/post-install scripts, data exfiltration, typosquatted names imitating popular packages); and provenance/integrity (verifying the package is genuinely from the expected source and unchanged, via lockfile integrity hashes and, increasingly, signed provenance). Scanning only for CVEs misses the malicious-package and typosquat risks that have driven many recent incidents.
How are npm supply-chain attacks carried out?
Common vectors include typosquatting (publishing a malicious package with a name close to a popular one), dependency confusion (tricking a build into pulling a public package instead of an intended private one), and maintainer-account compromise (an attacker gains control of a legitimate package and pushes a malicious update that all its users auto-pull). Malicious code often hides in install scripts that run during npm install, which is why post-install script behaviour is a key thing to scan and control.
How do I integrate scanning into my workflow?
Run dependency and malicious-package scanning in CI so every pull request and build is checked, fail builds on high-severity findings, pin and verify dependencies with a committed lockfile (integrity hashes), and consider disabling or sandboxing install scripts for untrusted packages. Catching a bad dependency at the pull-request stage is far cheaper than after it ships.