Artifact attestation: sign a verifiable statement

Identify the artifact before reading the statement

Two files can share a name while containing different bytes. Binding an attestation to the correct artifact requires a digest calculated under the relevant format’s rules. A release number is not enough.

The attestation then provides a statement, such as how the file was produced. Its signature lets a verifier check the statement’s integrity and its connection to an approved key.

Questions worth asking

• Which artifact and digest does the statement concern?
• Which steps and inputs were recorded?
• Which key signed it, and why does the recipient trust that key?
• Are the files needed for comparison available?

These questions distinguish an attestation file that merely exists in an archive from an attestation that has actually been checked.

The Continuum Attest receipt

The CLI records build steps and hashes within the declared scope. With signing enabled, the receipt becomes portable evidence: a recipient can check its signature using their own trust store.

Comparing files against the receipt also requires the relevant files and appropriate checks. Signature verification alone does not automatically inspect every delivered file. The CLI documentation distinguishes the available verification options.

Attestation, SBOM and provenance

An SBOM describes software composition. Provenance describes its production. An attestation carries a statement about an artifact. They are complementary; an attestation can carry provenance.

Read SBOM vs attestation to choose which documents to retain, then the receipt format to understand what is signed. The in-toto exchange format identifies artifacts and statement types without depending on a platform’s user interface.

Reference: in-toto Statement v1.