Kettle builds and verifies attested builds, packages that include cryptographically signed SLSA provenance certifying the source, tools, and machine used to create the build.
Get just the good parts of reproducible builds: the security and assurance of signed and provable inputs, without the misery of constantly repairing your build system.
Attested builds allow anyone to verify the exact inputs that produced any binary output, by adding cryptographic signatures showing exactly what source code, dependencies, and toolchains were used.
Kettle uses TEEs (Trusted Execution Environments) to sign builds using hardware attestation. Hardware attestations are verified against certificates published by the hardware manufacturer, cryptographically linking binaries to their exact source code.
Kettle's attested builds provide a solution to almost every scenario where binaries need a verification trail directly back to the source code and tools that created them. This is just a few examples of problems Kettle can solve:
- A customer deploying your service wants to know it’s running the code you claim, built from the source they audited.
- A compliance team wants evidence that a binary was built with specific dependency versions, not newer ones with unknown changes.
- A security auditor wants to verify that the toolchain used to compile a release matches the one specified in your security documentation.
- A regulated enterprise wants proof that sensitive data will be processed only by code that passed their review, not by a modified version.
- A package consumer wants to ensure that the binary they downloaded corresponds to the source code and dependencies they reviewed, not a tampered version.
For a full tour of Kettle's design, architecture, and security guarantees, read our guide to attested builds.
- What are Attested Builds?
- How Attested Builds Work
- Provenance and Standards
- Threat Model and Security Boundaries
Most build systems can't provide hardware-secured build machines. Kettle ensures your build was created and signed inside a confidential virtual machine, with memory and compute secured even against a malicious hypervisor. In contrast, if you use GitHub's artifact attestations, you are forced to simply take GitHub's word that their cloud VMs didn't tamper with your build.
Using Kettle to build and attest inside a TEE gives you hardware-based cryptographic assertion, dramatically reducing the number of parties you are forced to trust. You only need to trust the hardware manufacturer and the physical custodians of your build machines. No need to trust the sysadmins with root on the bare metal, or the authors of the hypervisor that creates and manages your build VMs, or the developers maintaining the image your code will run on. The code that runs in your TEE is signed by the hardware, so you can be sure what ran, and encrypted so even the hypervisor can't read the memory of your job as it runs.
Kettle is available from GitHub Releases or from source via Cargo, the Rust build tool.
curl -LO https://github.com/lunal-dev/kettle/releases/latest/download/kettleTo install Kettle, first install Rust, and then use Cargo to build and install:
cargo install --git https://github.com/lunal-dev/kettleIf you are running inside a TEE, you will need to install OS packages for attestation, and then enable the attest feature flag. Here's an example for Ubuntu Linux:
apt-get install -y libtss2-dev
cargo install --features attest --git https://github.com/lunal-dev/kettleRun kettle build to do all the steps except the hardware cryptography: generate a SLSA-compliant provenance.json file, build the project, and checksum the binaries. Use this command to test your build process even if you aren't inside a TEE.
Today, Kettle supports building and attesting Rust and Nix projects. It's easy to add additional toolchains, and we plan to add first-party support for Python and Go soon.
This example will check out the ripgrep search tool, build a binary, and generate a provenance file:
git clone https://github.com/burntsushi/ripgrep
kettle build ripgrepAfter Kettle finishes running, look for the provenance and binaries are available inside the kettle-build directory.
Run kettle attest to run a build, record the VM firmware and OS image, then apply a hardware signature to everything to create an evidence.json file.
While running inside a TEE, this will check out, build, and attest the ripgrep search tool:
git clone https://github.com/burntsushi/ripgrep
kettle attest ripgrepAfter Kettle finishes running, the provenance, attestation, and binaries are available inside the kettle-build directory.
Run kettle verify to cryptographically verify your binaries. Kettle will read the evidence.json, verify the signature using hardware vendor public keys, and then validate the signed provenance.json and use it to confirm the checksum of your binary.
Verify the attested build created above like this:
kettle verify ripgrep/kettle-buildUse cargo nextest run to run the tests for any platform.
In a TEE, use cargo nextest run --ignored all to run the full integration tests that checkout Rust and Nix projects, build them, attest them, and verify them.