Verify Package Provenance
Check whether a package release has verifiable evidence that binds its published bytes to a source revision and build process.
A package page may link to a source repository, but that link does not prove that the archive installed by your application came from that source. This guide is for a package consumer deciding whether to accept one registry release. Start with the exact namespace, registry host, version, and resolved tarball in your lockfile. Do not review a similar package name or the repository's latest commit instead.
Consumer evidence card
| Item | Check |
|---|---|
| Registry | Is the resolved host the approved registry? |
| Package | Does namespace and version match the change request? |
| Lockfile | Does the resolved URL and integrity value match the install? |
| Registry proof | Are signature or provenance results valid for this release? |
| Publisher | Does the attested source and publish identity fit policy? |
| Decision | Accept, reject, or record an evidence gap |
For npm packages, use a disposable environment with no production secrets. Install from the lockfile with npm ci --ignore-scripts so untrusted lifecycle scripts do not run just for this check. Then use a supported npm CLI to run npm audit signatures. npm documents that the command checks registry signatures and available provenance attestations for installed packages. Treat a missing attestation separately from an invalid one. Check the CLI result for the selected version and retain the command version and output. Other ecosystems need their own registry-supported verification method; do not reuse npm's command as a generic package check.
Decide whether to install
Compare any provenance details with the package's intended repository, source commit, build workflow, and publisher. A valid registry signature helps detect altered registry content, but it does not show that the package code is benign. A source link alone does not bind installed bytes to that source. Review the archive contents and dependency change when the package has privileged access or handles untrusted input.
Record the lockfile revision, package name and version, registry host, resolved artifact digest, verification result, expected publisher, and reviewer. If provenance is unavailable, state that limit and choose a documented risk decision. If verification fails, stop the upgrade and investigate before installing it in a release. Repeat the check for each new version; proof for last month's version does not cover today's tarball.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.
Sources
- SLSA v1.2 Provenance SpecificationAccessed
- npm Docs: Viewing Package ProvenanceAccessed
- npm Docs: npm-ciAccessed