in-toto Supply Chain Attestation

Best Practice: in-toto Supply Chain Attestation

in-toto is a framework that secures the software supply chain by verifying that every step from source to finished artifact was carried out as the project intended. A project defines a layout that describes the expected steps, who is authorized to perform each one, and what materials and products each step should consume and produce. As the pipeline runs, each step emits a signed attestation (called link metadata). Before an artifact is trusted, in-toto verifies the attestations against the layout. It matters because most supply chain attacks insert or alter a step in the build; in-toto makes such tampering detectable. For a developer it is a way to prove the build was not tampered with; for a leader it raises supply chain assurance to an auditable standard. in-toto complements artifact signing: signing proves who produced the artifact, while in-toto proves the process that produced it followed the intended steps. The layout is the heart of the system: it is a signed policy describing the legitimate pipeline, and any deviation, an extra step, an unauthorized signer, or an unexpected input, causes verification to fail. This turns the build process itself into something that can be inspected and trusted, not just the artifact it produces.

Step-by-Step Implementation Guidance

1. Map your build and release pipeline into discrete, named steps.
2. Define an in-toto layout specifying the steps, authorized functionaries, and expected inputs and outputs.
3. Generate signing keys or identities for each step's functionary.
4. Wrap each pipeline step so it records signed attestations of what it did.
5. Collect the attestations alongside the final artifact.
6. Run in-toto verification against the layout before deploying or distributing.
7. Store attestations as auditable provenance for each release.

Common Mistakes Teams Make When Ignoring This Practice

• Trusting a final artifact without evidence of how it was produced.
• Allowing unauthorized or undefined steps to alter the build.
• Generating attestations but never verifying them before release.
• Defining a layout once and letting it drift from the real pipeline.
• Treating supply chain integrity as solely a signing problem, ignoring the process between steps.
• Securing the final signature while leaving intermediate build steps unattested and forgeable.

Tools and Techniques That Support This Practice

• The in-toto reference implementation and attestation specification.
• The in-toto attestation framework used by SLSA provenance.
• Cosign and Sigstore for signing attestations with short-lived identities.
• CI/CD systems that emit step metadata for each pipeline stage.
• Policy engines that gate deployment on successful in-toto verification.
• SLSA provenance generators that emit in-toto attestations directly from CI workflows.

How This Practice Applies to Different Migration Types

• Cloud Migration: Verify that artifacts deployed to the new environment carry valid provenance.
• Database Migration: Attest the integrity of schema and data migration tooling before running it.
• SaaS Migration: Prefer vendors who provide attested provenance for distributed components.
• Codebase Migration: Define a layout for the new pipeline so the rebuilt artifacts are verifiable end to end.

Checklist

• Mapped the pipeline into named steps
• Defined an in-toto layout with authorized functionaries
• Provisioned signing identities per step
• Recorded signed attestations for each step
• Collected attestations with the artifact
• Verified attestations against the layout before release
• Stored attestations as auditable provenance