Following the recent launch of SLSA v1.0, we’re announcing a new, GitHub Actions workflow that achieves SLSA Build Track Level 3 for provenance generation. This lets users generate unforgeable provenance, allowing consumers to trust and verify how their software artifacts were built. The container-based SLSA 3 builder is the result of a collaboration between the Google Open Source Security Team (GOSST), the SLSA community, and Project Oak.

How it works

The new container-based SLSA 3 builder runs a containerised build in a secure environment and generates an unforgeable provenance statement of the execution, all in an ecosystem-agnostic way that’s easy to add to your GitHub CI.

To ensure unforgeability of provenance, the container-based SLSA 3 builder uses the same secure build mechanisms used in other SLSA builders and generators, relying on GitHub reusable workflows and ephemeral VM containers for isolation. For more details, see the technical design document. As before, we rely on OpenID Connect (OIDC) with Sigstore tooling to prove the identity of the workflow. These provide the workflow identity guarantees described in an earlier blog post that announced the generic SLSA 3 generator.

The builder allows a developer to run a custom command in a container in a secure environment, which gives the developer full control of the environment and customization of the container’s function. For example, the developer may choose to use the command to build a binary artifact, or produce metadata like OpenSSF’s Scorecard reports.

Enhanced provenance verification with the new workflow

The container-based SLSA 3 builder differs from earlier builders and generators in the content of the generated provenance statements, and therefore how they can be verified. Like all provenance generated by all SLSA 3 builders and generators, you can trace the binary to its source code and verify the builder’s identity—and now, you can additionally perform detailed verification of the build process.

For instance, the provenance produced by the generic SLSA 3 provenance generator minimally contains the source GitHub repository and a reference to the workflow file that built the artifact. This workflow may contain any operation, ranging from copying a pre-built binary from another resource to running a massive build script. Because the provenance does not include these details, verifiers need to audit the referenced workflow file to establish trust in the build process.

The container-based SLSA 3 builder simplifies and enhances provenance verification by including the build process directly inside the provenance. This is enabled by a Docker-based build tool used internally in the container-based SLSA 3 builder for building the binaries and the new SLSA v1.0 provenance format. In particular, it includes the builder image and command directly inside the build definition:

        "cargo", "build", "--release"

Next Steps

If your builds are already containerized, we encourage you to give the container-based SLSA 3 builder a try—see the step-by-step guide in our onboarding tutorial. Otherwise, we suggest containerizing your build, which also improves the reproducibility of your binaries, and adopting the container-based SLSA 3 builder.

Once you have generated a SLSA provenance with the container-based SLSA 3 builder, the next step to complete the lifecycle is to provide instructions to verify the artifacts, including using the slsa-verifier to verify the provenance. If you are using these artifacts in your own build pipeline, consider threat modeling your software supply chain and building expectations for your build origins and process.

Please share your success stories with us by creating a pull request to add your project to the list of container-based SLSA 3 users. Feel free to create issues on the repository if you have noticed any issues, or are missing features you need. We look forward to fulfilling new requests and accepting new contributors to create even more useful features going forward.