SBOM vs attestation: composition, provenance and signatures

Compare the three concepts

Concept	Main question	Expected content
SBOM	Which components make up the software?	Component inventory and associated information
Build provenance	How was this artifact produced?	Inputs, steps and build context
Attestation	What statement concerns this artifact?	An identified subject and typed statement, optionally signed

An SBOM helps examine known software components. It does not necessarily describe the commands that produced a binary. Provenance describes production, but does not automatically provide a complete dependency inventory.

A signature is another dimension

A document can be signed regardless of its role. A signature lets a verifier check its integrity and connection to a key. It does not fill missing fields or establish the truth of its contents on its own.

You can therefore sign an SBOM or carry provenance in an attestation. These are useful combinations, not synonyms.

A release example

For an application archive, retain an SBOM associated with the version actually delivered. Also attach provenance linked to the resulting artifacts. Recipients should be able to associate each record with the right file and understand how to check its signature when present.

A Continuum Attest receipt covers the steps and files declared during the build. Its presence does not imply that a complete SBOM was generated: that requires a suitable tool and build step.

Where in-toto fits

in-toto provides a framework for statements about artifacts. The predicate type identifies what the contents mean. SLSA provenance uses that mechanism to describe production.

SBOM, provenance and attestation: three concepts often confused expands the example. Start with the CLI to put the provenance part into practice.

Reference: SPDX specifications, a standard used for SBOMs.