Google revealed that it has been working with GitHub to create a forgery-proof method for signing source code as part of an ongoing effort to better secure software supply chains.
Bob Callaway, technology lead for open source software supply chain security at Google, said a prototype of this method, written in the Go programming language, generates non-forgeable provenance using GitHub Actions workflows for isolation and code signing tools for authenticity provided by Sigstore. Projects that make use of GitHub runners to run jobs can now achieve the third level of security as defined by the supply chain levels for software artifacts (SLSA) framework to assure software artifacts are authentic and trustworthy, he said.
The reusable workflow also protects against interference from maintainers who could otherwise try to define the workflow in a way that interferes with the builder. The only way to interact with a reusable workflow is through the input parameters it exposes to the calling workflow, which prevents maintainers from altering information via variables, steps, services and defaults.
“The goal is not only to ensure the provenance of individual software artifacts but also to make it possible to identify which build system was employed to create that artifact,” said Callaway. In addition to working with GitHub, Callaway added that Google expects to apply this method to securing other build systems that organizations use to construct applications.
Overall, Callaway said, “Google is also working toward embedding security functions with DevOps platforms to ensure the integrity of software supply chains and educate developers on how to build more secure software.”
To protect against the possibility of one job tampering with artifacts used by another job, Google’s method creates a trusted channel. Job outputs send hashes that are then used to verify the binary received via the untrusted artifact registry. The OpenID Connect (OIDC) protocol, which GitHub just opted to support, is then used to prove the identity of the workflow to an external service, such as Sigstore, by attaching a unique JSON web token (JWT) to each runner. The token contains verifiable information about workflow identity, such as the caller repository, commit hash, trigger and the current workflow path and reference.
That makes it possible for the workflow to prove its identity to the Fulcio root certificate authority provided by Sigstore. Fulcio signs a short-lived certificate attesting to an ephemeral signing key generated in the runner. A record of that signing is kept in Sigstore’s transparency log Rekor. Users can then rely on the signing certificates to verify provenance in a way that is authenticated and non-forgeable. That approach means maintainers don’t need to manage or distribute cryptographic keys for signing, which until now have made it challenging to manage code signing at scale, Callaway noted.
In the wake of a series of high-profile security breaches involving open source software, Google and others have significantly increased the resources being applied to secure both open source and proprietary software within a set of DevSecOps best practices. It may be a while before developers pervasively employ the benefits of that effort, but it’s clear that substantial progress is being made involving everything from the tools developers use to the build systems managed by DevOps teams.
