← npm deployment evidence

This tool vs. npm audit

npm audit is the vulnerability scanner almost every npm project already has — it ships inside npm itself, no separate install, and it is very likely the tool that produced the finding count you are looking at right now. It checks every package in your lockfile against GitHub's public security advisory database and reports which ones have a known issue, at which severity, and whether a fix is available.

That makes npm audit the right tool for one job: finding out whether a package in your dependency tree has a known vulnerability. This tool does not do that job and has no advisory database of its own — it never checks a package name against anything. What it does is answer the question npm audit's own output leaves open: of the packages it just flagged, which ones does your lockfile show reaching your deployed application, and which exist only for a build, test, or lint step to run.

What we actually ran

Rather than describe npm audit from memory, this page is built from running it: npm 10.9.7, a throwaway project with one vulnerable production dependency (minimatch) and one vulnerable devDependency (minimist), npm install, then npm audit --json. The full output is reproducible with the same two packages at the same versions. 

{
  "vulnerabilities": {
    "minimatch": { "name": "minimatch", "severity": "high", "isDirect": true,
      "via": [ … ], "range": "<=3.1.3", "nodes": ["node_modules/minimatch"],
      "fixAvailable": { … } },
    "minimist": { "name": "minimist", "severity": "critical", "isDirect": true,
      "via": [ … ], "range": "<=0.2.3", "nodes": ["node_modules/minimist"],
      "fixAvailable": { … } }
  },
  "metadata": {
    "vulnerabilities": { "high": 1, "critical": 1, "total": 2 },
    "dependencies": { "prod": 5, "dev": 1, "total": 5 }
  }
}

minimist exists only in devDependencies in that project. It is reported exactly the same shape as minimatch, the production dependency — name, severity, isDirect, via, range, nodes, fixAvailable. Nothing on that finding says "dev." The only place the run distinguishes prod from dev at all is the aggregate count at the bottom, metadata.dependencies — a total, not a per-finding label.

Re-running with npm audit --omit=dev does remove minimist from the report and drops the critical count from 1 to 0 — npm audit can scope to production. But it does so by excluding the dev-only finding, not by keeping it and marking it dev-only. A reviewer who wants to see both — what's on the production path and what's dev-only, each labelled, in one document — has to run the audit twice, with and without the flag, and diff the two lists by hand. That is the exact manual step this tool's report replaces: it reads the same lockfile once and classifies every entry — declared by the application, reachable only through a production dependency, or build-only — with the evidence for each classification, in one exportable Markdown or JSON file.

QuestionWhere to answer it
Does this package in my lockfile have a known vulnerability? npm audit — it checks against a live advisory database this tool does not have.
Of the packages npm audit just flagged, which ones does my deployed application actually load? This tool — drop in the same package-lock.json and read the production/build-only split, with the reason for each row.
I want a document I can attach to a security questionnaire showing the classification, not just a console count. This tool's Markdown or JSON export. npm audit's JSON is a point-in-time advisory list without that reasoning.
Is a build-only finding safe to ignore? Neither tool says yes. A compromised build or test dependency still runs on your machine and in CI — see the FAQ below.

Open the free lockfile evidence tool

Common questions

Should I use this tool or npm audit?

Both, for different questions. npm audit checks the packages in your lockfile against a vulnerability advisory database (GitHub Security Advisories) and tells you which ones have a known issue. It does not tell you, on a per-finding basis, whether the affected package reaches your deployed application or only exists for your build and test tooling. This tool answers that second question by reading what the lockfile already records about each package's install path, and produces a report you can attach to the audit output.

Doesn't npm audit already separate production from dev dependencies?

Partly. npm audit --json reports an aggregate count of prod versus dev dependencies scanned (the metadata.dependencies object), and npm audit --omit=dev will exclude devDependencies from the run entirely. But run against a real project (verified on npm 10.9.7 with a lockfile containing one vulnerable production dependency and one vulnerable devDependency), the per-finding objects in vulnerabilities carry no field marking a specific finding as production-path or dev-only — only name, severity, isDirect, via, range, nodes and fixAvailable. And --omit=dev removes dev-only findings from the report rather than keeping and labelling them, so a reviewer who wants to see and document which findings are dev-only, not just hide them, has to run the audit twice and diff the two lists by hand. That manual diff is what this tool's report replaces.

Is this affiliated with npm, Inc. or the npm CLI project?

No. npm audit is named here only to describe what it does and does not report, based on running it directly (npm 10.9.7, npm audit --json) and its own --help output. This site is not affiliated with, endorsed by, or sponsored by npm, Inc. or the Node.js Foundation.

See also: Which npm vulnerabilities actually reach production?