The npm audit signatures command verifies the registry signatures of the packages you downloaded and also verifies their provenance attestations where present. It tells you a package came from the registry unmodified and, with provenance, where it was built. It does not tell you the package is safe.
What the npm documentation says
The npm audit documentation states that registry signatures can be verified with the audit signatures command, and that the command also verifies the provenance attestations of downloaded packages. It adds that provenance attestations are a new feature, that the attestation format may change over time, and that you should run the latest npm CLI, which often means updating npm beyond the version that ships with Node.js.
Two different checks
| Check | What it shows | What it cannot show |
|---|---|---|
| Registry signature | The registry signed the package data, so it was not altered after signing | That the publisher is trustworthy |
| Provenance attestation | The package links to a build and source, as claimed by the attestation | That the source or build is free of malicious changes |
Think of signatures as proof of delivery integrity and provenance as proof of origin. Neither is proof of good intent.
Where it fits in intake
- After install in CI. Run it as a check on the installed tree and fail the job on invalid signatures.
- As a signal, not a gate, for provenance. Many packages have no attestation. Treat a missing one as information for review, not an automatic block, unless you decide to require it for a set of critical packages.
- As a change detector. A package that had provenance in the last version and lost it in the new version deserves a closer look.
A phased approach
- Phase one: run the command in report mode on the main branch, and count what is signed, what has attestations and what fails.
- Phase two: fail the build on signature failures.
- Phase three: require provenance for a short list of high-impact packages, and alert on regressions.
Practical notes
- If you use a private mirror, check that signature data is available through it. A mirror that does not pass the signature material along will make the check fail or produce nothing useful.
- Keep the npm version consistent across CI and developer machines, since the documentation warns that attestation handling changes.
- Record the output with the build, as evidence of what was verified.
What to pair it with
Signatures and provenance work best alongside a holding period for new releases, scans for known malicious packages, install script controls and an approved list. A related guide on install scripts covers one of those layers.
Where Safeguard fits
Safeguard's dependency scanning, policies and gates can combine checks like this with vulnerability and license rules at pull request time. The free scan shows how an inventory looks.
Quick check
Does a valid signature mean a package is safe?
No. It means the data was not changed after signing. A malicious publisher can still publish a validly signed package.
Should I block packages with no provenance?
Not by default, since many have none. Consider requiring it for a short list of critical packages.
Sources
Last reviewed: 19 October 2026.
