in-toto attestations & provenance

Signed statements about how an artifact was made.

A signature says "this identity vouches for this artifact." An attestation says more: it is a signed statement about the artifact — a claim, in a structured format, cryptographically bound to the exact artifact digest. The in-toto framework defines the envelope, and provenance is the most important attestation type: a machine-readable record of how the artifact was built (the source, the builder, the parameters, the inputs). It is the artifact’s verifiable birth certificate.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{ "name": "payments-api", "digest": { "sha256": "9f2a..." } }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "externalParameters": { "source": "git+https://.../acme/payments@<sha>" },
      "resolvedDependencies": [ /* pinned inputs */ ]
    },
    "runDetails": { "builder": { "id": "https://gitlab.acme.internal/ci" } }
  }
}

Attestations beyond provenance

Provenance is one attestation; the model generalizes. You can attest an SBOM (a signed claim about contents), a vulnerability scan result (a signed claim that the artifact passed scanning at a point in time), a test report, or a manual review sign-off. Each is a signed, structured statement bound to the digest, so a consumer can verify not just "who built this" but "was it scanned," "what is in it," "did it pass policy." The artifact accumulates a portfolio of verifiable evidence about itself.

# create and later verify a provenance attestation, bound to the digest
$ cosign attest --yes --predicate provenance.json --type slsaprovenance "$IMAGE@$DIGEST"
$ cosign verify-attestation --type slsaprovenance \
    --certificate-identity-regexp "https://gitlab.acme.internal/acme/.*" \
    --certificate-oidc-issuer https://gitlab.acme.internal \
    "$IMAGE@$DIGEST"

Bound to the digest, generated by the builder

Two properties make attestations trustworthy. They are bound to the immutable digest, so a claim about image@sha256:abc cannot be transplanted onto a different artifact. And, for provenance especially, they should be generated by the trusted builder rather than the build steps (the SLSA L3 idea) so the build cannot forge favorable claims about itself. Signed with Sigstore, bound to the digest, produced by a trusted builder, verified at the gate — that is the full chain from "we built something" to "you can prove what we built and how."