Enhancing software program provide chain safety with tamper-proof builds



Most of the current high-profile software program assaults which have alarmed open-source customers globally had been penalties of provide chain integrity vulnerabilities: attackers gained management of a construct server to use malicious supply information, inject malicious artifacts right into a compromised construct platform, and bypass trusted builders to add malicious artifacts.

Every of those assaults may have been prevented if there have been a approach 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 troublesome. This data permits customers to hint artifacts verifiably again to the supply and develop risk-based insurance policies round what they eat. At the moment, provenance era isn’t extensively supported, and options that do exist might require migrating construct processes to providers like Tekton Chains.

This weblog put up describes a brand new methodology of producing non-forgeable provenance utilizing GitHub Actions workflows for isolation and Sigstore’s signing instruments for authenticity. Utilizing this strategy, initiatives 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.

SLSA (“Provide-chain Ranges for Software program Artifacts”) is a framework to assist enhance the integrity of your venture all through its growth cycle, permitting shoppers to hint the ultimate piece of software program you launch all the way in which again to the supply. Reaching a excessive SLSA stage helps to enhance the belief that your artifacts are what you say they’re.

This weblog put up 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 good to:

  1. Isolate the provenance era from the construct course of;
  2. Isolate towards maintainers interfering within the workflow;
  3. Present a mechanism to establish the builder throughout provenance verification.

The complete 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 consists of working the construct contained in the trusted builder, which supplies a powerful 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.

Step One: Create a reusable workflow on GitHub runners

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 required isolation for a trusted builder, in order that completely different VMs compile the venture 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 towards attainable interference from maintainers, who may in any other case attempt to outline the workflow in a method that interferes with the builder. The one approach to work together with a reusable workflow is thru the enter parameters it exposes to the calling workflow, which stops maintainers from altering data by way of setting 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 strategy makes use of a trusted channel to guard the integrity of the info. We use job outputs to ship hashes (attributable to dimension limitations) after which use the hashes to confirm the binary obtained by way of the untrusted artifact registry.

Step 2: Use OpenID Join (OIDC) to show the id of the workflow to an exterior service (Sigstore)

OpenID Join (OIDC) is a typical used throughout the online for id suppliers (e.g., Google) to attest to the id 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 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 file 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.

The patron can confirm the artifact and its signed provenance with these steps:

  1. Lookup the corresponding Rekor log entry and confirm the signature;
  2. Confirm the trusted builder id by extracting it from the signing certificates;
  3. Verify 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 patron 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.

One additional good thing about this methodology is that maintainers don’t have to handle or distribute cryptographic keys for signing, avoiding the notoriously troublesome drawback of key administration. The OIDC protocol requires no hardcoded, long-term secrets and techniques be saved in GitHub’s secrets and techniques, which sidesteps the potential drawback of key mismanagement invalidating the SLSA provenance. Shoppers merely use OIDC to confirm that the binary artifact was constructed from a trusted builder that produced the anticipated provenance.
Using the SLSA framework is a confirmed method for guaranteeing software program supply-chain integrity at scale. This prototype reveals that reaching excessive SLSA ranges is less complicated than ever due to the latest options of widespread CI/CD methods 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 venture. Please share suggestions, feedback and ideas at slsa-github-generator-go and slsa-verifier venture repositories. We’ll 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 package deal managers, and so forth. Keep tuned!