Google and GitHub have been collaborating on a forgery-proof method for signing source code as part of their efforts to secure the software supply chain.
Software supply chain security depends on developers and organizations being able to detect that artifacts — the software components, frameworks, and build tools being used — are authentic and have not been tampered with. That is the thinking behind Supply chain Levels for Software Artifacts (SLSA), a framework for maintaining end-to-end integrity of a software supply chain.
SLSA’s goal is to generate information that described where, when, and how the artifacts were produced, and give developers and organizations a way to identify where the artifacts diverged from the original. The project, originally built by Google last June in response to National Institute of Standards and Technology’s (NIST) framework for software development, is managed by the Open Source Security Foundation.
Knowing a project’s SLSA level can provide developers and organizations with some insights into the project’s security posture.
Looking at the Build Tools
Google and GitHub’s recent collaboration focuses on build provenance, or verifying the authenticity of the entity behind the release processes and whether the build artifacts are protected against tampering. As the attack against SolarWinds and Codecov showed, threat actors can hijack build tools to disseminate malicious components.
“[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,” writes Google Open Source Security Team’s Asra Ali and Laurent Simon.
Google and GitHub announced a prototype tool, written in the Go programming language, that uses GitHub Actions workflows and Sigstore‘s signing tools to create “tamperless evidence of the build and allow consumer verification.”
Using those workflows and tools allows “users to not only verify that the software they receive is authentic, but also to verify where it was built and with which software,” writes Jose Palafox, GitHub’s director of business development.
The new workflow, which is available in the Actions tab in any GitHub repository, creates runners, or fresh virtual machine instances, for each job. Different VMs compile the project and generate and sign the SLSA provenance. Projects using GitHub-hosted runners have the guarantee that the code has not been modified.
“To protect against the possibility of one job (e.g. the build step) tampering with the other artifacts used by another job (the provenance step), this approach uses a trusted channel to protect the integrity of the data,” Ali and Simon write.
A unique token contains verifiable information about the workflow such as the caller repository, commit hash, trigger, and current workflow path and reference. Users can rely on the signing certificates to verify provenance, and developer don’t need to manage or distribute cryptographic keys for signing.
GitOps in Security
With cloud-native development, developers are working as quickly and efficiently as possible with their CI/CD pipelines using Git repos, says Melinda Marks, a senior analyst with ESG. If security is to match the speed of modern software development, security tools need to be integrated into the developer workflow in order to reduce the risk of deploying faulty code. Google and GitHub’s collaboration “illustrate how GitOps is good for security,” Marks says.
The use of GitHub Actions workflows to automatically generate build provenance and using Sigstore information to track the code is giving developers ways to create reusable trusted workflows, mechanisms to prevent tampering, and records when code is altered, Marks says.
“These GitHub features and frameworks keep track of the code, where it’s from, who had access, what changes were made, etc., so if there are problems, they can use security tools, testing tools, configuration/posture management tools, etc., and use the metadata from the repos to fix issues efficiently because they have the data on the code origin, any modifications, access, etc,” she says.
A Graduated Approach
Recent high-profile breaches highlight how the software supply chain is vulnerable and what kind of damage attacks can cause. Gartner predicts that “by 2025, 45% of organizations will have experienced attacks on their software supply chains, a threefold increase from 2021.”
The SLSA framework recognizes that adopting supply chain security for software builds is not a quick process and that an incremental approach is necessary. The framework considers how provenance — metadata about how an artifact was built, including the build process, top-level source, and dependencies — is generated and verified. There are four levels:
- Level One: The build process must be fully scripted and/or automated and generate provenance. This level doesn’t prevent tampering but offers information that can be used in vulnerability management.
- Level Two: The organization must be using version control and a hosted build service that generates authenticated provenance. This level prevents tampering to the extent that the build service is trusted.
- Level Three: The source and build platforms meet specific standards to guarantee the auditability of the source and the integrity of the provenance.
- Level Four: The organization requires a two-person review of all changes and a hermetic, reproducible build process. Hermetic builds guarantee the provenance’s list of dependencies is complete.
The new build provenance prototype tool would bring organizations to Level Three under SLSA, Ali and Simon say. Projects using GitHub runners will be perceived as having authentic artifacts. Level Three requires some way to repeatedly verify the provenance, which this prototype provides.
“Using this approach, projects building on GitHub runners can achieve SLSA 3 (the third of four progressive SLSA levels), which affirms to consumers that your artifacts are authentic and trustworthy,” Ali and Simon write.
Source: www.darkreading.com