Every of those assaults might have been prevented if there have been a strategy to detect that the delivered artifacts diverged from the anticipated origin of the software program. However till now, producing verifiable data that described the place, when, and the way software program artifacts had been produced (data often called provenance) was tough. This data permits customers to hint artifacts verifiably again to the supply and develop risk-based insurance policies round what they eat. Presently, provenance era shouldn’t be broadly supported, and options that do exist might require migrating construct processes to providers like Tekton Chains.
This weblog put up describes a brand new technique of producing non-forgeable provenance utilizing GitHub Actions workflows for isolation and Sigstore’s signing instruments for authenticity. Utilizing this method, tasks constructing on GitHub runners can obtain SLSA 3 (the third of 4 progressive SLSA “ranges”), which affirms to shoppers that your artifacts are genuine and reliable.
This weblog put up focuses on construct provenance, which supplies customers vital details about the construct: who carried out the discharge course of? Was the construct artifact protected in opposition to malicious tampering? Supply provenance describes how the supply code was protected, which we’ll cowl in future weblog posts, so keep tuned.
To create tamperless proof of the construct and permit shopper verification, that you must:
- Isolate the provenance era from the construct course of;
- Isolate in opposition to maintainers interfering within the workflow;
- Present a mechanism to determine the builder throughout provenance verification.
The total isolation described within the first two factors permits shoppers to belief that the provenance was faithfully recorded; entities that present this assure are referred to as trusted builders.
Our Go prototype solves all three challenges. It additionally contains operating the construct contained in the trusted builder, which supplies a robust assure that the construct achieves SLSA 3’s ephemeral and remoted requirement.
The next steps create the trusted builder that’s essential to generate provenance in isolation from the construct and maintainer’s interference.
Leveraging GitHub’s reusable workflows supplies the isolation mechanism from each maintainers’ caller workflows and from the construct course of. Throughout the workflow, Github Actions creates recent cases of digital machines (VMs), referred to as runners, for every job. These separate VMs give the mandatory isolation for a trusted builder, in order that totally different VMs compile the mission and generate and signal the SLSA provenance (see diagram under).
Working the workflow on GitHub-hosted runners provides the assure that the code run is actually the supposed workflow, which self-hosted runners don’t. This prototype depends on GitHub to run the precise code outlined within the workflow.
The reusable workflow additionally protects in opposition to doable interference from maintainers, who might in any other case attempt to outline the workflow in a approach that interferes with the builder. The one strategy to work together with a reusable workflow is thru the enter parameters it exposes to the calling workflow, which stops maintainers from altering data through surroundings variables, steps, providers and defaults.
To guard in opposition to the potential of one job (e.g. the construct step) tampering with the opposite artifacts utilized by one other job (the provenance step), this method makes use of a trusted channel to guard the integrity of the info. We use job outputs to ship hashes (resulting from dimension limitations) after which use the hashes to confirm the binary acquired through the untrusted artifact registry.
OpenID Join (OIDC) is an ordinary used throughout the online for identification suppliers (e.g., Google) to attest to the identification of a consumer for a 3rd social gathering. GitHub now helps OIDC of their workflows. Every time a workflow is run, a runner can mint a singular JWT token from GitHub’s OIDC supplier. The token accommodates verifiable data of the workflow identification, together with the caller repository, commit hash, set off, and the present (reuseable) workflow path and reference.
Utilizing OIDC, the workflow proves its identification to Sigstore’s Fulcio root Certificates Authority, which acts as an exterior verification service. Fulcio indicators a short-lived certificates testifying to an ephemeral signing key generated within the runner and tying it to the workload identification. A file of signing the provenance is saved in Sigstore’s transparency log Rekor. Customers can use the signing certificates as a belief anchor to confirm that the provenance was authenticated and non-forgeable; it should have been created contained in the trusted builder.
- Search for the corresponding Rekor log entry and confirm the signature;
- Confirm the trusted builder identification by extracting it from the signing certificates;
- Examine that the provenance data matches the anticipated supply and construct.
See an instance in motion within the official repository.
Performing these steps ensures to the buyer that the binary was produced within the trusted builder at a given commit hash attested to within the provenance. They’ll belief that the data within the provenance was non-forgeable, permitting them to belief the construct “recipe” and hint their artifact verifiably again to the supply.
Using the SLSA framework is a confirmed approach for making certain software program supply-chain integrity at scale. This prototype reveals that reaching excessive SLSA ranges is less complicated than ever because of the latest options of widespread CI/CD programs and open-source tooling. Elevated adoption of tamper-safe (SLSA 3+) construct providers will contribute to a stronger open-source ecosystem and assist shut one simply exploited hole within the present provide chain.
We encourage testing and adoption and welcome any enhancements to the mission. Please share suggestions, feedback and solutions at slsa-github-generator-go and slsa-verifier mission repositories. We are going to formally launch v1 in just a few weeks!
In follow-up posts, we’ll exhibit including non-forgeable supply provenance testifying to safe repository settings, and showcase the identical strategies for different construct toolchains and bundle managers, and many others. Keep tuned!
