← Back to blog

What npm audit Actually Misses — And the Three Layers of Dependency Security

npm audit checks one database. Your dependencies face three types of threats. Here's the full picture and what tools cover each layer.

npmsecuritysupply-chainCVEEUVDKEV

If you run npm audit and see “0 vulnerabilities found,” you might think your dependencies are secure. They’re not — or at least, you can’t know that from npm audit alone.

npm audit checks the npm advisory database. That’s one source. Your dependencies face threats from at least three different directions, and no single tool covers all of them.

The Three Layers

Layer 1: Code review     — bugs in YOUR code
Layer 2: Known CVEs      — bugs in THEIR code (legitimate packages)
Layer 3: Supply chain    — malicious packages pretending to be legitimate

Most developers handle Layer 1 (code review, linting, AI security audits). Almost nobody handles Layer 3. And Layer 2 — the one npm audit partially covers — gets incomplete treatment.

What npm audit Actually Does

npm audit queries the GitHub Advisory Database (which includes npm advisories). It checks your package-lock.json against known vulnerabilities in that single database.

What it catches:

  • Vulnerabilities reported to npm/GitHub
  • Direct and transitive dependency issues
  • Severity ratings from the advisory

What it misses:

  • Vulnerabilities not yet in the GitHub Advisory Database — there’s always a lag between CVE publication and npm advisory creation
  • CISA KEV data — is this vulnerability actively exploited in the wild right now? npm audit doesn’t tell you
  • EUVD data — the EU Vulnerability Database maintained by ENISA, relevant for CRA and NIS2 compliance
  • EPSS scores — what’s the statistical probability this vulnerability gets exploited? Not all “critical” CVEs are equally dangerous
  • Cross-ecosystem view — if your project uses npm AND pip AND cargo, you need three separate tools

Layer 2: Beyond npm audit

OtterSight cross-references three vulnerability databases instead of one:

NVD (via Grype) — the US National Vulnerability Database. The most comprehensive CVE source, with detailed CVSS scoring. Grype matches against this at the package level, including transitive dependencies.

CISA KEV — CISA’s Known Exploited Vulnerabilities catalog. These are not theoretical risks — they’re vulnerabilities confirmed to be exploited in the wild. If a dependency has a KEV entry, it’s not “you should probably update eventually.” It’s “attackers are using this right now.”

EUVD — the EU Vulnerability Database maintained by ENISA. If you operate in the EU or your customers do, the Cyber Resilience Act (CRA) and NIS2 directive make EUVD data relevant for compliance. OtterSight is the first open-source scanner to integrate it.

npx @ottersight/cli scan .

One command, all three databases, 20+ ecosystems (not just npm). The output tells you not just “this has a CVE” but “this CVE is actively exploited (KEV), has an 87% exploitation probability (EPSS), and is tracked in the EU database (EUVD).”

Layer 3: The One Nobody Covers

CVE scanners — including OtterSight and npm audit — catch known vulnerabilities in legitimate packages. They check: “is lodash 4.17.20 known to be vulnerable?” Answer: yes, CVE-2021-23337.

What they don’t catch: malicious packages pretending to be legitimate. Typosquatting (lod-ash instead of lodash), compromised maintainer accounts, supply chain attacks on build pipelines.

The LiteLLM/Telnyx supply chain attack in March 2026 was a recent example. A legitimate package was compromised at the maintainer level. No CVE existed because the package itself was the attack vector.

For Layer 3, you need different tools entirely:

  • Socket.dev — analyzes package behavior (network access, file system operations, eval calls). Detects malicious intent, not just known CVEs.
  • lockfile-lint — verifies lock file integrity (registry URLs, hash consistency). Catches lock file manipulation attacks.

The Full Stack

Here’s what complete dependency security looks like:

Layer 1: Code review     → Your AI assistant / linter / code review
Layer 2: Known CVEs      → npx @ottersight/cli scan .
Layer 3: Supply chain    → Socket.dev / lockfile-lint

Three layers, three tools. None of them covers all three. npm audit partially covers Layer 2. OtterSight covers Layer 2 more comprehensively (three databases instead of one, 20+ ecosystems). Socket.dev covers Layer 3.

Practical Setup

Minimum viable security (5 minutes):

# Layer 2: scan dependencies against CVE databases
npx @ottersight/cli scan .

Better (add to CI):

# GitHub Action
- name: Dependency scan
  run: npx @ottersight/cli scan . --format json

Best (all three layers):

# Layer 2: CVE matching
npx @ottersight/cli scan .

# Layer 3: lock file integrity
npx lockfile-lint --path package-lock.json --type npm --allowed-hosts npm

Start with Layer 2. It catches the most common real-world issues. Add Layer 3 when you’re handling sensitive data or payments.

For Claude Code Users

If you want your AI assistant to check dependencies while coding:

npx @ottersight/mcp

This MCP server gives Claude access to real vulnerability databases instead of guessing from training data.

Both tools are MIT licensed and run locally: github.com/Ottersight/ottersight-cli

npm audit is a start, not an answer. It checks one database for one ecosystem. Your dependencies face three types of threats across potentially multiple ecosystems. Knowing which layer you’re covering — and which you’re not — is the first step to actually securing what you ship.