Modern supply chain security needs scalable verifiability

Modern software supply chains are complex. Dependency trees of modern software often contain thousands of packages across multiple ecosystems. This makes it challenging for any developer team to fully understand exactly what code is going into their build.

One significant challenge is the reliance on pre-built dependencies. Whereas source code is something we as humans can read and audit, compiled binaries are opaque and difficult to understand. Whenever we download a pre-built package, we are not just trusting the developer who offers it, but also their build infrastructure—and everything multiple levels upstream in the supply chain.

“

We believe that modern software supply chain security is complex and cannot rely on trust alone.

”

Trust can scale to a handful of people. Beyond that, it is more akin to hope. So, instead of blindly trusting an unknown set of build pipelines, we ideally make them transparent and verifiable. To deal with scale, this process should be low-overhead and automatic.

Reproducible builds are the current standard answer, but come with drawbacks.

This problem is not new—although AI-fueled acceleration in software development makes it more pressing. Some open-source projects have adopted Reproducible Builds (R-Bs) as a technique for verifiable builds. R-Bs make the build process perfectly deterministic, so that the same source code input results in bit-for-bit identical outputs.

However, introducing R-Bs in large software projects is challenging since sources of non-determinism are plenty: timestamps of files, implicit file traversal, and compiler optimizations are all potential sources of randomness. As a data point: making Debian reproducible took 10 years. Importantly, R-Bs also require a continued commitment across all future toolchain upgrades and dependency updates.

Another challenge is that the verification of R-B artifacts does not scale well. At the very least, it requires independent parties to execute the full build as well, which the user then relies on in an "any-trust" model.

Attestable Builds provide verifiability with minimal changes and at scale.

Attestable Builds is an alternative approach to R-Bs for achieving verifiable builds. They use hardware-based trust anchors to instantiate encrypted, hermetic build environments. The Confidential Computing features of modern CPUs (such as AMD SEV-SNP and Intel TDX) provide the required integrity guarantees and cryptographic proof in the form of attestation reports.

“

Attestable Builds are the easiest and most scalable way to make the build process verifiable.

”

This means that the build process does not require any changes—it simply executes in a secure environment that can attest to all inputs and outputs. This provides clear provenance and protection against build server compromise, lifting a significant burden from developers and DevOps engineers.

Furthermore, verification becomes instant. With the artifact hash, we can look up the certificate for the build process, verify its inclusion in a transparency log, and confirm an artifact's provenance. This entire verification can happen in just a few milliseconds.