Run npm audit in your project folder. It submits a description of your configured dependencies to the registry and returns known vulnerabilities with the remediation it calculates. By default it needs a package-lock.json, and it exits with a non-zero code when it finds something, which makes it usable in CI.
What the command does
According to the npm documentation, npm audit sends the dependency description to your default registry and asks for a report. If it finds issues, it works out the impact and suggests a fix. The report covers the whole tree, not just the packages in your package.json.
Steps
- Make sure package-lock.json exists and is committed.
- Run the audit from the project root.
- Read the report, starting with high and critical findings in direct dependencies.
- Re-run after you update packages.
- Add the command to CI with a failure threshold.
npm audit
npm audit --json
npm audit --audit-level=high
The audit level option sets the lowest severity that causes a non-zero exit. The npm docs are clear that it does not filter the report. It changes just the failure threshold.
Useful variations
| Need | Approach |
|---|---|
| Machine readable output | Add the JSON option |
| Fail CI only on serious findings | Set the audit level to high or critical |
| Skip dev tooling | Omit the dev dependency type |
| Verify package integrity | Run npm audit signatures |
The signatures command verifies registry signatures of downloaded packages, and provenance attestations too. That is a different question from known vulnerabilities, so run both.
Limits to know
- The audit reports what the registry knows. A new advisory is not visible until it is published.
- Without a lockfile you can bypass the requirement with a flag, but results may differ between runs.
- A finding in a package does not prove your code reaches the flawed function.
How to read the result
Each finding names the vulnerable package, the range of affected versions, and a recommended fix when one exists. Look at the dependency path to see which of your direct packages brings it in. A finding on a direct dependency is usually a one line change. A finding several levels down may need a parent upgrade, or an override, and the report will say when the fix needs manual review.
Keep a copy of the JSON output from each run. Comparing two runs shows what is new since the last release, which is more useful than a single long list.
A sensible CI setup
- Install with the lockfile, so the tree matches what you ship.
- Run the audit with a high severity threshold and fail the job on a non-zero exit.
- Run a second, broader audit on a schedule and send the output to the owning team.
- Review the threshold each quarter and lower it as the backlog shrinks.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a finding and compare its severity with the fix version shown.
Quick check
Does npm audit change my files?
No. Plain npm audit just reports. The fix variant modifies your tree, and that is covered in a separate post.
Should CI fail on every finding?
Usually not at first. Start with high and critical, then tighten as the backlog shrinks.
Safeguard adds reachability analysis and policy gates on top of dependency findings, and you can run a free scan without setup.
Sources
Last reviewed: 19 October 2026.
