Trust is not evidence — A green pipeline is not proof

Status stays in the platform

Imagine a successful build on Monday. Its archive is copied, renamed and delivered. Three months later, someone asks whether the retained file really corresponds to that build.

A green screenshot does not connect the file’s bytes to the execution. A job link can help recover context, but still depends on platform access, permissions and log retention.

The problem is not the status color. It is the missing information needed to compare a delivery with what was recorded during production.

Give verification an object

Build provenance describes the recorded scope: inputs, steps and artifacts. A Continuum Attest receipt gathers that information. With signing enabled, it becomes a record whose integrity can be checked using an approved key.

That record can stay with the files. Verification moves beyond the producer’s screen, giving the recipient a specific object to examine.

Trust remains explicit

“Trust is not evidence” does not mean trust disappears. Verifiers must choose approved keys and understand the process that recorded production. Signing a false statement does not make it accurate.

The difference is that assumptions become open to examination: who signs, which files are declared and which checks can be repeated? The receipt format documents that technical contract.

Try it with one release

Choose a simple build. Declare its inputs and outputs, produce a signed receipt, then check it from another environment. Change a declared file and observe the hash check. This distinguishes evidence that is merely present from evidence that is actually used.

To choose the records that should accompany this exercise, continue with SBOM, provenance and attestation: three concepts often confused.