The npm audit signatures command verifies the registry signatures of packages you downloaded, and also verifies their provenance attestations. It tells you the package matches what the registry signed and, where an attestation exists, how it was built. It does not tell you the code is safe or free of vulnerabilities.
What the documentation says
The npm documentation describes verifying registry signatures with the audit signatures command. It adds that the same command verifies the provenance attestations of downloaded packages. Because attestations are a relatively new feature, the format may change, so the documentation advises running the latest npm CLI, which often means updating npm beyond the version that ships with Node.js.
Signatures live in the package metadata for each published version, in a signatures list holding a key identifier and a signature. The CLI also supports registries other than the default one, as long as they follow the same conventions.
Running it on a laptop
npm audit signatures
Run it from a project after an install. Treat output in three groups:
- Verified signatures and attestations. Good, and still not proof of safety.
- Packages without attestations. Common. Many packages have signatures but no provenance. Note which of your important dependencies lack it.
- Invalid or missing signatures. Stop and investigate before running the code. It could be a mirror or proxy that rewrites packages, or tampering.
What a valid result means
- The tarball you hold matches what the registry signed.
- If provenance is present, the package was built and published by the pipeline the attestation names.
This is useful against tampering in transit or at a mirror, and for confirming a build came from a specific repository and workflow.
What a valid result does not mean
Signed does not mean benign. A maintainer account that was compromised can still publish a signed package, and a compromised build pipeline can still produce a validly attested one. Attestation records the path, not the intent. Read it as evidence about origin, then judge the package on its own.
Making it part of a routine
- Update npm so verification keeps working with newer attestation formats.
- Run the command after dependency updates and before releases.
- Keep a short list of critical dependencies and expect attestations from them.
- Combine it with a delay before adopting new versions and with advisory scanning.
If the command starts failing in a corporate network, check whether a proxy modifies metadata before assuming the worst, but do check.
Reading a missing attestation
A package with no provenance is not automatically suspect. Many maintainers have not adopted it yet. What matters is change: if a dependency that used to publish with provenance suddenly does not, ask why before upgrading. Keeping a note of which of your important packages carry attestations makes that change easy to spot.
If you want a quick look at what your projects actually resolve, Safeguard offers SBOM and dependency scanning, and there is a free scan at gold.safeguard.sh/scan.
Click through it at your own pace, or open it full screen.
Quick check
Does a valid signature mean the package is safe?
No. It shows origin and integrity. A signed package can still contain malicious or vulnerable code.
Why update npm to use it?
The npm documentation says the attestation format may change, so you need the latest CLI to keep verifying correctly.
Sources
Last reviewed: 19 October 2026.
