Threat Model

Every security system has a root of trust, a set of components assumed to be correct because they cannot be verified further down. Attested builds shift where the root of trust sits. In a conventional build, a verifier must trust the entire build infrastructure stack (the cloud provider's software, its operators, other tenants, and the build pipeline itself) to accept that a binary corresponds to its claimed source. Attested builds replace that trust surface with a much smaller one rooted in TEE hardware and a small set of cryptographic primitives.

Trust Model

The trust boundary encompasses the TEE hardware and firmware and a small set of cryptographic primitives. Physical operators are legible attackers. Software-level access by an operator is untrusted, and invasive physical access can break the TEE threat model. The source repository is also trusted in the sense that attestation cannot reason about the intent of the code being built. All other parties are untrusted.

  ┌────────────────────────────────────────────────────────────────────────┐
  │                                                                        │
  │       Hypervisor      Host OS      CI runner      Cloud operator       │
  │                                                                        │
  └────────────────────────────────────┬───────────────────────────────────┘
                                       │
                                       │  launches
                                       ▼
  ╔═══════════════════════════ Kettle build CVM ═══════════════════════════╗
  ║                                                                        ║
  ║            ┌──────────┐      ┌──────────┐      ┌──────────┐            ║
  ║            │  Source  │      │   Deps   │      │Toolchain │            ║
  ║            └─────┬────┘      └─────┬────┘      └─────┬────┘            ║
  ║                  │                 │                 │                 ║
  ║                  └─────────────────┼─────────────────┘                 ║
  ║                                    │                                   ║
  ║                                    ▼                                   ║
  ║                           ┌────────────────┐                           ║
  ║                           │Build execution │                           ║
  ║                           └────────┬───────┘                           ║
  ║                                    │  produces                         ║
  ║                                    ▼                                   ║
  ║                    ┌───────────────┴──────────────┐                    ║
  ║                    │                              │                    ║
  ║                    │       SLSA provenance        │                    ║
  ║                    │     + attestation report     │                    ║
  ║                    │                              │                    ║
  ║                    └──────────────────────────────┘                    ║
  ║                                                                        ║
  ╚════════════════════════════════════════════════════════════════════════╝

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.

Two of these entries are subtle and worth elaborating.

Physical operators. Whoever physically hosts the hardware can attack the TEE using active probing of the memory bus, hardware interposers placed between the CPU and memory, fault injection, or chip decapsulation. Those attacks can break the guarantees of the TEE. They require physical possession of the running machine and specialized equipment, and are outside Kettle's threat model. Software-level access by the same operator (administrators, datacenter technicians, monitoring agents, employees acting through cloud APIs) is untrusted and is in scope. The asymmetry is deliberate. The TEE threat model is scoped against software adversaries with arbitrary host privileges, not against an attacker with invasive physical access.

Source and package registries. The source commit and any registry-fetched dependencies are trusted only for identity. The attestation proves that a specific commit and specific packages were used. This prevents package alteration or replacement, and provides a verifiable audit trail, but does not prove that any of them are free of backdoors.

Attacks Addressed

Protection comes from two sources. The first is TEE isolation during the build itself. The second is cryptographic binding between inputs, the build process, and outputs.

• Tampering during the build. An attacker who compromises the build platform and injects malicious behavior during compilation is normally undetectable. The source is clean but the binary is backdoored. Running the build inside a TEE places the environment outside the host's reach, and the attestation report binds the build to the exact code that was loaded. Any modification to the build process changes the launch measurement and causes verification to fail.
• Tampering after the build. An attacker with access to artifact storage could substitute a malicious binary for the legitimate one. The provenance produced by an attested build records the digest of every output artifact, and a SHA-256 digest of the provenance document is in turn committed to the TEE attestation report-data field. A substituted artifact fails the digest check against the provenance, and a forged provenance document fails the digest check against the report-data field of the hardware-signed attestation.
• Forged provenance. Without a hardware root of trust, provenance is a claim. Anyone with a signing key can produce a JSON document asserting that a binary came from a particular source. Attested provenance is bound to a hardware-signed attestation report by committing a SHA-256 digest of the document into the report-data field, with the report itself signed by the TEE platform's attestation key (the AMD VCEK on SEV-SNP, the equivalent on Intel TDX). The certificate chain terminates at the CPU vendor's root of trust, so forging provenance requires producing a valid hardware-signed attestation report whose report-data matches the forged document, which in turn requires compromising the TEE hardware itself.
• Dependency substitution. A pinned dependency silently swapped at build time fails the checksum recorded in the lockfile and is rejected before the build starts. The provenance records the resolved version and digest of every dependency, so post-hoc substitution is also detectable by any verifier.

Attacks Not Addressed

The following are architectural constraints rather than implementation gaps. Stating them explicitly clarifies the actual security posture provided by attested builds.

• Malicious source code. Attested builds verify that a specific source was used, not that the source is safe. If the upstream repository contains a backdoor, the attested build faithfully reproduces the backdoor and the provenance accurately records the commit that introduced it. Attestation proves identity, not intent.
• Compromised upstream dependencies. Dependencies fetched from registries are trusted for identity, not for the trustworthiness of their contents. If a registry publishes a malicious package, an attested build that consumes that package produces a verifiable record that the malicious version was used. It does not detect that the package is malicious.
• TEE hardware or firmware compromise. The trust anchor is the CPU vendor's hardware and key management. If those are compromised, the guarantees break. Firmware vulnerabilities have been found in TEE implementations before and will be found again. The trust surface is substantially smaller than that of a conventional build pipeline, but not zero.
• Invasive physical attacks. A physical operator with possession of the machine can attack the CPU package, memory bus, or memory subsystem directly. These attacks can break TEE confidentiality or integrity and are outside the software-adversary model Kettle relies on.
• Side-channel attacks. TEEs share microarchitectural state with the host. Cache timing, branch prediction, and other side channels can leak information. Vendor mitigations have raised the bar significantly, but side channels remain an active research area. Attested builds reduce, but do not eliminate, information leakage during compilation.
• Availability. The host controls whether the build runs at all. It can refuse to schedule the TEE, terminate it mid-build, or disrupt network connectivity. Attested builds protect confidentiality and integrity, not availability.
• Bugs in the built software. The TEE protects the execution environment, not the code running in it. If the built application contains a vulnerability, an attacker can exploit it. Attestation proves which code was loaded, not that the code is correct.