Verify a supplier's release by checking the signature against the identity you expect, then checking the build attestation to see which repository and workflow produced it. A valid signature proves the artifact was not altered after signing. An attestation says where and how it was built. Neither proves the code is safe.
Two different questions
Was this file changed after the supplier produced it? A signature answers that.
Where and how was it built? Provenance answers that. GitHub's documentation says artifact attestations establish where and how your software was built, and SBOM attestations tie a bill of materials to the artifact it describes.
Sigstore, the open source signing project, aims to make the first question easier. Its documentation says signing uses ephemeral keys, so developers do not manage long-lived keys, and signing events go to a public log that anyone can audit. The parts are cosign, the client that signs; Fulcio, a certificate authority that issues short-lived certificates tied to an identity; and Rekor, an append-only ledger of signing records.
A verification routine
- Get the expected identity first. Ask the supplier, in writing, which repository, workflow or account signs releases. Do this before you look at the artifact.
- Verify the signature. For container images and files signed with Sigstore, use cosign and require the expected identity, not just any valid signature.
- Verify the attestation. For artifacts built on GitHub, the documentation shows
gh attestation verifywith the artifact path and the repository, and anoci://prefix for container images. - Read the claims. Confirm the repository name, branch or tag, and workflow match what you expected.
- Check the SBOM attestation if present. It should describe the exact artifact digest you hold.
- Record the result with the artifact digest and date, so you can show an auditor what you did.
What can still go wrong
| Situation | Why verification passes anyway |
|---|---|
| Compromised build workflow | The malicious build is signed by the real pipeline |
| Wrong identity accepted | You verified a signature, not the right signer |
| Stale attestation | It describes an older artifact |
| Malicious dependency | Provenance covers the build, not every input's intent |
That is why identity pinning in step one matters most. Verification without an expected signer is a checksum with extra steps.
What to ask a supplier who has no signing
Not every supplier signs yet. Ask for a roadmap, what they publish instead (hash lists on a separate channel, for example) and how they protect the build system. Treat unsigned delivery as a risk to manage, not an automatic no.
Try it yourself
Open the demo to see a container image scan, including the information recorded for each layer. Think about which of those details you would want tied to a signature.
Click through it at your own pace, or open it full screen.
Safeguard scans container images and generates SBOMs, which gives you a second view alongside any supplier attestation. A free scan is a place to start.
Quick check
Does a valid signature mean the software is safe?
No. It means the artifact matches what the signer produced. The signer can still ship a flaw.
Do I need Sigstore to verify releases?
No. Other signing schemes exist. The principle is the same: pin the expected signer, then verify.
Sources
Last reviewed: 19 October 2026.
