Build provenance: connect artifacts to their build

What provenance describes

An archive named service.tar.gz contains software. Its filename and version do not explain which commands ran or which files produced it. Build provenance adds that context: execution, declared inputs, steps and results.

In Continuum Attest, attest.yaml defines the recorded scope. The CLI hashes declared inputs and outputs, runs the steps and records their results. Signing is explicitly enabled with attest run --sign.

Define a useful scope

For a compiled service, declare source code, the dependency manifest and its lockfile as inputs; declare the delivered binary as an output. Include build scripts that influence the result. A file read without being declared falls outside the recorded scope.

Useful provenance therefore starts with an accurate build description. Collecting more logs without identifying the corresponding artifacts makes those logs harder to interpret.

Signed provenance: from build record to receipt

Provenance is information about production. A signature binds the receipt to a key and makes changes detectable. Recipients independently choose which keys they trust, then check the receipt and available files.

Signing an incomplete or false record does not make it accurate. It protects the integrity of the statement. The reliability of the process producing that statement remains a separate question.

Formats and verification

Continuum Attest exports in-toto Statement v1 with a SLSA Provenance v1 predicate. Using that format alone does not demonstrate a SLSA level.

Read the receipt format for the signed fields, then the CLI documentation to create your first receipt. Trust is not evidence explains why pipeline status cannot replace portable evidence.

Reference: SLSA Build Provenance.