Unsigned releases are a weakness, not an automatic reject. A signature lets you verify that a release came from the claimed publisher and was not altered. Without one, you rely on other evidence: build provenance, pinned hashes, a reviewed diff and the registry's own integrity checks.
What a signature gives you
OpenSSF Scorecard includes a Signed-Releases check, rated high risk, that asks whether releases are cryptographically signed. The point of signing is verification: when you download an artifact, you can confirm who produced it and that it was not changed after signing.
Without signatures, a compromised mirror, release page or storage bucket could swap an artifact and you would have no cryptographic way to notice. That risk is mostly relevant when you download release binaries or tarballs directly from a project page. For packages installed through a registry, the registry adds its own integrity data.
Signature, provenance and checksum are different
| Item | Answers | Limit |
|---|---|---|
| Checksum | Is this the file the page listed? | Anyone who changes the file can change the page |
| Signature | Did the key holder produce this? | Key can be stolen, and trusting the key is a separate decision |
| Build provenance | Where and how was it built? | Does not prove the source is benign |
The npm documentation describes provenance attestations as signed through Sigstore public good servers and logged in a public transparency ledger, and says a verified attestation shows where a package was built, not that its code is safe. For more, see checksum versus signature.
When it matters most
- You download binaries or installers from a project site, rather than a registry.
- The package will run in your build pipeline or with elevated privileges.
- You mirror or cache artifacts inside your company.
For a registry hosted library used as a normal dependency, missing signatures are a smaller concern than a missing owner list or a dangerous workflow.
How to compensate
- Pin the exact version and record its content hash in the lockfile.
- For npm packages, run
npm audit signaturesto check what registry signatures and attestations exist. - Diff each upgrade rather than accepting it blindly.
- Fetch artifacts only from the official source, and cross-check the checksum from a second place such as the repository.
- Ask the maintainer whether signing is planned. Many are glad to adopt it when someone asks.
- Record the gap and the compensating control in your adoption record.
A reasonable policy
Treat unsigned releases as a required condition, not a veto, for low and medium blast radius packages. For code that runs at privileged points, require either signatures or provenance, plus a human read of changes.
Safeguard can help here. Its SBOM and dependency scanning, reachability analysis and policy gates cover the checks that should repeat after adoption, and the free scan at gold.safeguard.sh/scan shows what a project already depends on.
Quick check
Does a valid signature mean the release is safe?
No. It proves who signed it and that it was unchanged. A signed file from a compromised maintainer is still harmful.
Is provenance a replacement for signing?
They answer related but different questions. Where you can, look for both.
Sources
Last reviewed: 19 October 2026.
