Every of those assaults might have been prevented if there have been a technique 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 often known as provenance) was tough. This info permits customers to hint artifacts verifiably again to the supply and develop risk-based insurance policies round what they devour. Presently, provenance era isn’t broadly supported, and options that do exist might require migrating construct processes to providers like Tekton Chains.
This weblog publish 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, initiatives 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 publish 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, it’s worthwhile to:
- Isolate the provenance era from the construct course of;
- Isolate towards maintainers interfering within the workflow;
- Present a mechanism to establish 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 known as trusted builders.
Our Go prototype solves all three challenges. It additionally consists of 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. Inside the workflow, Github Actions creates recent situations of digital machines (VMs), known as runners, for every job. These separate VMs give the mandatory isolation for a trusted builder, in order that completely different VMs compile the challenge and generate and signal the SLSA provenance (see diagram beneath).
Working the workflow on GitHub-hosted runners offers the assure that the code run is in reality 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 towards doable interference from maintainers, who might in any other case attempt to outline the workflow in a manner that interferes with the builder. The one technique 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 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 information. We use job outputs to ship hashes (attributable to dimension limitations) after which use the hashes to confirm the binary obtained through the untrusted artifact registry.
OpenID Join (OIDC) is a normal used throughout the net for id suppliers (e.g., Google) to attest to the id of a person 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 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 report 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 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;
- Test 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 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 knowledge 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 manner for making certain software program supply-chain integrity at scale. This prototype exhibits that attaining excessive SLSA ranges is less complicated than ever due to the latest options of in style CI/CD techniques 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 challenge. Please share suggestions, feedback and options at slsa-github-generator-go and slsa-verifier challenge repositories. We are going to formally launch v1 in just a few weeks!
In follow-up posts, we are going to show 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!