The gap between understanding SLSA and implementing it is wider than most DevSecOps teams expect. The framework documentation describes what each level requires—provenance documentation, authenticated signatures, hermetic builds—without providing the specific tooling choices and configuration steps that turn requirements into working pipeline controls.
This is a practical roadmap: specific tools, specific configurations, and specific implementation order for container workloads progressing from SLSA Level 1 through Level 3.
SLSA Level 1: Provenance Documentation
What it requires: The build produces a provenance document. The document records: what source code produced the artifact, what build system ran the build, the build configuration used, and the resulting artifact digest. The provenance doesn’t need to be signed at Level 1.
How to implement for GitHub Actions:
# .github/workflows/build.yml
jobs:
build:
uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v1.9.0
with:
image: ${{ needs.build.outputs.image }}
digest: ${{ needs.build.outputs.digest }}
The slsa-github-generator repository provides reusable workflows that generate SLSA provenance for container builds. The generator workflow handles provenance document creation; the calling workflow provides the image and digest.
Verification: Download the provenance attestation from the GitHub release artifacts and verify it references the correct source commit, build configuration, and image digest. The slsa-verifier tool verifies Level 1 provenance documents.
Effort: Low. One workflow change, no infrastructure additions.
SLSA Level 2: Authenticated Provenance
What it requires: The provenance is signed by the build service, not just generated by it. The signature provides cryptographic evidence that the provenance was generated by the authorized build system during the actual build—not created after the fact.
How to implement: GitHub Actions workflows using the slsa-github-generator automatically produce Level 2 provenance when called from the generator workflow. The generator uses OIDC-based identity from GitHub Actions to sign the provenance with Sigstore’s Fulcio CA and publish the signature to Rekor.
For teams not using the generator workflow, add Cosign keyless signing to the build pipeline:
# In CI, after building and pushing the image
cosign sign –yes $IMAGE_DIGEST
Cosign keyless signing uses the CI system’s OIDC token to sign the image with Fulcio-issued certificates, logged to Rekor. This provides Level 2 authenticated signing without key management.
Secure software supply chain organizations at Level 2 can verify the provenance of any image by checking the Rekor transparency log for the signing event and verifying the certificate chain back to Fulcio.
Verification:
cosign verify –certificate-identity-regexp=”^https://github.com/your-org/your-repo/.+” \
–certificate-oidc-issuer=”https://token.actions.githubusercontent.com” \
$IMAGE_DIGEST
Effort: Low-to-medium. Add Cosign signing to the build pipeline. No infrastructure additions if using cloud-based CI with OIDC support.
SLSA Level 3: Build Environment Isolation
What it requires: The build environment is isolated from the code being built (hermetic), and the build process is reproducible. The build must run in an isolated environment where the code under test cannot influence the build infrastructure.
This is the level where significant infrastructure investment begins. Standard CI runners—GitHub Actions hosted runners, GitLab CI runners—don’t satisfy hermetic build requirements because the build environment can access the network during build, can be influenced by environment variables set by the code, and isn’t fully isolated from other builds sharing the runner.
Implementation options for containers:
Kubernetes Job isolation: Build pipelines that run each build in a dedicated Kubernetes Job with network policies that restrict outbound access, read-only filesystem for the build environment (separate from the workspace), and ephemeral credentials that expire after the job completes.
Cloud Build with hermetic settings: GCP Cloud Build with network isolation configured, AWS CodeBuild with VPC isolation, or Azure Pipeline agents with restricted network access can satisfy Level 3 isolation requirements with appropriate configuration.
Container image software build pipelines at Level 3 should also include attestations for the hardening step that runs between the initial build and the registry promotion—documenting that the hardening step ran in the same isolated environment and that its inputs and outputs are covered by the provenance chain.
Effort: High. Requires changes to CI infrastructure, runner configuration, and potentially migration to different build systems.
Practical Implementation Path
Phase 1 (Days 1-3): Level 1 provenance
- Add slsa-github-generator workflow to container build pipelines
- Verify provenance document generation for a test build
- Store provenance artifacts alongside releases
Phase 2 (Weeks 1-2): Level 2 signing
- Add Cosign signing to the build pipeline after image push
- Configure Rekor transparency log upload (default with keyless signing)
- Add signature verification to the admission controller configuration
Phase 3 (Months 2-6): Level 3 isolation
- Evaluate current CI runner isolation against Level 3 requirements
- Identify gaps: network access during build, environment variable influence
- Implement isolation controls or migrate to a build system with hermetic support
- Verify reproducibility for a test case before applying fleet-wide
Frequently Asked Questions
What are the SLSA framework levels and what does each require for supply chain security?
SLSA Level 1 requires that the build produces a provenance document recording the source, build system, configuration, and output digest—no signature required. Level 2 adds authenticated provenance: the build service cryptographically signs the provenance, providing evidence it was generated during the actual build by the authorized system rather than created after the fact. Level 3 requires a hermetically isolated build environment where the code under build cannot influence the build infrastructure and builds are reproducible, which demands significant CI infrastructure changes beyond what cloud-hosted runners typically provide.
How do you implement SLSA provenance for GitHub Actions container builds?
Add the slsa-github-generator reusable workflow to your container build pipeline, providing the image name and digest as inputs. The generator workflow automatically produces Level 1 and Level 2 provenance by using GitHub Actions’ OIDC identity to sign the provenance with Sigstore’s Fulcio CA and log it to Rekor. For Level 2 signing without the generator workflow, add cosign sign –yes $IMAGE_DIGEST to the pipeline after image push, which performs keyless signing using the CI system’s OIDC token with no key management required.
Is SLSA Level 3 necessary for most container supply chain security programs?
For most commercial container deployments, SLSA Level 2 with comprehensive SBOM and vulnerability scan attestations provides greater practical security improvement than Level 3 without those attestations. Level 3 addresses hermetic build environment guarantees relevant to the most sensitive threat models—where an adversary could influence the build environment itself—but the infrastructure investment is high and the marginal security gain over Level 2 is limited for standard workloads. The highest-value combination is Level 2 provenance plus a signed SBOM attestation plus a signed vulnerability scan result.
What is Cosign keyless signing and how does it support SLSA supply chain security implementation?
Cosign keyless signing uses the CI system’s OIDC token—in GitHub Actions, this is the workflow’s identity—to obtain a short-lived certificate from Sigstore’s Fulcio CA and sign the container image or attestation, with the signing event logged to the Rekor transparency log. This provides cryptographic authentication of the build identity without requiring teams to manage long-lived signing keys. Verifiers can confirm that an image was signed by a specific GitHub Actions workflow in a specific repository by checking the Rekor log and verifying the certificate chain back to Fulcio.
Level 2 With Strong Attestation Coverage Is Usually Sufficient
For most organizations, the practical security improvement from Level 2 with comprehensive SBOM and vulnerability attestations exceeds the improvement from Level 3 without those attestations. Level 3 addresses the hermetic build environment requirement; SBOM and scan result attestations address what the build produced.
The highest-value SLSA implementation for container workloads is Level 2 provenance + signed SBOM attestation + signed vulnerability scan result. This combination provides authenticated evidence of how the image was built (Level 2 provenance) and what it contains (SBOM) with current security quality (scan result). Level 3 adds hermetic environment guarantees that matter for the most sensitive threat models but are overkill for most commercial container deployments.
