An SBOM is an inventory: what components make up a piece of software. An attestation is a signed statement about an artifact, such as who built it, from which source and whether it passed a check. The SBOM answers "what is inside?" and the attestation answers "can I trust this claim about it?"
What is an SBOM?
The NTIA's minimum elements report describes an SBOM as a formal record containing the details and supply chain relationships of the components used in building software. Two common formats are SPDX and CycloneDX. A good one lists each component, its version and supplier, and how components depend on one another.
What it lets you do: when a new vulnerability is announced in a library, search your inventory and find every product that contains it, in minutes instead of weeks.
What it does not do: prove that the list is correct, complete or unmodified. An SBOM is a document, and anyone can write one.
What is an attestation?
An attestation is an authenticated statement about a software artifact. The in-toto project describes its aim as ensuring the integrity of a software product from initiation to end user installation, by making it transparent what steps were performed, by whom and in what order. A statement names a subject, usually by its digest, a type of claim and the claim's content, and it is signed.
Many kinds exist. Provenance says where, when and how an artifact was produced; SLSA's provenance specification defines it as verifiable information about software artifacts describing exactly that. Others record test results, vulnerability scan results or review approvals. An SBOM can itself be wrapped as an attestation, which gives the inventory a signature and ties it to a specific artifact.
How do they differ?
- What it describes. An SBOM describes the components inside. An attestation can describe any claim about an artifact.
- Who made it. An SBOM does not prove that by itself. A signed attestation does, once verified.
- Tie to one artifact. An SBOM is tied only if you bind it. An attestation is tied through its subject digest.
- Typical use. SBOMs serve vulnerability and license lookup. Attestations serve policy decisions at deploy time.
Why do you need both?
Constructed example: a team ships a container image. The SBOM says it contains library X version 1.2. A scanner later reports a flaw in X 1.2, and the SBOM tells the team which services to patch. Separately, the deploy gate demands a provenance attestation from the official build pipeline for every image. An image built on a laptop has no valid attestation and is refused, even though its SBOM looks fine.
One tells you what to worry about. The other tells you whether the thing running is the thing you meant to run.
Where do these things go wrong?
- Generated after the fact. An SBOM made by scanning a finished image may miss components that the build knew about.
- Not verified. An attestation nobody checks is decoration. The verifier must check the signature, the signer's identity and the claim.
- Overtrust. A signed statement that the build passed a test only proves that someone signed it.
- Stale. An SBOM from last release does not describe this one.
The NIST Secure Software Development Framework recommends practices producers can use to reduce vulnerabilities in released software, and both artifacts support evidence for those practices.
Safeguard generates SBOMs from dependency scanning and applies policies and gates on what may ship. Teams can use those to decide what to allow into production.
How to check or apply this
- Generate an SBOM at build time for every release, in SPDX or CycloneDX.
- Bind it to the artifact digest and sign it.
- Record provenance from your build system and sign that too.
- Decide what you will enforce: for example, only deploy images with valid provenance from your pipeline.
- Verify at the point of use, not only when you create the document.
- Keep the documents with the release so you can answer questions later.
- Feed the SBOM into vulnerability monitoring so new disclosures trigger searches.
Quick check
Is a signed SBOM an attestation?
Effectively yes, if it is packaged as a signed statement about a specific artifact. The signature adds integrity and origin to the inventory.
Which should I start with?
Start with SBOMs, because they pay off the first time a vulnerability hits. Add provenance attestations when you are ready to enforce build integrity.
Sources
- NTIA, The Minimum Elements For a Software Bill of Materials
- SPDX, About
- CycloneDX specification overview
- in-toto
- SLSA provenance
- NIST SP 800-218, Secure Software Development Framework
Last reviewed: 18 October 2026.
