npm audit isn't enough: what it misses

Run npm audit on almost any real-world Node project and you'll get a wall of output: dozens of "vulnerabilities," most of them low-severity issues in transitive dependencies nobody on your team has ever heard of. Triage takes an hour. Fixing them means a npm audit fix that may or may not break your build. And at the end of it, your supply chain is not meaningfully safer -- because npm audit was never designed to catch the attacks that actually hit npm in 2024 and 2025: malicious packages published fresh with no CVE, compromised maintainer accounts pushing backdoored updates, typosquats of popular libraries, and post-install scripts that exfiltrate environment variables the moment npm install runs. This post breaks down exactly what npm audit misses, how Socket.dev's approach differs from a CVE-matching tool, and where Safeguard fits for teams that need continuous, policy-driven supply chain defense rather than a point-in-time scan.

What Does npm Audit Actually Check?

npm audit works by comparing the packages in your package-lock.json (or npm-shrinkwrap.json) against the GitHub Advisory Database, which npm's registry API queries on your behalf. If a version range in your lockfile matches a published advisory, you get a finding with a severity rating and, where available, a suggested fix version.

That's the entire mechanism: lockfile version ranges matched against a database of already-disclosed vulnerabilities. It is a reactive control. A package has to be:

1. Publicly known to be vulnerable,
2. Assigned a CVE or GitHub Security Advisory, and
3. Indexed in the advisory database npm queries

...before npm audit can ever flag it. None of that happens at publish time, and none of it happens in real time. A brand-new malicious package, or a legitimate package that gets compromised today, will show up in npm audit as completely clean until someone notices the attack, reports it, and an advisory gets written -- which in supply chain attacks is often weeks after the damage is done.

Why Doesn't a Clean npm Audit Mean You're Safe?

Because the categories of attack that dominate npm's actual threat landscape don't produce CVEs at all, or don't produce them in time to matter:

• Malicious packages with no prior history. Packages published purely to steal credentials or crypto wallets, or to run as droppers, don't have a "vulnerable version" to detect -- the package is malicious from version 1.0.0. There's no patched version to upgrade to because the entire package is the payload.
• Typosquats. reqeust instead of request, crossenv instead of cross-env. These are new packages, not vulnerable versions of trusted ones, so they never appear in an advisory database tied to a legitimate package's history.
• Compromised maintainer accounts and build pipelines. When a legitimate, previously-safe package gets an unauthorized release pushed through a hijacked npm token or compromised CI system, the version bump looks routine. Advisory databases catch these only after the community notices and researchers publish a report.
• Install-time and lifecycle-script behavior. npm audit does not execute, sandbox, or analyze what a package's preinstall, install, or postinstall scripts actually do. A script that phones home, downloads a second-stage payload, or reads your .env file runs before any vulnerability scanner even has a chance to look at the code.
• Dependency confusion and namespace attacks. Publishing a public package that shadows an internal, private package name isn't a "vulnerability" in the CVE sense -- it's a naming and resolution problem npm audit has no visibility into.

This is the gap that gave rise to a category of tools, including Socket.dev, built specifically to look at package behavior rather than only matching against disclosed CVEs.

How Does Socket.dev's Approach Differ From npm Audit?

Socket.dev is publicly positioned around static analysis of package behavior at the point a dependency is added or updated, rather than matching only against known-CVE databases. Its documented approach analyzes package source and manifests for indicators such as the use of install/lifecycle scripts, network or filesystem access, use of eval or dynamic code execution, obfuscation, and suspicious permission requests, and surfaces those as risk signals directly in pull requests via a GitHub app, in addition to traditional vulnerability data. That is a materially different detection model than npm audit's lockfile-to-advisory matching: it's looking for behavioral red flags in code that hasn't been reported as malicious yet, which is exactly the class of attack the previous section describes.

Two concrete, verifiable differences worth naming plainly:

• Detection trigger. npm audit requires a published advisory to exist before it can flag anything. Socket.dev's published model is built to flag suspicious characteristics of a package (install scripts, obfuscation, unexpected permissions) independent of whether a CVE has been filed.
• Surface point. npm audit is a CLI command you run against a lockfile, typically in CI or manually. Socket.dev is documented as integrating primarily through a GitHub app that comments on pull requests when a new or changed dependency trips a risk signal.

Where we're deliberately not going further is into Socket.dev's specific detection accuracy, pricing tiers, or coverage claims -- those are worth verifying directly against their current documentation rather than taking on faith from a competitor's blog post, and we'd rather point you to primary sources than guess.

What Should a Real npm Audit Alternative Cover?

Based on the gaps above, a tool that actually closes what npm audit misses needs to do more than re-run the same advisory match faster. At minimum it should:

1. Evaluate packages before they're merged, not just after a CVE is published -- looking at behavior and metadata (install scripts, maintainer/publish history, package age, download velocity anomalies) rather than only known-vulnerability status.
2. Enforce policy, not just report findings. A list of risk signals that nobody acts on is no better than a wall of low-severity CVEs nobody triages. Findings need to map to a policy your team actually enforces at the PR or registry-ingestion level.
3. Cover the full lifecycle, not a single scan. Dependencies get updated constantly; a one-time audit at project setup tells you nothing about the package that changes six weeks from now.
4. Produce artifacts your compliance program can use. SBOM generation and audit trails matter as much as detection when you're answering to SOC 2 or customer security questionnaires.

How Safeguard Helps

Safeguard is built around the idea that supply chain security has to be continuous and policy-driven, not a CLI command you remember to run before a release. Concretely, that means:

• Continuous dependency monitoring, not a point-in-time scan. New packages and updates to existing dependencies are evaluated as they land, so a compromised update or a freshly-published malicious package doesn't sit undetected until the next time someone happens to run an audit.
• Policy-as-code enforcement that lets teams define what "acceptable" looks like -- allowed licenses, disallowed install-script behavior, minimum maintainer trust signals -- and block or flag violations directly in CI/CD and pull requests, rather than surfacing a report that requires manual follow-up.
• SBOM generation and audit trails built for compliance workflows, so the same scanning that protects your build also produces the documentation your SOC 2 auditor or enterprise customer's security team will ask for.
• Tenant-aware, org-level policy controls for teams managing multiple projects or business units under a single security posture, so policy doesn't have to be re-implemented per repository.
• Integration into the points where dependencies actually enter your codebase -- CI pipelines and registry ingestion -- rather than requiring a separate manual step that's easy to skip under deadline pressure.

None of this is a claim that npm audit or CVE-based scanning is worthless -- known-vulnerability data is still a necessary part of the picture, and Safeguard incorporates it. The point is that CVE matching alone leaves the door open to exactly the attacks that are currently landing in the npm ecosystem: packages with no disclosure history, compromised accounts, and install-time payloads. If your current process stops at npm audit, the honest next question isn't "which tool has the better dashboard" -- it's whether your process evaluates packages before they're exploited and reported, or only after.

If you're evaluating an npm audit alternative for your team, the right test isn't a feature checklist -- it's whether the tool would have caught the last few real npm supply chain incidents you've read about, none of which were CVE-driven at the time they happened. That's the bar Safeguard is built to clear.