Attested Builds
What attested builds are, how they work, how they fit into SLSA and in-toto, what they guarantee — and the field-by-field shape of the documents a build emits.
An attested build runs inside a Trusted Execution Environment and emits a signed record of exactly what went in and what came out, so a consumer can check that an artifact was built from the source it claims — without trusting the builder.
We assume familiarity with git, package managers, and the concept of cryptographic hashes.
Understand it
Read in order. Each one depends on the last.
01. What Are Attested Builds?
What attested builds are, why they matter, and how they solve the software verification problem. Covers the core insight, why reproducible builds remain elusive in practice, and why Trusted Execution Environments make a different approach possible now.
02. How It Works
The architecture and mechanics end to end. Each phase of the build, how cryptographic binding works at every step, and how verification closes the loop from source to running code — using Kettle, Confidential AI's implementation, as the reference.
03. Provenance & Standards
How the claims an attested build produces fit into the supply-chain ecosystem: what SLSA and in-toto are, why standards matter for interoperability, and how to read a provenance document.
04. Threat Model and Security Boundaries
The line between what attested builds protect against and what they don't — where the trust boundaries lie, which attacks are prevented, and which assumptions you are still making.