Every of those assaults may have been prevented if there have been a option to detect that the delivered artifacts diverged from the anticipated origin of the software program. However till now, producing verifiable info that described the place, when, and the way software program artifacts have been produced (info generally known as provenance) was troublesome. This info permits customers to hint artifacts verifiably again to the supply and develop risk-based insurance policies round what they eat. At present, provenance era is just not broadly supported, and options that do exist could require migrating construct processes to providers like Tekton Chains.
This weblog submit 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 customers that your artifacts are genuine and reliable.
This weblog submit focuses on construct provenance, which provides customers essential details about the construct: who carried out the discharge course of? Was the construct artifact protected towards 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, you have to:
- Isolate the provenance era from the construct course of;
- Isolate towards 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 customers 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 consists of operating the construct contained in the trusted builder, which gives 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 gives the isolation mechanism from each maintainers’ caller workflows and from the construct course of. Inside the workflow, Github Actions creates contemporary cases of digital machines (VMs), referred to as runners, for every job. These separate VMs give the required isolation for a trusted builder, in order that totally different VMs compile the mission and generate and signal the SLSA provenance (see diagram beneath).
Operating the workflow on GitHub-hosted runners offers the assure that the code run is in reality the meant 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 towards doable interference from maintainers, who may in any other case attempt to outline the workflow in a method that interferes with the builder. The one option to work together with a reusable workflow is thru the enter parameters it exposes to the calling workflow, which stops maintainers from altering info through surroundings variables, steps, providers and defaults.
To guard towards the potential for 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 (because of dimension limitations) after which use the hashes to confirm the binary obtained through the untrusted artifact registry.
OpenID Join (OIDC) is a typical used throughout the net for id suppliers (e.g., Google) to attest to the id of a person for a 3rd get together. GitHub now helps OIDC of their workflows. Every time a workflow is run, a runner can mint a novel JWT token from GitHub’s OIDC supplier. The token comprises verifiable info of the workflow id, together with the caller repository, commit hash, set off, and the present (reuseable) workflow path and reference.
Utilizing OIDC, the workflow proves its id 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 id. A document of signing the provenance is stored 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 will need to have been created contained in the trusted builder.
- Lookup the corresponding Rekor log entry and confirm the signature;
- Confirm the trusted builder id by extracting it from the signing certificates;
- Examine that the provenance info matches the anticipated supply and construct.
See an instance in motion within the official repository.
Performing these steps ensures to the patron that the binary was produced within the trusted builder at a given commit hash attested to within the provenance. They will 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 method for guaranteeing software program supply-chain integrity at scale. This prototype reveals that attaining excessive SLSA ranges is less complicated than ever because of the latest options of fashionable 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 recommendations at slsa-github-generator-go and slsa-verifier mission repositories. We’ll formally launch v1 in just a few weeks!
In follow-up posts, we are going to exhibit including non-forgeable supply provenance testifying to safe repository settings, and showcase the identical strategies for different construct toolchains and package deal managers, and many others. Keep tuned!
