Use an embedded signature when the SBOM file will be passed around on its own, and a detached signature or attestation when you store SBOMs next to the artifact they describe. Either way, say what the signature covers and give readers the key or identity they need to verify it.
The two shapes
Embedded. The signature is a field inside the SBOM document. CycloneDX supports this: its JSON schema includes a signature property described as an enveloped signature in JSON Signature Format. The schema allows several signers, so more than one party can sign the same document.
Detached. The signature is a separate file or record that refers to the SBOM by its digest. A common pattern is to attach the SBOM to a container image as an attestation and sign that statement. The SBOM itself stays unchanged.
| Property | Embedded | Detached |
|---|---|---|
| Travels with the file when emailed or downloaded | Yes | Only if you send both |
| Works for any format | Depends on format support | Yes, signs a digest of the bytes |
| SBOM content must be edited to add it | Yes | No |
| Easy to bind to an image or release digest | Less direct | Direct |
| Adding a second signer later | Possible if the format allows | Add another signature |
| Risk that a tool re-serialises and breaks it | Higher | Lower, if bytes stay identical |
The re-serialisation trap
A signature covers specific bytes or a canonical form. If a tool opens the SBOM, reformats it and saves it, an embedded signature may no longer verify, even though the content is the same. Detached signatures over the original bytes avoid that, provided nobody changes the file. Test this: pass a signed SBOM through the tools in your pipeline and verify it at the end.
What a signature proves
A valid signature shows that the holder of a key or identity signed these bytes, and that they have not changed since. It does not show that the SBOM is complete or that the build was clean. Say so in your documentation. Readers who understand the limit trust the signature appropriately.
How to choose
- Do consumers receive the SBOM file alone, for example from a download page? Prefer embedded, or publish the signature at a stable address next to it.
- Do you already sign images and attach metadata to them? Prefer a detached attestation tied to the digest.
- Do several parties vouch for the document? Check that your format supports multiple signers.
- Will downstream tools rewrite the file? Prefer detached.
Steps to put it in place
- Decide what is signed: the file bytes, or a statement that names the artifact digest.
- Decide who signs, and how a reader will learn the verification key or identity.
- Sign in CI after the final SBOM is produced, never before post processing.
- Verify in CI as a separate step, so a broken signature fails the build.
- Publish the verification instructions with the SBOM.
Where Safeguard fits
Safeguard produces SBOMs and applies policies and gates in your pipeline, so you can check an SBOM before a release proceeds. Start with the free scan at gold.safeguard.sh/scan. Confirm signing options for your setup before relying on them.
Quick check
Does a signed SBOM mean it is accurate?
No. It shows who signed and that the bytes are unchanged, not that the content is complete.
Which is easier to automate?
Detached signing in CI over the final file is usually simpler, because nothing in the document changes.
Sources
Last reviewed: 19 October 2026.
