Performing a software supply chain security audit of Git, the ubiquitous version control system, is a little like a financial audit of the U.S. Treasury Department. This is because the modern software supply chain all starts with git, whether a software developer is interacting with code on their own machine or pulling code from a Git-based code management system. Therefore when the Open Source Technology Improvement Fund (OSTIF) invited Chainguard and GitLab to participate in a software supply chain security audit of Git, a chance to assess the very foundations of the modern software supply chain, we agreed promptly.
This software supply chain security audit, part of a larger OSTIF-organized security audit of Git, attempted to use the Supply-Chain Levels for Software Artifacts (SLSA, pronounced salsa) framework to assess the software supply chain security practices of Git and the closely related git-for-windows project. Housed under the umbrella of the Open Source Security Foundation, SLSA defines levels of software supply chain integrity and a set of practices to achieve these levels. Version 0.1 of SLSA (at the time of writing, there is active progress towards a 1.0 specification) emphasizes a set of software supply chain security practices that deal with source code, the build process, and provenance with an emphasis on machine-readability and machine-verifiability. A richer description of SLSA can be found here.
The main findings include:
SLSA is not a suitable framework for assessing Git’s software supply chain security practices. This is because Git releases source code directly and not a built artifact. SLSA emphasizes protecting the integrity of built artifacts (“binaries”), rendering it an awkward fit for Git. The downstream consumers of Git do, however, release built artifacts and so are appropriate objects of a SLSA assessment.
Nonetheless, a more informal assessment of Git’s practices suggests that the project’s vibrant community offers protection against software supply chain attacks. The software supply chain security practices of Git aren’t machine-readable or machine-verifiable, but the dedicated community of contributors and current tooling offers protection consistent with the spirit of SLSA.
One downstream consumer of Git, git-for-windows, can be assessed via the SLSA framework. The assessment finds that the current practices of git-for-windows achieve SLSA level 3 (using the SLSA v0.1 framework) and level 3 compliance could be extended to the whole project by generating a provenance document. Table 1 summarizes the SLSA findings for git-for-windows. Future Git-related software supply chain security assessments could focus on assessing and aiding the set of projects that are immediate downstream consumers to Git.
The full report can be found here.
Free and open source software projects interested in a similar audit can contact OSTIF for further information. Companies interested in a software supply chain security audit can contact Chainguard. And anyone interested in education materials on SLSA can find them on Chainguard Academy.
