npm audit sends a description of your project's dependencies to your configured registry and asks for known vulnerabilities. If it finds any, it reports their impact and remediation. It does not read your source code, and by default it exits with a non-zero code when it finds vulnerabilities.
What it checks
According to the npm documentation, the command compares your dependency tree against the registry's advisory data. It works on packages and versions, not on your own code. That means it can tell you that version 1.2.3 of a package has a known advisory, but not whether your code calls the affected function.
What it sends
Since npm 7 the default is the bulk advisory endpoint. npm posts a JSON payload that lists each package in the tree by name and a list of versions. Packages without a version field are skipped, and packages matching your omit options are left out.
If the bulk endpoint errors or returns invalid data, npm falls back to a quick audit endpoint. That sends the full package tree from the lock file plus the npm version, Node version, platform, architecture and environment.
The docs also note that since npm 7, package names are no longer scrubbed. Earlier versions omitted names containing a slash. If your dependency names are sensitive, for example private scoped packages, think about whether sending them to your registry is acceptable. Using a private registry mirror is one answer.
Exit codes and severity
The command exits with 0 when no vulnerabilities are found. The audit level setting accepts info, low, moderate, high, critical and none. It sets the minimum level that causes a non-zero exit, and it does not filter the report itself. A CI job can fail only on high and above while still showing everything.
What audit fix does
npm audit fix applies remediations by running a full install under the hood. Some issues cannot be fixed automatically. Without the force option it will not change dependency ranges. With force it can install semantic version major updates and versions outside your stated range, which can break your app. Read the lockfile diff and run tests before you commit.
A short, honest checklist
- Run the audit on a clean install.
- Read the severity and the fixed version for each finding.
- Ask whether your code reaches the vulnerable function.
- Fix, then rerun the audit and your tests.
- Record anything you accept and why.
Steps 3 and 5 are the ones scanners cannot do for you. Our post on what fix available means in a scan covers the gap.
Where Safeguard fits
Safeguard's SBOM and dependency scanning adds reachability analysis on top of advisory matching, and you can try a free scan on a Node.js project.
Try it yourself
Open the demo to see how a fix that is available is applied and verified.
Click through it at your own pace, or open it full screen.
Quick check
Does npm audit scan my own code?
No. It matches dependency names and versions against known advisories.
Is a clean npm audit proof of safety?
No. It means the registry knows of no matching advisory, not that the packages are safe.
Sources
Last reviewed: 19 October 2026.
