No. The audit-level setting does not filter the report. According to the npm documentation it simply changes the command's failure threshold, so npm audit still lists every finding while exiting non-zero only at or above the level you set. Gate on the exit code, and read the full output separately.
What the documentation says
The audit-level option accepts info, low, moderate, high, critical and none. It sets the minimum severity that causes a non-zero exit code. The default is null. The documentation states that it "simply changes the command's failure threshold" and does not filter the report output.
Exit behavior in short:
npm auditexits 0 when no vulnerabilities are found.- Otherwise the exit code depends on
audit-level. npm audit fixexits 0 if nothing is vulnerable or if the remediation fixes everything.
Why this trips people up
A common assumption is that setting a level to high means the report only shows high and critical issues. It does not. The log of a passing job can contain a long list of low and moderate findings next to a green tick. That can be good or bad depending on whether anyone reads the log.
| What you set | What the job does | What the log shows |
|---|---|---|
| audit-level high | Fails on high or critical only | Everything |
| audit-level none | Never fails because of findings | Everything |
| default | Fails according to default behaviour | Everything |
Two consequences follow. A green build does not mean the dependency tree is clean. And a long list in the log does not mean the gate is broken.
Setting up a gate you can defend
- Decide the threshold in policy. For example: block on high and critical, track moderate in a backlog with a review date.
- Set the level in the CI step so the exit code matches the policy.
- Save the full report as a build artifact. Use the json option of npm audit for machine-readable output.
- Make a person or a bot responsible for the lower-severity items. A gate without a backlog owner turns into silent debt.
- Pair the gate with production scope when that is the question. The omit option accepts dev, optional or peer, and omitted packages are left out of the advisory payload. The default is to omit dev when the NODE_ENV environment variable is production.
Common gaps
- A job that ignores the audit exit code never fails at all. That is a deliberate choice only if you documented it.
- A threshold set once and never revisited. As severity data changes, new findings appear at levels you did not plan for.
- A passing audit used as evidence for a customer. The audit checks installed packages against the advisory data npm uses. It does not review code you wrote.
Testing your gate
Test the gate once. Add a known vulnerable package to a branch, run the job, and confirm it fails at the level you chose. Then remove it and confirm it passes. Skipping this check is how a gate ends up inactive without anyone noticing.
Reading the log on purpose
Make a habit of opening the audit output at each release, not only when the job fails. A release review that includes a minute on the full list catches the moderate item that has been open for six months.
Safeguard's policies, gates and guardrails apply a severity threshold to pull requests and keep the full finding list available, so blocking and reporting are separate. A free scan is at gold.safeguard.sh/scan.
Quick check
If I set audit-level to critical, will lower findings still be printed?
Yes. The setting changes only the failure threshold, not the printed report.
What does npm audit do when no vulnerabilities are found?
It exits with code 0.
Sources
- npm Docs, npm audit
Last reviewed: 19 October 2026.
