Three big IT companies have proposed a way to create tamper-proof application builds that lower the odds of a supply chain attack like SolarWinds.
Many of the recent high-profile software attacks that have alarmed open-source users globally were consequences of supply chain integrity vulnerabilities, Google said in a blog on Thursday. For example, in the compromise of the SolarWinds Orion security update process, attackers gained control of a build server to use malicious source files and jnject malicious artifacts into a compromised build platform. In the case of the compromise of Codecov’s Bash Uploader, attackers were able to bypass trusted builders to upload malicious 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 said. “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. Currently, provenance generation is not widely supported.”
So Google and partners have built a prototype framework for generating non-forgeable provenance for apps. Initially it only works for apps created in the Go language. It would use GitHub Actions workflows for isolation and digital signing tools from Sigstore for authenticity. Using this approach, Google argued, projects building on GitHub runners can achieve SLSA 3 (the third of four progressive SLSA “levels”), which affirms to IT departments and developers that the artifacts are authentic and trustworthy. SLSA is an industry-standard security framework that allows developers to trace the final piece of software they release all the way back to the source.
Build provenance gives users information about the build, such as who performed the release process, and was the build artifact protected against malicious tampering. It differs from source provenance, which describes how the source code was protected.
Leveraging GitHub’s reusable workflows provides the isolation mechanism from both maintainers’ caller workflows and from the build process, Google explained. Within the workflow, Github Actions creates fresh instances of virtual machines (VMs), called runners, for each job. These separate VMs give the necessary isolation for a trusted builder, so that different VMs compile the project and generate and sign the SLSA provenance.
Running the workflow on GitHub-hosted runners gives the guarantee that the code run is in fact the intended workflow, which self-hosted runners do not. This prototype relies on GitHub to run the exact code defined in the workflow.
GitHub now supports OpenID Connect (OIDC), a standard for identity providers (like Google) to attest to the identity of a user for a third party. Each time a workflow is run, a runner can mint a unique JWT token from GitHub’s OIDC provider. The token contains verifiable information of the workflow identity, including the caller repository, commit hash, trigger, and the current (reuseable) workflow path and reference. Using OIDC, the workflow proves its identity to Sigstore’s Fulcio root Certificate Authority, which acts as an external verification service.
Fulcio signs a short-lived certificate attesting to an ephemeral signing key generated in the runner and tying it to the workload identity. A record of signing the provenance is kept in Sigstore’s transparency log, Rekor. Users can use the signing certificate as a trust anchor to verify that the provenance was authenticated and non-forgeable; it must have been created inside the trusted builder.
