Give the customer a SHA-256 checksum, sent through a different channel from the file, to confirm the file arrived unchanged. For proof of who issued it, sign the file, for example with cosign sign-blob, and share the signature bundle. A checksum shows integrity. A signature adds identity.
Two different questions
Customers may be asking one of two things:
- Did this file arrive intact? A checksum answers it.
- Did this file really come from you, and has nobody edited it since? Only a signature answers it, because anyone can compute a checksum of a modified file.
Pick the level that matches the risk. For routine procurement a checksum is often enough. For regulated buyers or large deployments, a signature is better.
Step by step: checksum
On your side:
sha256sum product-4.12.0-sbom-rev2.cdx.json
Send the output in your email or message, not inside the shared folder. If an attacker can swap the file in the folder, they can swap a checksum sitting next to it. Using a separate channel, such as the covering email while the file sits on a portal, closes that gap.
On the customer side, they run the same command and compare. On macOS the equivalent is shasum -a 256.
Step by step: signature
The Sigstore documentation describes cosign as able to sign and verify standard files and blobs, not just containers. The command is:
cosign sign-blob product-4.12.0-sbom-rev2.cdx.json --bundle bundle.sigstore.json
The documentation says the bundle contains verification metadata, including the artifact's signature, the certificate and proof of transparency log inclusion, and that you need to store the bundle for verification. Send the bundle alongside the SBOM.
The customer verifies with cosign's verify-blob command, supplying the bundle and the identity they expect. Follow the current Sigstore docs for the exact flags, since they can change between versions.
What to tell the customer
Write a short note with the SBOM:
- The file name, version and revision.
- The SHA-256 value.
- Whether a signature bundle is attached, and the identity it was signed under.
- How to verify, in two commands.
Keep it plain. People under review pressure will not read a long guide.
Limits to be honest about
A signature proves the file is unchanged since signing and ties it to an identity. It does not prove the SBOM is complete or correct. A signed SBOM can still miss components. For quality questions, see how to tell if a supplier SBOM is complete and compare against minimum elements guidance.
Also decide where you keep signed files. Store the signed original with the register entry so you can show the same bytes later. See version numbers for shared SBOMs.
Safeguard produces SBOM exports that you can sign with your own tooling, and its SBOM and dependency scanning keeps the inventory current. You can run a free scan to produce a sample file.
Quick check
Is a checksum enough to prove an SBOM is genuine?
No. It shows the file matches the checksum you sent. If the checksum comes from the same place as the file, an attacker could replace both. A signature is stronger.
Do customers need special software to verify?
For a checksum, only a standard command line tool. For a cosign signature, they need cosign installed.
Sources
Last reviewed: 19 October 2026.
