Scorecard's Signed-Releases check looks at the last five releases of a repository for signature or provenance files, such as .sig, .asc, .sigstore or .intoto.jsonl. It does not verify those signatures. To pass, sign each release archive and attach the signature file to the release.
What the check does
The checks documentation rates Signed-Releases as High risk. It inspects the five most recent releases and looks for files that look like signatures or provenance attestations. The examples it names are .sig, .asc, .sigstore and .intoto.jsonl.
Notice the limit stated in the same documentation: signatures are not verified. The check confirms that a signature file is present, not that it is valid or that it was made by a key you trust.
Why it matters
A signature lets a consumer confirm that an artifact came from a source they trust. Without one, anyone who can alter a download, a mirror or a release asset can change the contents without detection. Signing does not stop a compromised maintainer from signing a bad release, but it narrows the places an attacker can tamper.
How to pass
- Pick a signing method. Options include a GPG detached signature, which produces an .asc file, or keyless signing and attestations that produce Sigstore or in-toto files.
- Sign in CI, not on a laptop, where you can. A release built and signed by a workflow is easier to audit than one signed by hand.
- Attach the signature to every release. The check looks at the last five, so one signed release among five unsigned ones will not give full marks.
- Document verification. Tell users the exact command and the identity or key to expect. A signature nobody checks adds little.
Signing and package registries
Scorecard looks at release assets on the hosting platform. Many projects publish through a package registry instead. Registries have their own provenance features. For example, npm's trusted publishing documentation says npm generates provenance attestations automatically for public packages published from a public repository on GitHub Actions or GitLab, and not for CircleCI. See our guide to the differences between npm and PyPI trusted publishing: npm and PyPI trusted publishing compared.
For consumers
When you pick a dependency, a missing signature is a moderate signal, not a veto. Check whether the project publishes from CI and whether attestations exist at the registry. If you require verified provenance for a class of packages, write that into your dependency policy. Safeguard policies and gates can enforce rules like that on pull requests that add or change dependencies.
Quick check
Does a passing Signed-Releases score prove the release is authentic?
No. The check only confirms that signature or provenance files exist. Verifying them is a separate step.
Sources
Last reviewed: 19 October 2026.
