Kettle: Attested builds for verifiable software provenance

Authors: Amean Asad, Andr'e Arko

arXiv · PDF

Summary

Kettle is a build system that runs software compilation inside a trusted execution environment (a hardware-isolated virtual machine) and produces a cryptographically signed provenance document listing the source commit, dependencies, toolchain, build environment, and output artifact hashes. The TEE hardware signs the document's hash, so the signature chains to the chip vendor's root of trust rather than the build operator. Because the VM image is reproducible, verifiers can check one signature and a few hashes without re-running the build or trusting the infrastructure operator.

Main takeaways:

• Builds run in a confidential VM that produces a provenance document (source commit, dependencies, toolchain, environment, output hashes)
• The TEE hardware signs the document's SHA-256 hash, chaining trust to the chip vendor instead of the build operator
• The VM image is reproducible, so its launch measurement is public and stable — verifiers can pre-attest the VM before submitting source
• Source code can be delivered over TLS terminated inside the VM, so the build host never sees plaintext source
• Verification reduces to one signature check and a few digest comparisons; no need to re-execute the build or trust the artifact distribution channel

Relevance

Not related to my persona or midtraining work — this is a software supply-chain security tool for verifiable builds. Included because it's a useful reference if I ever need cryptographic provenance for model artifacts or training runs.

Abstract

arXiv:2605.08363v1 Announce Type: new Abstract: Kettle is an attested build system that produces cryptographically verifiable provenance for software built inside Trusted Execution Environments (TEEs). A Kettle build records the source commit, dependency set, toolchain, build environment, and output artifact digests in a provenance document produced inside a measured confidential VM. The SHA-256 digest of that document is committed to the TEE platform's attestation report-data field, so the hardware-signed attestation report is itself the signature on the provenance, with the signing identity chaining to the TEE manufacturer's root of trust rather than to the build infrastructure operator. Because the CVM image is itself reproducible, its launch measurement is public and stable, which lets a build requester pre-attest the CVM before submitting any input and optionally deliver source over a TLS channel terminated inside it, so the build runs end-to-end confidentially without the host ever seeing source code in plaintext. Verification reduces to one signature check against the vendor root and a small set of digest comparisons, with no need to re-execute the build. The result removes the build infrastructure, its operators, and the artifact distribution channel from the trust surface a verifier must accept when deciding whether a binary corresponds to its claimed inputs.