npm audit Alternative: Block Malware, Not Just Known CVEs

Short answer: npm audit is a useful built-in report, but it is not a security control. It lists known vulnerabilities (CVE/GHSA advisories) for the versions already in your lockfile — after you have installed them, and only where you happen to run the command. It has no malware feed, so the attacks that dominated npm in 2026 (the keyv worm, the Shai-Hulud family) sail straight past it. A real npm audit alternative does three things npm audit does not: it detects malware, it acts before download instead of after, and it enforces everywhere the project installs. The lowest-friction way to get all three is a hosted registry firewall like InstallSafe — two config lines in .npmrc, no per-machine tooling.

This guide explains exactly what npm audit does and doesn't cover, when its gaps matter, and how the common alternatives compare — so you can decide in ten minutes.

What does npm audit actually do?

Per the official npm documentation, npm audit "submits a description of the dependencies configured in your project to your default registry and asks for a report of known vulnerabilities." If any are found, it calculates impact and remediation. Run npm audit fix and it applies safe upgrades by running a full npm install underneath; anything that can't be fixed safely is left for you.

A few properties matter for this comparison:

• It needs a lockfile. Without package-lock.json or a shrinkwrap, results vary run to run because npm rebuilds the tree each time.
• It is advisory-based. The report is only as good as the vulnerability data npm receives for the exact versions you resolved.
• It is reactive. By the time npm audit flags a version, that version is already in your lockfile and on disk — its install scripts have already run.
• It is a threshold, not a wall. In CI you can set --audit-level=high to fail a build, but that only changes the failure threshold; it doesn't stop the install.

None of this is a criticism of the tool for what it is. It's a free CVE report bundled with npm. The problem is when teams treat it as their supply-chain defence.

Why look for an npm audit alternative?

Four gaps push teams to look elsewhere.

• It doesn't detect malware. This is the big one. npm audit checks for vulnerabilities — bugs in legitimate packages. It has no concept of a package published specifically to steal your NPM_TOKEN, exfiltrate CI secrets, or self-propagate. The 2026 keyv worm that trojanised 400+ packages in 90 minutes was pure malware. npm audit reports it as clean, because there is no CVE for "this release is a credential stealer." Catching that requires a malware feed such as the OpenSSF malicious-packages advisories, which npm audit does not consult.
• It runs too late. The dangerous moment in a supply-chain attack is install, when lifecycle scripts execute. A report you read afterwards tells you that you were compromised; it doesn't prevent it. You want the bad version filtered out before it's ever downloaded.
• It only covers where you run it. npm audit protects the terminal you type it into and the CI step that calls it. It does nothing for a fresh Docker build, a Dependabot/Renovate bot, a new hire's laptop, or an AI coding agent running npm install unattended. Coverage is exactly as wide as your discipline about running the command.
• The signal is noisy and often unfixable. Much of an npm audit report lives in transitive dev dependencies you don't control, and the only "fix" is a breaking major bump. npm audit fix --force is notorious for breaking builds. Teams end up ignoring the output, which is the worst possible outcome for a security tool.

npm audit vs the alternatives: honest comparison

Here is how npm audit lines up against the three approaches teams most often move to.

The pattern: npm audit, Socket's CLI and Snyk all sit above the package manager, so they must be present and run in each place. A registry firewall sits below it — npm asks the registry which versions exist, and the unsafe ones simply aren't in the answer. That's why it protects an AI agent or a CI runner identically to a laptop with zero per-machine setup.

What a good npm audit alternative should do

Whatever you pick, judge it against the four gaps above. A credible replacement should:

• Block malware, not just CVEs. It must consult a malicious-package feed (OpenSSF MAL- advisories), not only vulnerability data.
• Act before install. Prevention at resolution beats a post-mortem report.
• Enforce automatically everywhere. Protection should follow the project, not depend on each person remembering to run a command.
• Preserve your lockfile. Allowed versions should be byte-for-byte identical so package-lock.json integrity hashes stay valid.
• Give an actionable result. Every block should name the advisory ID and the first safe version, not dump an unfixable backlog.

How to replace (or augment) npm audit in three steps

A registry firewall is a hosted, npm-compatible registry that forwards to npmjs.org but filters the metadata. Because npm, yarn, pnpm and bun all resolve versions from registry metadata before downloading anything, removing a bad version from that list means it can never be selected. Here's the switch:

1. See what npm audit is missing right now. Run the free InstallSafe scan on your package-lock.json. It checks every dependency against live OSV.dev data — the GitHub Advisory Database plus the OpenSSF malicious-packages feed — and returns malware (MAL-) findings that npm audit structurally cannot report.
2. Verify in CI. Push a branch. Your CI runner, Docker build and any coding agent that opens the repo now pull through the filtered registry — malicious and known-vulnerable versions never resolve, and a pinned bad version fails with a clear ETARGET error and the advisory ID. Lockfile integrity hashes stay valid because tarballs are served byte-for-byte.

Point the project at the filtered registry. For the whole team, commit it to the repo:

echo "registry=https://r.installsafe.io" >> .npmrc

pnpm and bun read .npmrc too; Yarn Berry uses npmRegistryServer in .yarnrc.yml. Add your token line and you're done.

There is nothing to install on laptops, no shell restart, and no shim to add to a GitHub Actions workflow.

Do you still need npm audit?

Be fair to it: keep it. npm audit is free, built in, and a perfectly good second signal. The healthy setup is layered — a registry firewall enforces the baseline so malicious and known-vulnerable versions can't be installed anywhere, and npm audit stays in CI as a familiar CVE report for the advisories that land after you've already resolved a version. What you shouldn't do is rely on npm audit alone and assume it covers malware. It doesn't, and the 2026 worms proved how expensive that assumption is.

If you want to compare specific tools in more depth, see our teardowns of Socket, Snyk and the broader SCA tool landscape. If your real worry is unattended installs, read blocking AI agents from installing malicious npm packages.

FAQ

Does npm audit detect malware?

No. It reports known vulnerabilities (CVE/GHSA) for the versions in your lockfile. It has no malware feed, so a package published purely to steal credentials or self-propagate passes npm audit cleanly. Detecting malware requires a feed such as the OpenSSF malicious-packages advisories (MAL- IDs), which npm audit does not consult.

What is the best alternative to npm audit?

It depends on the gap. For malware and enforcement, a hosted registry firewall like InstallSafe blocks both malicious and known-vulnerable versions before download, everywhere the project installs. For deep behavioral review of new dependencies at PR time, Socket is strong. For a broad reporting and auto-fix platform, Snyk fits. npm audit is a report; those alternatives actually prevent bad versions from being installed.

Can I keep using npm audit alongside an alternative?

Yes, and it's sensible. Keep npm audit as a free CVE report in CI, and add a registry firewall so malicious and known-vulnerable versions never resolve in the first place. The firewall enforces a baseline across laptops, CI, Docker and AI agents; npm audit remains a familiar second signal.

Why does npm audit report vulnerabilities it can't fix?

Many advisories sit in transitive dependencies you don't control, or the only fix is a breaking major version. npm audit fix applies safe upgrades, but the rest require manual review, and npm audit fix --force can introduce breaking changes. That's why teams look for an approach that blocks bad versions at resolution rather than producing a post-install backlog.

Does replacing npm audit change my lockfile?

No. A registry firewall serves allowed versions as byte-for-byte identical tarballs, so package-lock.json integrity hashes stay valid. Only flagged versions disappear from the metadata; a pinned bad version fails with a clear error and the advisory ID.

Next step: scan your lockfile for free to see the malware and vulnerable versions npm audit is missing today — then add two lines to .npmrc to stop them everywhere.