Use cosign sign-blob with a bundle output to sign any file, such as a tarball or installer. Publish the bundle next to the file. Consumers then run verify-blob with the bundle and the signer identity they expect, which checks both the signature and who made it.
Sign a file
Keyless signing is the documented recommendation:
cosign sign-blob <file> --bundle bundle.sigstore.json
With your own key:
cosign sign-blob --key cosign.key --bundle bundle.sigstore.json README.md
The docs say the bundle is the recommended way to sign a blob, because users pass one bundle instead of separate signature and certificate files. In CI, a yes flag skips confirmation prompts.
Verify a file
cosign verify-blob <file> --bundle artifact.sigstore.json \
--certificate-identity=name@example.com \
--certificate-oidc-issuer=https://accounts.example.com
The identity and issuer are the point. Without them you only learn that someone signed, which anyone can do.
For key based signing, verify with the public key. If the key lives in a KMS, the docs suggest exporting the public key once, so verification does not need a KMS call.
Checksum, signature or bundle
| Method | Proves integrity | Proves who signed | Notes |
|---|---|---|---|
| Checksum file alone | Only if the checksum came from a trusted channel | No | Attacker who swaps the file can swap the sum |
| Signature with a key | Yes | Yes, by key | You manage keys |
| Bundle with keyless signing | Yes | Yes, by identity | Needs trust roots and the bundle |
A release routine
- Build the file in CI and compute its digest.
- Sign with the CI workload identity, writing a bundle.
- Upload the file, the bundle and the checksum to the release page.
- In your install docs, show the exact verify command with your real identity and issuer filled in.
- Test the instructions on a clean machine.
Pitfalls
- Losing the bundle. The docs say to keep it, since it holds verification metadata.
- Publishing the verify command without the identity flags.
- Signing on a developer laptop with a personal identity, which makes the identity hard to explain to users.
- One doc example passes an image reference to sign-blob, which looks like a mistake, so check your target is a file path.
What signing does not cover
A signed file can still be malicious if the pipeline or source was compromised. Signing says who published it, not that it is safe.
Where Safeguard fits
Safeguard's SBOM and dependency scanning and policy gates help check what goes into a release before you sign it.
Quick check
Do I need the bundle to verify later?
Yes, or the separate signature and certificate. The bundle keeps them together with log evidence.
Is a published SHA-256 enough?
Only if the sum is delivered over a channel an attacker cannot change. A signature verified against an identity is stronger.
Sources
Last reviewed: 19 October 2026.
