implementing-supply-chain-security-with-in-toto

Generate Ed25519 keys for each functionary, define a signed layout with steps for checkout, build, and scan, then record each step with in-toto-run. Before deployment, run in-toto-verify against the layout and link metadata, and fail the pipeline on a non-zero exit.

in-toto-verify checks that all required steps ran, each was signed by an authorized functionary, and artifact hashes chain correctly between steps. A ValidatingWebhook with failurePolicy Fail enforces this at admission so tampered images are blocked.

Yes, in-toto attestations map directly to SLSA levels, from documented build processes at Level 1 to two-party review and hermetic builds at Level 4. It also integrates with Sigstore for keyless signing of attestations.

Common causes include verifying with the layout's embedded keys instead of an out-of-band owner public key, loose artifact rules without MATCH constraints, or an expired layout. Mutating one byte of a product and re-running verification should fail; if it passes, the trust chain is broken.

You need Python 3.8+ or a Go runtime for the in-toto client libraries, GPG or Ed25519 keys for signing, a container build tool such as Docker, Buildah, or Kaniko, a container registry, and a Kubernetes cluster for deployment verification.