Possibly. The npm CLI can verify registry signatures and provenance attestations for downloaded packages, on the public registry or on any registry that follows its conventions. A mirror that drops the signature fields or does not expose the public keys will break that check. Test your mirror before you rely on it.
What the command checks
The npm audit command has a signatures mode. The docs say it verifies the registry signatures of downloaded packages and also verifies provenance attestations. The output reports counts, such as how many registry signatures and attestations were verified.
A registry signature shows that the registry vouches for the tarball it served. A provenance attestation links a package to its source repository and build instructions. The npm docs on generating provenance describe it as signed by Sigstore public good servers and logged in a public transparency ledger, and they say plainly that provenance does not guarantee a package is free of malicious code. It gives you a verifiable link to source and build.
What a mirror has to do
The CLI docs list conventions for a registry other than the public one. Signatures are published in each version's dist object, and public keys are exposed at a keys path under the registry. If your mirror rewrites package metadata and drops those fields, or does not serve the keys path, the check has nothing to verify.
| Mirror behavior | Result of the check |
|---|---|
| Passes metadata through unchanged | Counts verified as on the public registry |
| Rewrites metadata and keeps signature fields | Verification may work if keys are served |
| Drops signature fields or keys path | Nothing to verify, or errors |
The docs do not say what the CLI does with a registry that lacks signature support, so observe it directly.
Test it
Use a throwaway project with a few well known packages.
npm install lodash express
npm audit signatures
Read the output. If the counts of verified signatures are zero or the command errors, ask the mirror owner whether metadata is passed through. Then run the same command with the registry set to the public default and compare. A difference points at the mirror.
What this tells you and what it does not
Publisher side requirements limit coverage. Per the npm docs, provenance generation needs a supported cloud CI provider on a hosted runner, a recent npm CLI, and a repository field that matches the publishing repository. Many packages simply do not carry attestations, so a count of unverified attestations is normal.
So treat the result as one signal. A valid attestation answers where and how a package was built. It does not answer whether the code is trustworthy, whether a maintainer account was compromised, or whether a dependency is vulnerable.
A reasonable policy
- Run the signature check in CI as a report first, not a gate.
- Record the counts over a few weeks to learn your baseline.
- Alert if verified counts drop sharply after a mirror change.
- Pair it with dependency scanning, since verified provenance says nothing about known vulnerabilities.
Where Safeguard fits
Safeguard's SBOM and dependency scanning covers known vulnerabilities in the packages you resolve, the question provenance leaves open. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a monitored project surfaces a change after the fact, the same idea as watching your signature counts over time.
Quick check
Does a verified attestation mean a package is safe?
No. The npm docs say provenance does not guarantee a package is free of malicious code.
Why are some packages unverified in my report?
The publisher may not generate attestations, which has its own requirements. That is common.
Sources
Last reviewed: 19 October 2026.
