Install your dependencies, then run npm audit signatures. It verifies registry signatures and also checks the provenance attestations of downloaded packages. Provenance links a package to its source repository and build, which helps you audit it. It does not prove the code is free of malicious behavior.
What provenance is
The npm documentation says provenance includes two attestations. The provenance attestation publicly links a package to its source code and build instructions from the build environment, so developers can verify where and how it was built before downloading. The publish attestation is generated by the registry when an authorized user publishes. Packages published with provenance are signed through Sigstore public good servers and recorded in a public transparency log.
To publish with provenance, a maintainer must build on a supported cloud CI provider with a cloud-hosted runner. The docs name GitHub Actions and GitLab CI/CD. That is a limit on who can offer it, so a missing badge is not automatically a red flag for small projects.
The check, step by step
- Install dependencies from the lockfile with npm ci.
- Run npm audit signatures. The audit docs say it verifies registry signatures for packages from the public registry or any registry that supports signatures, and also verifies provenance attestations.
- Read the result. Missing or invalid signatures need an explanation before you proceed.
- For a new dependency, open its package page and look for the provenance information and the linked repository.
- Confirm the repository named in the attestation is the project you expect, not a fork or lookalike.
For a longer walkthrough see npm audit signatures and registry attestations.
What provenance does not tell you
The npm documentation is explicit that established provenance does not guarantee the package contains no malicious code. It gives a verifiable link to source and build instructions, which you can audit and then decide whether to trust.
| Provenance tells you | Provenance does not tell you |
|---|---|
| Which repository and workflow built it | That the source is harmless |
| That the registry recorded the publish | That the maintainer's account is safe forever |
| That the record sits in a public log | That dependencies of the package are clean |
A sensible rule for new developers
Treat provenance as a plus when comparing two similar packages, and as a reason to read the linked build workflow for anything sensitive. Do not treat its absence as proof of danger, and do not treat its presence as approval.
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 checks keep running after the first scan, since a package can change after you approve it.
Quick check
Does npm audit signatures replace npm audit?
No. One verifies signatures and attestations, the other reports known vulnerabilities. They answer different questions.
Can I trust a package because it has a badge?
The badge shows where it was built. You still decide whether to trust the code and its maintainers.
Sources
Last reviewed: 19 October 2026.
