Kettle: Attested builds for verifiable software provenance

Amean Asad; Andr\'e Arko

arxiv: 2605.08363 · v1 · submitted 2026-05-08 · 💻 cs.CR · cs.SE

Kettle: Attested builds for verifiable software provenance

Amean Asad , Andr\'e Arko This is my paper

Pith reviewed 2026-05-12 01:04 UTC · model grok-4.3

classification 💻 cs.CR cs.SE

keywords software provenancetrusted execution environmentsattested buildsverifiable buildsconfidential computingsoftware supply chain securitycryptographic attestation

0 comments

The pith

Kettle produces hardware-attested provenance for builds inside confidential VMs so verifiers confirm binaries match claimed inputs by trusting only the TEE vendor.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper introduces Kettle as a build system that executes inside trusted execution environments and captures the source commit, dependencies, toolchain, environment, and output digests in a provenance document. That document's digest is written into the TEE attestation report-data field, so the hardware signature on the report also covers the build record and chains to the manufacturer's root of trust. Verification then collapses to checking that signature plus a handful of digest comparisons, without re-running the build or trusting the operators who run the build servers. The approach also allows the build requester to pre-attest the confidential VM image and deliver source code over an in-VM TLS channel so the host never sees plaintext inputs.

Core claim

Kettle 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 ch

What carries the argument

The provenance document whose digest is placed in the TEE attestation report-data field, with the CVM image being reproducible to enable pre-attestation and confidential input delivery.

If this is right

Verification requires only one signature check against the vendor root and a small set of digest comparisons, with no need to re-execute the build.
Builds can run end-to-end confidentially without the host seeing source code in plaintext.
The build infrastructure, its operators, and the artifact distribution channel are removed from the trust surface a verifier must accept.
Requesters can pre-attest the CVM image before submitting inputs.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

Similar provenance mechanisms could apply to other reproducible build pipelines if they gain hardware attestation primitives.
The model reduces the value of compromising build servers or distribution networks for supply-chain attacks.
Widespread use would shift verification costs from repeated rebuilds to lightweight signature and digest checks.

Load-bearing premise

The TEE platform must deliver a trustworthy attestation report whose signing identity chains to the manufacturer's root of trust, and the confidential VM image must remain reproducible with a public and stable launch measurement.

What would settle it

An attestation report accepted by verifiers whose report-data digest does not match the actual provenance document, or a publicly distributed CVM image whose launch measurement changes without notice.

Figures

Figures reproduced from arXiv: 2605.08363 by Amean Asad, Andr\'e Arko.

**Figure 1.** Figure 1: A build is a many-input transformation. Source identity is necessary but incomplete because dependencies, toolchains, build scripts, and execution state also affect the final bytes. 2.2 SLSA Software Provenance As described by The Linux Foundation, “SLSA is a specification for describing and incrementally improving supply chain security, established by industry consensus” [10]. Among other things, the SLSA… view at source ↗

**Figure 2.** Figure 2: Measured boot inside a CVM. The hypervisor, host OS, BIOS, device drivers, and cloud operator sit outside the confidentiality boundary. Inside, the security processor extends a digest of each loaded layer (firmware, initrd, kernel, user space, deployed workload) into a single cumulative measurement that is later carried in the attestation report. Implementations. Current commercial TEEs from AMD [6] and In… view at source ↗

**Figure 3.** Figure 3: Reproducible builds verify provenance by independent reconstruction. The original build and the rebuild must converge on the same output digest from the same declared inputs. A number of projects work on making this practical across the open source ecosystem. One of them is the Reproducible Builds project [1], which supports reproducibility efforts across many parts of that ecosystem. Lamb and Zacchiroli [… view at source ↗

**Figure 4.** Figure 4: The host launches the CVM but cannot observe its memory. Inside the CVM, the build observes its declared inputs and produces a SLSA provenance document together with a hardware-signed attestation report that commits to it. The signed evidence is the only state the verifier later trusts. Trusted Untrusted Out of scope TEE hardware vendor (AMD, Intel) and signing keys Hypervisor and host OS Invasive physica… view at source ↗

**Figure 5.** Figure 5: Kettle build at a glance. The client commits the input and requests a build. The build runs inside a freshly-launched CVM, which generates a provenance document and emits an attestation signed by the TEE processor with a key chained to the CPU vendor root. The bundle returned to the client is verifiable locally against that root. The result is a single bundle (the artifact, provenance.json, and the raw att… view at source ↗

**Figure 6.** Figure 6: Kettle build sequence. The developer creates a VCS commit and submits the build request to the host (1–2). The host launches the CVM (3). Inside the CVM, measured boot extends the launch digest in TEE hardware (4). Kettle fetches the repo, commit, and dependencies, then (5) runs the build and digests outputs (6), and assembles the provenance document as SLSA 1.2 build provenance JSON (7). It then requests … view at source ↗

**Figure 7.** Figure 7: Input manifest as a Merkle tree. Each declared input is digested into a leaf, leaves are paired and hashed into internal nodes, and the procedure repeats until a single root remains. The root is recorded in the provenance document, whose digest is committed to the attestation report. Any change to any input bubbles up and changes the root. The root of this tree is a single digest that uniquely identifies t… view at source ↗

**Figure 8.** Figure 8: Measured boot extends each loaded component into a single cumulative launch measurement, which becomes the measurement field of the attestation report. The report_data field carries a SHA-256 digest of the canonical provenance document and the nonce from the build request. The whole report is signed by the platform attestation key. The attestation report is therefore the signature on the provenance, with n… view at source ↗

**Figure 9.** Figure 9: Evidence chain and verification. Each link binds to the next, and each numbered check verifies one link. Verification is local. Consumer tooling reads the artifact, provenance.json, and the raw evidence blob from a single bundle and runs the checks in order, with no remote service contacted. Step What consumer tooling checks Step 1: Verify the TEE attestation The attestation signature chains to the hardwa… view at source ↗

**Figure 10.** Figure 10: Pre-attested confidential build. The requester generates a single nonce that the hypervisor commits into the CVM’s host_data field at launch and that Kettle inside the CVM also includes in report_data. The first attestation therefore proves three things at once. The CVM is running Kettle code, it was uniquely launched for this requester, and the report itself is fresh. Source is then delivered over a TLS … view at source ↗

read the original 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.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

Kettle's design for hardware-attested provenance via reproducible confidential VMs is coherent but stands or falls on whether the CVM image can actually be made perfectly stable.

read the letter

The main point is that this paper describes a build system where provenance gets bound directly into a TEE attestation report, so a verifier only needs to trust the hardware root and a few digests rather than the build host or distribution channel. The CVM runs the build confidentially, with source delivered over TLS terminated inside it, and the report-data field carries the provenance hash. Because the CVM image is claimed to be reproducible, its measurement is public and fixed, letting a requester pre-attest before sending inputs. That is the core mechanism, and the abstract lays it out cleanly without obvious internal contradictions. The combination of reproducible CVM launch, in-TEE TLS, and direct use of the attestation field for provenance does appear new relative to the cited prior work on attested builds and confidential computing. It gives a practical path to shrink the trust surface for open-source binaries if the pieces fit. The soft spot is exactly the one the stress-test flags: the entire removal of build infrastructure from the trust model requires that the CVM image itself never varies in measurement. Any nondeterminism in its construction—timestamps, absolute paths, compiler behavior, or platform differences—breaks pre-attestation and reintroduces the need to trust whoever built the CVM or to re-execute its build. The abstract states the reproducibility as given but supplies no details on how it is achieved, no measurements, and no evaluation of edge cases. Without those, the central claim cannot be checked for practicality. There is also no expanded threat model or implementation results visible. This is for people already working on supply-chain security and confidential computing who want to see how TEE attestation can be applied to provenance. A reader comfortable with SGX or SEV concepts would get value from the architecture sketch. It deserves peer review because the mechanism is technically grounded and the problem is real, even if the reproducibility assumption needs concrete support before the claims can be fully evaluated.

Referee Report

3 major / 2 minor

Summary. 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. 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. 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.

Significance. If the central assumptions hold, Kettle provides a meaningful reduction in the trusted computing base for software provenance by shifting reliance from build operators and infrastructure to hardware attestation roots. This could strengthen supply-chain security for reproducible builds without requiring verifiers to re-execute or trust additional parties, building directly on existing TEE attestation primitives.

major comments (3)

[Abstract] Abstract: The claim that 'the CVM image is itself reproducible' with a 'public and stable' launch measurement is load-bearing for the pre-attestation step and the removal of build infrastructure from the trust surface. The manuscript provides no description of the CVM image construction process, no enumeration of eliminated sources of non-determinism (timestamps, paths, compiler seeds, etc.), and no evidence or reference demonstrating that the measurement remains invariant across builds.
[Abstract] Abstract: The architecture assumes that the TEE platform's attestation report provides a trustworthy binding whose signing identity chains to the manufacturer's root of trust, yet the manuscript contains no threat model, no analysis of attestation forgery or CVM isolation failures, and no discussion of how a verifier would handle revocation or platform-specific quirks.
[Abstract] Abstract: Verification is described as 'one signature check ... and a small set of digest comparisons' with 'no need to re-execute the build,' but the manuscript supplies neither the exact verification algorithm nor any argument that this procedure is sufficient to detect all relevant provenance violations under the stated threat model.

minor comments (2)

[Abstract] The abstract would benefit from naming the target TEE platform(s) (e.g., AMD SEV-SNP, Intel TDX) and the specific attestation report format used.
No references to prior work on reproducible builds (e.g., Nix, Bazel, or SLSA) or TEE-based attestation systems appear in the provided text; adding a short related-work paragraph would clarify novelty.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the positive summary and the recommendation for major revision. We address each major comment below and will make the indicated changes to strengthen the manuscript.

read point-by-point responses

Referee: [Abstract] Abstract: The claim that 'the CVM image is itself reproducible' with a 'public and stable' launch measurement is load-bearing for the pre-attestation step and the removal of build infrastructure from the trust surface. The manuscript provides no description of the CVM image construction process, no enumeration of eliminated sources of non-determinism (timestamps, paths, compiler seeds, etc.), and no evidence or reference demonstrating that the measurement remains invariant across builds.

Authors: We agree that the abstract claim requires explicit supporting detail. The manuscript currently mentions reproducibility only at a high level. In the revision we will add a dedicated subsection describing the CVM construction process, enumerate the eliminated sources of non-determinism (fixed timestamps, absolute paths, disabled compiler randomization, pinned dependencies), and include both the public build recipe and the resulting stable launch measurement hash as evidence. revision: yes
Referee: [Abstract] Abstract: The architecture assumes that the TEE platform's attestation report provides a trustworthy binding whose signing identity chains to the manufacturer's root of trust, yet the manuscript contains no threat model, no analysis of attestation forgery or CVM isolation failures, and no discussion of how a verifier would handle revocation or platform-specific quirks.

Authors: We acknowledge that the current manuscript assumes standard TEE attestation properties without a dedicated analysis. We will expand the existing threat-model section to include explicit discussion of attestation forgery vectors, CVM isolation failure scenarios, revocation handling via vendor certificate mechanisms, and platform-specific considerations for the TEEs under consideration. revision: yes
Referee: [Abstract] Abstract: Verification is described as 'one signature check ... and a small set of digest comparisons' with 'no need to re-execute the build,' but the manuscript supplies neither the exact verification algorithm nor any argument that this procedure is sufficient to detect all relevant provenance violations under the stated threat model.

Authors: We agree that a precise verification procedure and sufficiency argument are needed. In the revision we will add pseudocode for the verification algorithm and a short proof sketch showing that the combination of attestation signature verification, report-data binding, and provenance digest checks detects the relevant classes of provenance violation (mismatched inputs, tampered artifacts) under the TEE threat model. revision: yes

Circularity Check

0 steps flagged

No significant circularity; claims rest on external TEE properties and stated reproducibility assumption

full rationale

The paper presents a system architecture for attested builds without equations, fitted parameters, or mathematical derivations. The central claim that build infrastructure is removed from the trust surface follows from standard hardware attestation chaining to the vendor root plus the explicit assumption that the CVM image is reproducible (yielding a stable launch measurement). This assumption is stated directly rather than derived from prior steps in the paper. No self-citations, self-definitional loops, or renamed known results appear in the abstract or described chain. Verification is reduced to signature validation and digest checks using ordinary cryptographic primitives.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The central claim rests on standard TEE security properties and reproducibility of the VM image; no free parameters or new invented entities are introduced in the abstract.

axioms (2)

domain assumption TEE hardware attestation report-data field can be used to bind a provenance document hash to a hardware signature that chains to the manufacturer root of trust
Invoked when stating that the attestation report itself signs the provenance.
domain assumption The CVM image is reproducible with a public and stable launch measurement
Required for pre-attestation by the build requester.

pith-pipeline@v0.9.0 · 5504 in / 1295 out tokens · 51190 ms · 2026-05-12T01:04:09.491443+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

11 extracted references · 11 canonical work pages

[1]

https://reproducible-builds.org

Reproducible Builds.Reproducible Builds project. https://reproducible-builds.org

work page
[2]

Lamb and S

C. Lamb and S. Zacchiroli. Reproducible Builds: Increasing the Integrity of Software Supply Chains.IEEE Software, 39(2):62–70, 2022. https://doi.org/10.1109/MS.2021.3073045. Preprint: https://arxiv.org/abs/2104.06020

work page doi:10.1109/ms.2021.3073045 2022
[3]

Dolstra, M

E. Dolstra, M. de Jonge, and E. Visser. Nix: A Safe and Policy-Free System for Software Deployment. InProceedings of the 18th USENIX Conference on System Administration (LISA ’04), pp. 79–92, 2004

work page 2004
[4]

AWS Builder Cen- ter, September 2024

Automata Network.Creating Attestable Builds with AWS Nitro Enclaves. AWS Builder Cen- ter, September 2024. https://builder.aws.com/content/2lZdD8iDfAGbQpWK8g8fGvQ1kp8/ creating-attestable-builds-with-aws-nitro-enclaves

work page 2024
[5]

Protocol-aware firmware rehosting for effective fuzzing of embedded network stacks

D. Hugenroth, M. Lins, R. Mayrhofer, and A. R. Beresford. Attestable Builds: Compiling Verifiable Binaries on Untrusted Systems using Trusted Execution Environments. In Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security (CCS ’25), pp. 4514–4528, ACM, 2025. https://doi.org/10.1145/3719027.3765128. Preprint: https://arxiv....

work page doi:10.1145/3719027.3765128 2025
[6]

Document 70366, 2020

AMD.AMD SEV-SNP: Strengthening VM Isolation with Integrity Protec- tion and More. Document 70366, 2020. https://docs.amd.com/v/u/en-US/ SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more

work page 2020
[7]

Document ID 853294, 2025

Intel.Intel Trust Domain Extensions (Intel TDX) Module Base Architecture Specification. Document ID 853294, 2025. https://www.intel.com/content/www/us/en/content-details/ 853294/intel-trust-domain-extensions-intel-tdx-module-base-architecture-specification. html. 25

work page 2025
[8]

Torres-Arias, H

S. Torres-Arias, H. Afzali, T. K. Kuppusamy, R. Curtmola, and J. Cappos. in-toto: Providing farm-to-table guarantees for bytes and bits. InProceedings of the 28th USENIX Security Symposium, pp. 1393–1410, 2019. https://www.usenix.org/conference/usenixsecurity19/ presentation/torres-arias. Specification at https://github.com/in-toto/attestation

work page 2019
[9]

https://stagex

Stagex.A container-native, full-source bootstrapped, reproducible toolchain. https://stagex. tools, source at https://codeberg.org/stagex/stagex

work page
[10]

https://slsa.dev/spec/v1.2/build-provenance, 2025

SLSA Community.Build: Provenance v1.2. https://slsa.dev/spec/v1.2/build-provenance, 2025

work page 2025
[11]

https://github.com/ lunal-dev/kettle

Lunal Dev.Kettle: attested builds for verifiable software provenance. https://github.com/ lunal-dev/kettle. 26

work page

[1] [1]

https://reproducible-builds.org

Reproducible Builds.Reproducible Builds project. https://reproducible-builds.org

work page

[2] [2]

Lamb and S

C. Lamb and S. Zacchiroli. Reproducible Builds: Increasing the Integrity of Software Supply Chains.IEEE Software, 39(2):62–70, 2022. https://doi.org/10.1109/MS.2021.3073045. Preprint: https://arxiv.org/abs/2104.06020

work page doi:10.1109/ms.2021.3073045 2022

[3] [3]

Dolstra, M

E. Dolstra, M. de Jonge, and E. Visser. Nix: A Safe and Policy-Free System for Software Deployment. InProceedings of the 18th USENIX Conference on System Administration (LISA ’04), pp. 79–92, 2004

work page 2004

[4] [4]

AWS Builder Cen- ter, September 2024

Automata Network.Creating Attestable Builds with AWS Nitro Enclaves. AWS Builder Cen- ter, September 2024. https://builder.aws.com/content/2lZdD8iDfAGbQpWK8g8fGvQ1kp8/ creating-attestable-builds-with-aws-nitro-enclaves

work page 2024

[5] [5]

Protocol-aware firmware rehosting for effective fuzzing of embedded network stacks

D. Hugenroth, M. Lins, R. Mayrhofer, and A. R. Beresford. Attestable Builds: Compiling Verifiable Binaries on Untrusted Systems using Trusted Execution Environments. In Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security (CCS ’25), pp. 4514–4528, ACM, 2025. https://doi.org/10.1145/3719027.3765128. Preprint: https://arxiv....

work page doi:10.1145/3719027.3765128 2025

[6] [6]

Document 70366, 2020

AMD.AMD SEV-SNP: Strengthening VM Isolation with Integrity Protec- tion and More. Document 70366, 2020. https://docs.amd.com/v/u/en-US/ SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more

work page 2020

[7] [7]

Document ID 853294, 2025

Intel.Intel Trust Domain Extensions (Intel TDX) Module Base Architecture Specification. Document ID 853294, 2025. https://www.intel.com/content/www/us/en/content-details/ 853294/intel-trust-domain-extensions-intel-tdx-module-base-architecture-specification. html. 25

work page 2025

[8] [8]

Torres-Arias, H

S. Torres-Arias, H. Afzali, T. K. Kuppusamy, R. Curtmola, and J. Cappos. in-toto: Providing farm-to-table guarantees for bytes and bits. InProceedings of the 28th USENIX Security Symposium, pp. 1393–1410, 2019. https://www.usenix.org/conference/usenixsecurity19/ presentation/torres-arias. Specification at https://github.com/in-toto/attestation

work page 2019

[9] [9]

https://stagex

Stagex.A container-native, full-source bootstrapped, reproducible toolchain. https://stagex. tools, source at https://codeberg.org/stagex/stagex

work page

[10] [10]

https://slsa.dev/spec/v1.2/build-provenance, 2025

SLSA Community.Build: Provenance v1.2. https://slsa.dev/spec/v1.2/build-provenance, 2025

work page 2025

[11] [11]

https://github.com/ lunal-dev/kettle

Lunal Dev.Kettle: attested builds for verifiable software provenance. https://github.com/ lunal-dev/kettle. 26

work page