Kettle: Attested builds for verifiable software provenance

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.

• The paper introduces a build system that integrates TEEs and confidential VMs to cryptographically bind software provenance, mitigating host-level tampering.
• It employs a deterministic Merkle tree and in-toto SLSA attestations to ensure reproducible builds and secure, hardware-rooted signatures.
• The approach minimizes trust assumptions solely to TEE vendors and cryptographic primitives, significantly enhancing supply chain security.

Kettle: Attested Builds for Verifiable Software Provenance

Abstract and Motivation

The paper presents Kettle, a build system architected to generate cryptographically verifiable provenance of software artifacts via attestation from Trusted Execution Environments (TEEs). The system is designed to reduce the software consumer’s trust surface to only the TEE hardware vendor and associated cryptographic primitives, effectively rendering infrastructure operators and distribution channels untrusted. Kettle leverages measured confidential VMs (CVMs), chains provenance document digests into hardware attestation reports, and encapsulates the supply-chain context via SLSA Provenance v1.2 predicates in canonical in-toto attestations.

Problem Setting and Threat Model

The dominant challenge addressed is the gap between claimed and actual software provenance. Unlike systems relying on operational evidence (such as signed logs or CI metadata), Kettle binds the provider’s claims to the artifact through hardware-rooted cryptographic evidence. The security model trusts only the TEE hardware/firmware and cryptographic primitives; all software operators (hypervisor, host OS, CI runners, artifact storage, and network) are out of the trust boundary. Physical attacks and TEE hardware compromise are scoped out.

Kettle specifically mitigates:

• Host-level tampering during or after builds
• Provenance forgery
• Dependency substitution attacks

It explicitly does not address:

• Malicious inputs (source or upstream dependencies)
• TEE hardware compromise
• Side-channels or physical attacks
• Software vulnerabilities in the build outputs

Background and Comparison to Prior Art

Kettle is situated in the context of existing reproducible builds and TEE-based attestation systems:

• Reproducible builds provide verification by deterministic rebuild but are impractical for many real-world software stacks with non-deterministic toolchains or environments.
• Nix improves environment reproducibility but cannot cryptographically bind environment provenance to particular artifact outputs or attest the honesty of the builder.
• Attestable builds using enclaves (e.g., AWS Nitro Enclave) have previously provided hardware signatures over input/output hashes but either lack flexible environment reproducibility or require unverifiable trust anchors (e.g., operator-controlled PKI).

Kettle’s main innovations are the use of CPU-vendor-rooted attestation keys, SLSA provenance (including explicit Merkle-rooted input manifests), and self-reproducible releases that close prior bootstrapping gaps.

Architecture

Kettle’s architecture is structured around developer CLI, untrusted host, Kettle CVM (inside a TEE), and TEE hardware. The primary workflow involves:

1. The developer provides a nonce and VCS commit. Dependencies are fully locked and digested.
2. The trusted CVM is booted from a deterministically built image; reproducibility ensures verifiers can add the platform measurement to their allow-list.
3. All build steps (input acquisition, build execution, provenance assembly, output artifact digest) are performed inside the CVM, with network severance as an option.
4. The assembled provenance document’s SHA-256 digest is placed in the attestation report-data field, and the TEE hardware signs the combined measurement.
5. Three outputs are emitted: the artifact, a provenance.json (in-toto SLSA statement), and the raw attestation evidence.

Verification involves validating the chain: TEE attestation signature → report-data matches provenance JSON digest → artifact bytes match provenance.

Input Merkle Tree

The system constructs a deterministic, lexicographically ordered Merkle tree of all relevant inputs (source digest, dependency digests, toolchain digests). This enables concise, cryptographic inclusion proofs for any subset of the input set, supporting selective disclosure for sensitive dependency lists.

Reproducible Build Environment

The Kettle CVM image is built reproducibly. Its public, stable launch measurement allows verifier-side inclusion on an allow-list, ensuring trust does not transitively depend on any infrastructure image distributor.

Confidential Build Flow

For confidential source scenarios, pre-attestation allows a requester to verify the CVM environment (via a fresh nonce and attestation over a TLS session public key) before sending source over a mutual-authenticated, TE-terminated TLS channel, guaranteeing the host cannot learn plaintext source content.

Provenance Format and SLSA Compliance

Kettle emits provenance documents as in-toto Statements with SLSA Provenance v1.2 predicates, integrating seamlessly with modern supply-chain security tooling. Critical fields encode input identity, build environment, external and internal build parameters, and resolved dependencies. The builder is identified by a unique platform- and version-tied URI, and SLSA L3 compliance is achieved via the hardware-rooted signature and strict compartmentalization of build and control-plane logic. There is never a guest-accessible software signing key; all signatures are generated by hardware.

Security Analysis

The security posture is substantially improved relative to conventional CI systems:

• Host- or operator-level attacks are neutralized unless the attacker has physical TEE compromise capability.
• Output substitutions and provenance forgeries are cryptographically detected.
• Any variance in build environment, input, or output is identified by digest mismatch at validation.

The main residual threats are those inherited from the TEE threat model—side-channel leakage, upstream supply chain attacks, and physical hardware compromise—but these constitute a much-reduced attack surface compared to conventional build and distribution pipelines.

Open Directions

Future work includes:

• In-CVM defense-in-depth (mandatory access controls, system call filters, network curtailment after dependency fetch).
• Optionally layered inner sandboxes, isolating provenance assembly from untrusted build scripts run inside the CVM.
• Migration to newer hash algorithms (SHA-3, Blake3).
• Deep canonicalization of source file digests to mitigate weaknesses in upstream hashing schemes (e.g., Git’s SHA-1).
• Upstream integration with evolving supply chain standards and registry policies.

Implications and Potential for Future AI Developments

Kettle’s paradigm enables an independently and efficiently verifiable, hardware-rooted chain of evidence linking software artifacts to all inputs and toolchains. This approach refines the trust model for supply chain integrity, lowering the verification cost to a single signature and digest chain comparison and thus making widespread, fine-grained provenance validation tractable for both human and automated agents.

The practical implications are profound for critical infrastructure, proprietary software, and settings requiring regulatory compliance. Instantiations in AI/ML workflows could dramatically improve traceability, for example, in model reproducibility or secure deployment pipelines. The extensibility of Kettle’s approach (especially the confidential flow and pluggable provenance standards support) makes it suitable for inclusion in future secure build and provenance frameworks for AI artifacts.

Conclusion

Kettle introduces a robust method for cryptographically verifiable, hardware-attested software provenance, substantially minimizing the trust assumptions required in the software supply chain. By leveraging confidential VM-based builds, explicit Merkle-rooted input manifests, vendor-rooted attestation, and standard SLSA/in-toto provenance artifacts, Kettle provides supply-chain guarantees that are both stronger and more generalizable than reproducible builds alone. The approach facilitates efficient, local verification of provenance without requiring rebuilds or trust in CI operators and intermediaries, shifting the attack surface to the TEE hardware and the cryptographic algorithms underpinning it. This trust model and implementation path represent a significant practical advancement for secure software delivery pipelines.

---

Paper reference: "Kettle: Attested builds for verifiable software provenance" (2605.08363).