By William Woodruff
This is a joint post with Alpha-Omega—read their announcement post as well!
We’re starting a new project in collaboration with Alpha-Omega and OpenSSF to improve the transparency and security of Homebrew. This six-month project will bring cryptographically verifiable build provenance to homebrew-core, allowing end users and companies to prove that Homebrew’s packages come from the official Homebrew CI/CD. In a nutshell, Homebrew’s packages will become compliant with SLSA Build L2 (formerly known as Level 2).
As the dominant macOS package manager and popular userspace alternative on Linux, Homebrew facilitates hundreds of millions of package installs per year, including development tools and toolchains that millions of programmers rely on for trustworthy builds of their software. This critical status makes Homebrew a high-profile target for supply chain attacks, which this project will help stymie.
Vulnerable links in the supply chain
The software supply chain is built from individual links, and the attacker’s goal is to break the entire chain by finding and subverting the weakest link. Conversely, the defender aims to strengthen every link because the attacker needs to break only one to win.
Previous efforts to strengthen the entire chain have focused on various links:
- The security of the software itself: static and dynamic analyses, as well as the rise of programming languages intended to eliminate entire vulnerability classes
- Transport security: the use of HTTPS and other authenticated, integrity-preserving channels for retrieving and publishing software artifacts
- Packaging index and manager security: the adoption of 2FA by package indices, as well as technologies like PyPI’s Trusted Publishing for reducing the “blast radius” of package publishing workflows
With this post, we’d like to spotlight another link that urgently needs strengthening: opaque and complex build processes.
Taming beastly builds with verifiable provenance
Software grows in complexity over time, and builds are no exception; modern build processes contain all the indications of a weak link in the software supply chain:
- Opaque, unauditable build hosts: Much of today’s software is built on hosted CI/CD services, forming an implicit trust relationship. These services inject their dependencies into the build environment and change constantly—often for important reasons, such as patching vulnerable software.
- Large, dense dependency graphs: We rely more than ever on small third-party dependencies, often maintained (or not) by hobbyists with limited interest or experience in secure development. The pace of development we’ve come to expect necessitates this dense web of small dependencies. Still, their rise (along with the rise of automatic dependency updating) means that all our projects contain dozens of left-pad incidents waiting to happen.
- Complex, unreproducible build systems and processes: Undeclared and implicit dependencies, environments that cannot be reproduced locally, incorrect assumptions, and race conditions are just a few of the ways in which builds can misbehave or fail to reproduce, leaving engineers in the lurch. These reliability and usability problems are also security problems in our world of CI/CD and real-time security releases.
Taming these complexities requires visibility into them. We must be able to enumerate and formally describe the components of our build systems to analyze them automatically. This goes by many names and covers many techniques (SBOMs, build transparency, reproducibility, etc.), but the basic idea is one of provenance.
At the same time, collecting provenance adds a new link to our chain. Without integrity and authenticity protections, provenance is just another piece of information that an attacker could potentially manipulate.
This brings us to our ultimate goal: provenance that we can cryptographically verify, giving us confidence in our claims about a build’s origin and integrity.
Fortunately, all the building blocks for verifiable provenance already exist: Sigstore gives us strong digital signatures bound to machine (or human) identities, DSSE and in-toto offer standard formats and signing procedures for crafting signed attestations, and SLSA provides a formal taxonomy for evaluating the strength and trustworthiness of our statements.
Verifiable provenance for Homebrew
What does this mean for Homebrew? Once complete, every single bottle provided by homebrew-core will be digitally signed in a way that attests it was built on Homebrew’s trusted CI/CD. Those digital signatures will be provided through Sigstore; the attestations behind them will be performed with the in-toto attestation framework.
Even if an attacker manages to compromise Homebrew’s bottle hosting or otherwise tamper with the contents of the bottles referenced in the homebrew-core formulas, they cannot contrive an authentic digital signature for their changes.
This protection complements Homebrew’s existing integrity and source-side authenticity guarantees. Once provenance on homebrew-core is fully deployed, a user who runs brew install python will be able to prove each of the following:
- The formula metadata used to install Python is authenticated, thanks to Homebrew’s signed JSON API.
- The bottle has not been tampered with in transit, thanks to digests in the formula metadata.
- The bottle was built in a public, auditable, controlled CI/CD environment against a specific source revision.
That last property is brand new and is equivalent to Build L2 in the SLSA taxonomy of security levels.
Follow along!
This work is open source and will be conducted openly, so you can follow our activity. We are actively involved in the Sigstore and OpenSSF Slacks, so please drop in and say hi!
Alpha-Omega, an associated project of OpenSSF, is funding this work. The Alpha-Omega mission is to protect society by catalyzing sustainable security improvements to the most critical open-source software projects and ecosystems. OpenSSF holds regularly scheduled meetings for its working groups and projects, and we’ll be in attendance.