SBOM, provenance and attestation: three concepts often confused

Start with a specific file

A team delivers service.tar.gz. The recipient wants to know which libraries it contains, understand its production and check that the documents concern their archive. These questions are related, but require different information.

The SBOM supports examination of declared composition. Provenance gives production context. An attestation attaches a statement to an identified subject. SBOM vs attestation compares their roles.

Why one record cannot replace the others

A component list does not necessarily identify the command that produced the archive. A build record may include a lockfile without enumerating every component in the final result.

The aim is therefore not to pick a single term. It is to identify the question, then the record providing the information needed to answer it.

A dependency update, for example, appears in composition and may also change provenance. Both records remain useful even when they mention the same component, because they place it in different contexts.

Add a signature without changing the document’s purpose

A signature connects signed bytes to a key. It does not turn an SBOM into an exhaustive build description. It does not fill in inputs missing from provenance.

Recipients must still check the connection to the artifact and determine which keys they approve. in-toto helps express the subject and statement type in an exchange format.

A specific role for the receipt

Continuum Attest records production within a declared scope and can sign the resulting receipt. An SBOM generation step can be part of the build, but producing the receipt does not automatically produce that inventory.

After choosing the records, they still need to be retained and delivered with the correct file. Continue with The software is delivered. Its evidence should be too..