Google has teamed up with GitHub for a solution that should help prevent software supply chain attacks such as the ones that affected SolarWinds and Codecov.
Google’s open source security team explained that in the SolarWinds attack hackers gained control of a build server and injected malicious artifacts into a build platform. In the Codecov attack, threat actors bypassed trusted builders to upload their artifacts.
“Each of these attacks could have been prevented if there were a way to detect that the delivered artifacts diverged from the expected origin of the software,” Google explained. “But until now, generating verifiable information that described where, when, and how software artifacts were produced (information known as provenance) was difficult. This information allows users to trace artifacts verifiably back to the source and develop risk-based policies around what they consume.”
Google and GitHub now propose a new method for generating what they describe as “non-forgeable provenance.” The method leverages GitHub Actions workflows for isolation and Sigstore signing tools for authenticity.
The goal is to help projects building on GitHub runners achieve a high SLSA level, which reassures consumers that their artifacts are trustworthy and authentic.
SLSA (Supply-chain Levels for Software Artifacts) is a framework designed for improving the integrity of a project by enabling users to trace software from the final version back to its source code. In this case, the goal is to achieve SLSA level 3 out of a total of four levels.
Google on Thursday published a blog post describing “build provenance,” which focuses on the entity performing the release process and whether the build artifact was protected against malicious modifications. The internet giant will soon share a different blog post focusing on “source provenance,” which covers how the source code was protected. GitHub published its own blog post on Thursday.
For build provenance, the companies have created two prototype tools: one for generating non-forgeable build provenance and one for verifying the artifact and its signed provenance. Currently, only applications created using the Go programming language are supported, but the project will be expanded to others as well.
A step-by-step description of the process has also been provided.
“Utilizing the SLSA framework is a proven way for ensuring software supply-chain integrity at scale,” Google said. “This prototype shows that achieving high SLSA levels is easier than ever thanks to the newest features of popular CI/CD systems and open-source tooling. Increased adoption of tamper-safe (SLSA 3+) build services will contribute to a stronger open-source ecosystem and help close one easily exploited gap in the current supply chain.”
The first version of the project is expected in a few weeks. In the meantime, interested parties are encouraged to conduct tests and share feedback.
Related: ‘Secrets Sprawl’ Haunts Software Supply Chain Security
Related: Legit Security Raises $30M to Tackle Supply Chain Security
Related: OpenSSF Alpha-Omega Project Tackles Supply Chain Security
