Integrity checks show a package was not altered after publication. Provenance shows where and how it was built. Neither proves the code is benign. Describe the checks you run for each and be clear that trust decisions still involve review.
Three questions, three controls
| Question | Control | Limit |
|---|---|---|
| Is this the file that was published? | Hashes in lockfiles, registry integrity data | Says nothing about intent |
| Who signed or built it? | Signatures, build attestations | Depends on trusting the signer |
| Is it harmless? | Review, behavior analysis, allowlists | Needs human or tool judgment |
NIST SP 800-218 includes the example of confirming the integrity of components through digital signatures or other mechanisms, and of building from source after verifying the source's integrity and provenance if binaries cannot be confirmed (PW.4.1, PW.4.4).
What provenance gives you
npm describes a provenance attestation as publicly providing a link to a package's source code and build instructions from the build environment, so developers can verify where and how a package was built before downloading it. It also states that this is not a guarantee that a package has no malicious code. A transparency log gives a public, tamper evident record of signed attestations.
SLSA, a set of incrementally adoptable supply chain guidelines established by industry consensus, describes producing and verifying artifacts and distributing provenance. It is useful vocabulary if a customer asks which framework you follow, but do not claim a SLSA level unless you have assessed it.
A truthful description
- Lock and verify. Installs come from lockfiles with integrity data.
- Check provenance where available. For packages that publish it, verify before first adoption.
- Prefer controlled sources. A mirror or allowlist limits pulls from open registries.
- Review. New packages and large version jumps get a human look.
Where the ecosystem offers no provenance, say you rely on the other controls.
Reply template
We install from lockfiles with integrity data, verify build provenance where the registry offers it, and pull from controlled sources. New dependencies are reviewed before adoption. We treat provenance as evidence of origin, not as proof the code is safe.
Related reading: abandoned package takeover risks.
Where answers usually break down
The common failure is claiming a control across the board when it applies to part of the estate. Provenance exists for packages whose publishers provide it, so a blanket "we verify provenance" is rarely accurate. Say which ecosystems you check, which you do not, and what you do instead for the rest.
A second failure is treating integrity data as a trust signal. A matching hash tells you the file is the one that was published, including when what was published was bad. Keep the two ideas separate in your reply and customers will see that you understand the difference.
Quick check
Does a signature mean a package is trustworthy?
It means the signer vouches for it. Whether you trust the signer is a separate decision.
Do we need SLSA to answer this?
No. It is a useful framework, but a clear description of your own controls is enough.
Sources
- NIST SP 800-218, Secure Software Development Framework 1.1
- npm Docs, Generating provenance statements
- SLSA, About SLSA
Last reviewed: 19 October 2026.
