npm audit failed on my first PR: what should I do?

Do not panic and do not run a force flag. Read the audit output, find which package is vulnerable and whether your change introduced it, try the normal fix, and ask the owner of the pipeline before suppressing anything. A failing audit on a first pull request often reflects debt that was already there.

What npm audit actually does

The npm documentation says the audit command submits a description of your dependencies to your registry and asks for a report of known vulnerabilities. By default it exits with a non-zero code if any vulnerability is found, which is what fails a pipeline. The audit level option sets the minimum severity that causes failure, and it does not filter the report output, only the exit threshold. A package lock or shrinkwrap is required unless you bypass it, and the docs warn that bypassing can give different results on every run.

Triage in five steps

1. Run it locally. Run npm audit and read the package name, severity and the dependency path.
2. Check whether you caused it. Compare against the main branch. If main fails the same way, your pull request did not add the problem.
3. Look at the path. If the vulnerable package is deep in the tree, a direct update may fix it. Our explainer on direct versus transitive dependencies helps here.
4. Try the standard fix. The docs say npm audit fix runs a full npm install under the hood and applies remediations to the tree. Review the lockfile diff before committing. Anything that needs a major version bump deserves its own pull request.
5. Ask before suppressing. If no fix exists, bring the report to whoever owns the pipeline. They decide on a time-boxed exception.

What not to do

• Do not delete the lockfile to make it go away.
• Do not lower the audit level on your own branch to turn the check green.
• Do not add a broad ignore without a written reason and an expiry date.

Why a report is not the whole story

An audit report lists known advisories against versions. It does not tell you whether your code calls the vulnerable function. That is a separate question, which reachability analysis tries to answer. If you want to see the difference, the demo below shows how a long list shrinks once reachability is considered.

Where Safeguard fits

Safeguard can do the inventory and watching for you. Its SBOM and dependency scanning lists what a repository actually pulls in, reachability analysis helps separate reachable findings from noise, and policies can gate a pull request. You can try a free scan on a repository to see the output.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how a finding with a known fixed version differs from one with none.

Quick check

Sources

• npm Docs: npm audit

Last reviewed: 19 October 2026.