in-toto and Continuum Attest signed receipts

Distinguish three layers

The Statement connects a declaration to artifacts identified by their digests. The predicate expresses the declaration’s content. The DSSE envelope carries signed data and signatures.

This separation helps a receiving tool recognize the document, identify its subject and interpret its provenance. It does not require the recipient to use the producer’s interface.

Export a receipt

After creating a receipt and preparing the necessary keys, run:

attest export --receipt receipt.yaml --format in-toto --output statement.json

The CLI documentation describes export and import commands. The receipt format remains the reference for the native document and its contents.

Check interoperability in practice

For a receiving tool, check the Statement version, predicate type, supported algorithms and how keys are approved. Readable JSON does not establish that a signature was checked.

A useful trial uses an artifact and its attestation, then repeats verification after changing either the file or the statement. The result should identify the check that failed.

SLSA and Sigstore in this picture

SLSA defines a provenance format and graduated requirements for software production. Emitting a SLSA predicate does not demonstrate achievement of a level. Sigstore provides signing and verification tools and services; its name does not describe provenance content.

in-toto, SLSA, Sigstore: who does what? explains their roles. SBOM vs attestation places complementary records in context.

References: in-toto specifications and SLSA 1.2.