Kettle: 検証可能なソフトウェア由来証明のための認証付きビルド Kettle: Attested builds for verifiable software provenance

Kettle is a research proposal that treats the build process itself as a first-class trust boundary, aiming to make the journey from source code to shipped binary cryptographically verifiable. In the wake of SolarWinds and a steady stream of compromised build pipelines, this question has moved from academic curiosity to a top-tier concern for governments and enterprises alike.

Traditional code signing only attests that a particular publisher released a particular artifact. It says nothing about what happened inside the build server. If an attacker injects malicious code during compilation, the resulting binary is still signed with a legitimate key and passes downstream verification. Kettle attacks this blind spot by running builds inside an attested environment, likely leveraging trusted execution technology and remote attestation, and emitting a certificate that binds together the hashes of input sources, build configuration, toolchain, and output artifacts. A downstream consumer can then independently verify that a given binary was produced from a specific source revision by a specific, inspectable procedure.

The work sits within a rapidly maturing ecosystem of supply-chain integrity efforts. SLSA, championed by Google and the OpenSSF, defines progressive levels of build provenance assurance. in-toto formalizes the chain of custody across pipeline steps. Sigstore provides keyless signing and a transparency log for artifacts. The Reproducible Builds project, meanwhile, has spent over a decade hardening Debian, Arch, and others against the assumption that bit-identical outputs from identical inputs are unattainable. Most of these frameworks rely on signed metadata and auditable logs but ultimately trust that the build host itself has not been subverted. Kettle appears to tighten that root of trust by anchoring it in hardware attestation rather than operational hygiene alone.

That anchoring is not without trade-offs. TEEs such as Intel SGX, AMD SEV-SNP, and ARM CDN have all faced side-channel and architectural vulnerabilities, and they introduce a dependency on specific silicon vendors and their attestation services. Key management, revocation, and long-term verifiability of certificates issued by retired hardware generations remain open operational questions. There is also a tension between attestation and build determinism: if a build embeds timestamps, resolves dependencies dynamically, or parallelizes nondeterministically, two honest builds of the same source can produce different binaries, weakening the practical value of any single attestation. For this reason, Kettle's approach is likely most powerful when combined with reproducible-build discipline, so that multiple independent attested builders can corroborate one another.

The practical impact will depend heavily on integration with existing CI/CD ecosystems. GitHub Actions has begun shipping artifact attestations based on Sigstore and SLSA; GitLab, Buildkite, and cloud-native systems like Tekton Chains are moving in similar directions. Build systems with strong hermeticity guarantees, such as Bazel and Nix, are natural partners for this kind of work because they already constrain inputs in ways that make attestations meaningful. Whether Kettle's specific design becomes a standard or simply informs the next iteration of SLSA-style frameworks remains to be seen, but the underlying direction, pushing verifiability deeper into the toolchain, looks set to define supply-chain security work for the rest of the decade.