It can, but only if your mirror answers the advisory request. npm audit sends package names and versions to the registry you have configured. If your mirror forwards that request upstream or serves its own advisory data, you get results. If it does not, npm falls back to a slower endpoint, and the docs do not say what happens after that.
What npm actually sends
Since npm 7, npm audit posts a list of package names and versions to a bulk advisory path on the default configured registry. If that call returns an error or an invalid response, npm tries an older quick audit endpoint, which the docs describe as considerably slower in most cases. The quick endpoint receives the full package tree from the lockfile plus some environment details such as the npm and Node versions.
The practical point for a small team is simple. Your mirror is now in the path of the audit. A mirror that only caches tarballs and package metadata may not know what to do with the advisory request.
The audit setting is on by default, and the config docs say npm submits audit reports to the default registry and to scoped registries. So a scope pointed at a private feed will receive audit traffic too.
Three ways a mirror can behave
| Mirror behavior | What you see | What to do |
|---|---|---|
| Forwards the advisory path upstream | Audit results as usual | Nothing, but confirm once |
| Serves its own advisory data | Results, possibly differing from upstream | Learn how fresh that data is |
| Rejects or ignores the path | Errors or an empty report | Add a separate scan of the lockfile |
The middle case deserves a note. If the mirror keeps its own copy of advisory data, the freshness of that copy decides how current your audit is. Ask whoever runs the mirror how often it refreshes.
Test it from a clean machine
Run this in a small project that has a lockfile and at least one dependency you know has an advisory.
npm config get registry
npm audit
echo "exit code: $?"
Check three things. First, the registry printed is your mirror and not the public default. Second, the report lists the advisory you expected. Third, the exit code is non-zero when vulnerabilities exist, so your CI step can fail on it.
An empty report is not proof of a clean tree. It may mean the audit call silently returned nothing. That is why you want one known-vulnerable package in the test project.
If audit does not work through the mirror
Do not turn audit off and move on. You have a few options:
- Ask the mirror owner to enable forwarding of the advisory path.
- Run the audit step with the registry pointed at the upstream default for that one command, if your network policy allows it.
- Scan the lockfile with a separate tool that does not depend on the registry, so advisory lookup and package download are decoupled.
Option 3 tends to age best, because it keeps working when you change mirrors. It also lets you feed the same inventory to your reviewers, not just to CI.
Where Safeguard fits
Safeguard's SBOM and dependency scanning reads your project's dependency inventory, so it does not depend on which registry served the tarballs. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click into a finding and look at how severity and fix availability sit side by side, because that is the information a failed audit leaves you without.
Quick check
Does a mirror change which advisories npm knows about?
It can. The advisory data comes from whatever answers the audit request, so a mirror with its own data may be behind upstream. Ask how often it refreshes.
Can I just set audit to false in CI?
You can, but then nothing checks the tree. Replace it with a registry-independent scan first.
Sources
Last reviewed: 19 October 2026.
