Every CI/CD pipeline is a supply chain. Source code travels through build systems, test runners, artifact registries, and deployment controllers before it reaches production — and every step in that chain is a potential attack surface. The SLSA framework (Supply-chain Levels for Software Artifacts, pronounced "salsa") provides a structured, incrementally adoptable model for hardening build pipelines so that organizations can answer two questions with confidence: what code ran in production, and can we prove nobody tampered with it between the pull request and the running container? This guide maps SLSA levels to concrete CI/CD controls that platform teams can implement this quarter, with practical examples for GitHub Actions and Kubernetes admission.
What Is the SLSA Framework and Why It Matters
SLSA is a security framework developed under the OpenSSF that defines four levels of build pipeline integrity, from basic provenance generation at Level 1 to fully hermetic, isolated builds with two-person review and non-falsifiable attestations at Level 4. The framework emerged from Google's internal Binary Authorization for Borg program, which has enforced build attestations across Google's production infrastructure for over a decade. SLSA adapts those lessons for the broader open-source and enterprise ecosystem. The core insight is that securing the source repository is not enough: an attacker who gains write access to a CI/CD configuration can inject malicious code, tamper with build artifacts, or exfiltrate secrets without ever touching the source tree. SLSA addresses this by requiring that every build artifact carries a verifiable provenance record — a cryptographically signed statement describing how, when, and from what source the artifact was produced.
SLSA Levels: From Build Scripts to Hermetic Builds
SLSA defines four levels, each building on the previous one. Platform teams can adopt them incrementally, starting with the highest-impact and lowest-effort controls, then progressing toward defense-in-depth as the pipeline matures. The levels are not a certification program; they are a roadmap for reducing supply chain risk in measurable, auditable steps that align with existing CI/CD infrastructure.
Level 1: Provenance Generation
At SLSA Level 1, the build process produces a provenance attestation that records the source repository, commit hash, builder identity, and build command. The attestation is not required to be tamper-proof — it can be a simple JSON document — but it must be available for inspection. This level requires minimal changes to existing pipelines and provides immediate value during incident response: when a vulnerability is discovered in a container image, the provenance record tells responders exactly which source commit produced it and which build system was used, eliminating the manual forensic work of tracing images back to source. The SLSA GitHub Generator, an official OpenSSF project, automates Level 1 provenance for GitHub Actions with a single workflow addition that requires no additional infrastructure.
Level 2: Hosted Build Platform
Level 2 requires that builds run on a hosted platform such as GitHub Actions, Google Cloud Build, or GitLab CI, rather than on an engineer's laptop or a self-managed server. The hosted platform provides build isolation, ephemeral build environments, and configuration-as-code that makes it harder for an attacker to tamper with the build process without leaving an audit trail. The platform must also sign the provenance attestation it generates, making the provenance verifiable: a consumer can check the signature to confirm that the attestation was produced by the expected build service and has not been modified. Google Cloud Build supports SLSA Level 2 provenance natively through the requestedVerifyOption build option, which generates signed build provenance in the in-toto attestation format that downstream verifiers can validate.
Level 3: Hardened Build Platform
Level 3 raises the bar significantly by requiring that the build platform itself enforces security controls that prevent tampering even by insiders with platform access. Build steps must run in isolated environments with no network access except to explicitly declared endpoints. Build configurations must be defined in version-controlled, reviewed files — not modified through web UIs or API calls outside the normal change management process. The provenance attestation must be non-falsifiable, meaning the build platform cryptographically guarantees that the recorded inputs and outputs match what actually occurred during the build. At this level, an attacker who compromises a CI/CD administrator account cannot modify a build definition or inject code without being detected, because any change to the build process would produce a different provenance record that fails verification downstream.
Practical Implementation: Generating Provenance with SLSA-GitHub-Generator
The fastest path to SLSA Level 1 for teams using GitHub Actions is the slsa-framework/slsa-github-generator reusable workflow. It requires no additional infrastructure and adds a single job to an existing workflow. The generator consumes the calling workflow's source checkout and produces a signed provenance attestation in the in-toto format, which can be uploaded alongside the build artifact or stored in a transparency log. Below is a minimal workflow that builds a Docker image and generates a provenance attestation:
name: Build and attest container image on: push: branches: [main] permissions: id-token: write contents: read actions: read jobs: build: outputs: digest: ${{ steps.build.outputs.digest }} runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - id: build uses: docker/build-push-action@v6 with: push: true tags: us-central1-docker.pkg.dev/my-project/repo/app:latest provenance: needs: [build] permissions: actions: read id-token: write contents: write uses: slsa-framework/slsa-github-generator/.github/workflows/ generator_container_slsa3.yml@v2.1.0 with: image: us-central1-docker.pkg.dev/my-project/repo/app digest: ${{ needs.build.outputs.digest }}
The provenance job uses the id-token permission to obtain an OIDC token from GitHub, which the generator uses to sign the attestation. The resulting attestation binds together the source repository, the triggering commit SHA, the builder workflow path, and the container image digest in a single verifiable document. Teams can extend this pattern to include vulnerability scan results, test pass/fail status, and SBOM generation as additional attestation predicates.
Verifying Provenance Before Kubernetes Deployment
Generating provenance is only half the equation. The attestation is only valuable if the deployment pipeline verifies it before admitting an image into a production cluster. Verification answers the question: was this container image built by our authorized CI/CD pipeline from the expected source repository and commit? If verification fails, the deployment is blocked — preventing an attacker who has pushed a malicious image to the registry from deploying it, even if they have Kubernetes deploy permissions.
The SLSA verifier CLI can be integrated into a GitOps workflow or a Kubernetes admission controller. A typical verification command in a deployment pipeline looks like this:
slsa-verifier verify-image \ us-central1-docker.pkg.dev/my-project/repo/app@sha256:abc123 \ --source-uri github.com/my-org/my-repo \ --builder-id https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v2.1.0
If the image was built from a different repository or by a different builder, the verification fails with a non-zero exit code, and the pipeline should halt the deployment. For Kubernetes-native enforcement, teams can deploy an admission controller such as Sigstore Policy Controller or Kyverno with a policy that requires a valid SLSA provenance attestation for every container image in a production namespace. This complements existing container image supply chain security controls by adding build-time integrity verification to the runtime admission layer.
SLSA Adoption Checklist for Platform Teams
- Generate provenance attestations for every production container image using the SLSA GitHub Generator or your build platform's native provenance support. Start with the images that handle customer data or authentication.
- Store attestations alongside container images in the same registry or in a dedicated attestation store. Set a retention policy that matches your incident response window — at least 90 days for production artifacts.
- Add a provenance verification step to the deployment pipeline that blocks promotion to production when verification fails. Test the block in a staging environment first to avoid disrupting legitimate deployments.
- Configure your build platform to run all build steps in ephemeral, isolated environments. Disable persistent build caches that can be poisoned across builds and invalidate provenance guarantees.
- Move build configuration into version-controlled workflow files. Disable manual trigger overrides and web UI edits for production pipelines to close the configuration tampering vector.
- Review and minimize the OIDC token permissions granted to build workflows. The build job should not have permissions it does not need, and provenance generation should use a dedicated identity separate from the build identity.
- Document the expected builder identity for each production image and configure monitoring that alerts when an image appears in the production registry without an expected provenance attestation.
SLSA is one of those security investments where the early wins are disproportionately large relative to the effort. Generating provenance for your production container images takes a single workflow file change, and the resulting attestation closes the most common supply chain blind spot — not knowing which source commit produced a given artifact. As your pipeline matures through the levels, the controls become progressively stronger without requiring a rip-and-replace of existing CI/CD infrastructure. If your team wants a second pair of eyes on your build pipeline before the next production release, Secpros can review your CI/CD configuration, artifact signing, and Kubernetes admission controls and return a short prioritized hardening plan — usually within one sprint — so your team can ship with more confidence and fewer supply chain blind spots.