SLSA Framework Adoption in CI/CD Pipelines

SLSA, Supply chain Levels for Software Artifacts, was proposed by Google in 2021 and is now maintained by the OpenSSF. Its lineage is not academic. It's modeled on Google's internal Binary Authorization for Borg, which has been mandatory for all Google production workloads for over eight years. That origin changes how you should read the specification. This is not a framework developed in anticipation of a problem; it's a distillation of controls that operated at production scale in one of the world's largest software environments for nearly a decade before anyone wrote them down for public consumption.

The current stable release is SLSA v1.1, published in 2024. Version 1.2 is in active development. One scope boundary practitioners must internalize clearly is that the v1.0 release and its successors focus on the Build Track. The Source Track, which would extend integrity controls upstream of the build itself, remains under development. Teams that treat SLSA as a comprehensive security program will eventually bump into this boundary, usually when someone asks why a compromised developer account isn't addressed.

SLSA is not a vulnerability scanner. It's not a dependency audit tool. It doesn't replace code review, and it doesn't try to. It's specifically concerned with build integrity and the verifiable record of how an artifact was produced. Teams with mature static analysis practices and strong code review culture still need SLSA. Teams that implement SLSA still need static analysis and code review. The framework's scope is deliberately narrow, and that narrowness is a feature, not an omission.

The core mechanism is provenance, a cryptographically signed attestation, packaged in the in-toto format, that records the source repository, the commit hash, the dependencies, the build environment, and a cryptographic digest of the output artifact. It answers not just "what is this artifact" but "where did it come from, under what conditions, and can you prove it."

The Four Build Levels as a Progression of Concrete Controls, Not a Maturity Checklist

The four SLSA levels are frequently described as a maturity model. That framing is technically defensible but practically misleading. They're better understood as a cumulative state of the pipeline. Each level inherits and extends the previous one. L2 controls are prerequisites for L3, not a separate track.

L0 is the default state for most software today. No provenance, no traceability, no mechanism to detect tampering, no ability to reconstruct what happened after an incident.

L1 introduces provenance generation. The build process emits an unsigned record containing the source repository, the commit SHA, a dependency list, and a cryptographic digest of the output artifact. This prevents accidental releases of wrong versions and provides a baseline audit trail. It doesn't prevent a determined attacker from forging provenance, because the record is unsigned and the build environment is uncontrolled. L1 is not trivial, though. The discipline of describing a build precisely enough to attest to it surfaces gaps in scripting and environment specification that many teams didn't know they had. I've seen this phase take longer than expected precisely because it forces that reckoning.

L2 adds hosted builds and signed provenance. The build runs on a managed CI platform rather than a developer's local machine, and the platform itself generates and signs the attestation. For internal applications, L2 is the inflection point. Forgery becomes non-trivial; an attacker can no longer produce convincing false provenance without compromising the CI platform itself, which is a substantially higher bar than compromising a developer workstation or intercepting an artifact in transit.

L3 hardens the build environment. Builds run in ephemeral, isolated environments with no shared state between runs. Execution is hermetic, meaning no network access during the build, all inputs pre-declared and fetched deterministically before execution begins. The build environment cannot be influenced by user-controlled pipeline code. Two-party code review is required before any build, so even a fully compromised developer account cannot introduce malicious code without a second authorized reviewer.

One clarification from the v1.0 specification is worth noting: hermetic builds and full reproducibility were moved from strict requirements to recommended practices at L3. The framework acknowledges that full hermeticity is aspirational for many organizations. That's not a loophole; it's intellectual honesty about where the industry currently sits. The following sections explain what pursuing it actually requires.

Why L2 Is the Practical Near-Term Target for Most Teams and How to Get There in GitHub Actions Today

For the large majority of engineering teams, L2 is the realistic and highest-value near-term objective. It's the level at which provenance becomes non-forgeable through ordinary means, and it's achievable without custom tooling or restructuring the pipeline.

The SLSA GitHub Generator project, maintained under the SLSA framework, produces SLSA L3-compliant provenance as a reusable workflow callable from any GitHub Actions pipeline. Teams can reach L2 without writing a single custom attestation tool. The workflow generates and signs provenance using the calling repository's OIDC identity, which pulls in Sigstore.

Sigstore is a Linux Foundation project backed by Google, Red Hat, and Purdue University. It eliminates the need for long-lived private signing keys by issuing short-lived certificates tied to OIDC identities. The CI job's identity becomes the signing identity. There's no key management infrastructure to operate, no rotation schedule to maintain, no risk of key exfiltration. For teams that have historically avoided artifact signing because of operational burden, Sigstore removes the primary objection.

Kubernetes-native CI systems can integrate in-toto attestations and Cosign signing with minimal disruption. Nothing in the SLSA ecosystem requires wholesale replacement of existing pipeline infrastructure. Reaching L1 and L2 typically takes on the order of weeks for a team that already scripts its builds. L3 with full environment hardening takes months. Setting accurate expectations here is part of the implementation work.

One operational discipline that L2 forces, and that pays dividends beyond SLSA, is building and deploying with commit SHA-based image tags rather than mutable tags like :latest. An image tagged my-app:0ab43f refers to exactly one artifact. An image tagged my-app:latest will silently refer to a different artifact tomorrow. Verifiable provenance requires that the artifact referenced in an attestation is the artifact that gets deployed. Mutable tags break that chain at the most basic level.

Hermetic Builds and What They Demand from the Environment Before the Build Starts

A hermetic build is one in which all inputs, source code, tools, compiler versions, build scripts, and configuration, are explicitly declared and pinned before execution begins, and the build process fetches nothing from the network at runtime. The output is determined entirely by those pre-declared inputs.

This is considerably harder than it sounds, and I want to be direct about that. Most CI pipelines implicitly pull from package managers, container registries, or action marketplaces during the build. Each of those fetches crosses a trust boundary. Any one of them can introduce a dependency that's different from the one the developer tested against. Hermeticity eliminates those fetches, not by ignoring the dependencies, but by resolving them before the build begins and verifying them at resolution time.

Environment drift is a supply chain problem in its own right. If a developer's local environment, the CI runner, and the production deployment target all resolve "the same" dependencies to different versions, then provenance attestations describe different artifacts depending on where the build ran. The SLSA guarantee collapses in practice even if the tooling is in place. Signed provenance for a build that produces non-deterministic output is not meaningless, but it's substantially weaker than signed provenance for a hermetic build. The signature attests to what happened, not to what should have happened. That distinction matters when you're investigating an incident.

What hermetic builds actually require is a reproducible, fully-specified environment consistent across local development, CI, and deployment. The toolchain itself, compilers, language runtimes, container base images, build utilities, must be pinned alongside application dependencies. Teams that have pinned application dependencies with a lockfile but left the toolchain floating have done half the work and do not realize it.

This is where environment management tooling becomes structurally important. Flox provides reproducible environments that pin every layer of the dependency stack, including the toolchain, with provenance and SBOM data embedded in the environment definition rather than generated as a post-build artifact. It approaches the hermetic-build and dependency-tracking problem from the development environment side, so the pre-declared inputs that hermeticity requires are established before the first CI run rather than retrofitted into an existing pipeline.

Hermetic environments also make drift detectable. If two builds of the same source commit produce different output digests, the environment specification becomes the audit trail. Without a fully-specified environment, that investigation becomes reconstruction after the fact, and reconstruction after a breach is an expensive, uncertain process.

Where SBOMs Fit into a SLSA Pipeline and Why They Are Not the Same Thing as Provenance

The distinction between SLSA provenance and a Software Bill of Materials is frequently collapsed in practice, and collapsing it causes concrete implementation errors.

Provenance records how an artifact was built: the process, the environment, the build system identity, a digest of the output. An SBOM records what components an artifact contains: the libraries, packages, and their versions. Together, they enable reasoning about both process risk and composition risk. An artifact with clean provenance and a vulnerable dependency is still a problem; an artifact with a clean SBOM and tampered provenance is equally a problem. You need both.

The two dominant SBOM formats in active use are SPDX, maintained by the Linux Foundation, and CycloneDX, which has become prevalent among open-source adopters. Both are mature, both are supported by current tooling, and both are referenced in CISA's 2025 updated SBOM guidance.

The gap between SBOM policy and SBOM reality is large. Roughly half of analyzed software projects have SBOMs available at all, and only a small fraction of those contain the minimum recommended information fields. An organization with an SBOM policy and incomplete, auto-generated SBOMs has documentation risk alongside its security risk. Those two problems compound.

Gartner has projected that the majority of organizations building or procuring critical infrastructure software would be mandating SBOMs, a significant increase from the small minority doing so just a few years prior. CISA's 2025 guidance updates reflect current maturity expectations, not aspirational ones.

For teams implementing SLSA L1 and L2, the most pragmatic approach is generating the SBOM at build time, in the same context that produces provenance. The build context already has visibility into the full dependency graph. Reconstructing that visibility after the fact is possible but more expensive and less reliable. Given that most teams are already instrumenting the build for provenance, adding SBOM generation in the same step is the obvious move.

The Regulatory Environment That Is Turning SLSA-Aligned Practices from Optional to Expected

Three regulatory instruments are currently reshaping the landscape for supply chain security controls.

U.S. Executive Order 14028 on Improving the Nation's Cybersecurity directed NIST to develop the Secure Software Development Framework. The OpenSSF has published an explicit mapping between SLSA controls and SSDF requirements. Organizations pursuing SSDF alignment for federal contracts can treat SLSA implementation as a path to compliance evidence, not a parallel workstream.

The EU Cyber Resilience Act requires manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents, with that obligation taking effect in September 2026. Supply chain provenance is structurally necessary for that reporting requirement. An organization that cannot reconstruct the build history of an artifact under active exploitation cannot fulfill its CRA reporting obligation. That's a gap that will surface at the worst possible moment.

NIS2, whose transposition deadline was October 2024, affects essential and important entities across the European Union. It raises the baseline for software supply chain risk management and vendor governance across sectors that were previously operating under lighter regulatory obligations.

SLSA is not a compliance standard. It doesn't map one-to-one to any regulatory requirement, and claiming SLSA certification as regulatory compliance would be inaccurate. SLSA controls produce the artifacts that compliance frameworks increasingly treat as evidence. Signed provenance, hermetic build records, and two-party review logs are what auditors request. SLSA is the mechanism for generating that documentation as a byproduct of a secure build process rather than as a retrospective reconstruction. The organizations that have understood this are not deliberating over whether to implement supply chain controls. They're deliberating over which controls, in what order, and how to produce documentation that compliance reviewers will accept.

A Phased Implementation Sequence That Reflects How Pipeline Controls Actually Compound

A 2024 analysis of over 1,500 SLSA-related GitHub issues found that confusion over implementation requirements and ambiguous specification language are the two dominant blockers. The fastest way through that confusion is to start with L1 tooling and read actual provenance output. Abstract specification language becomes concrete when you're looking at a real in-toto attestation for a real build.

Phase 1, weeks one through four: Inventory every build pipeline and artifact. Ensure all builds are fully scripted with no manual steps. This is the prerequisite for provenance generation of any kind. You can't attest to a process you can't describe. Teams frequently discover in this phase that some builds are partially manual, some artifacts are built in multiple places, and some pipelines have implicit dependencies that have never been documented. That discovery alone is worth the effort.

Phase 2, weeks four through eight: Instrument builds to emit in-toto provenance. For GitHub Actions teams, the SLSA GitHub Generator provides this as a reusable workflow. Train the team on reading and storing attestations. L1 attestations are unsigned, but generating and inspecting them builds the operational familiarity needed for subsequent phases.

Phase 3, weeks eight through twelve: Move builds fully onto a managed CI platform if they aren't already. Integrate Sigstore and Cosign for keyless signing. Establish verification gates at deployment, meaning nothing deploys without a valid, verifiable provenance attestation signed by the expected identity. This is the L2 inflection point, where provenance transitions from an audit record to an actual gate.

Phase 4, months not weeks: Pin the full toolchain in a reproducible environment specification. Enforce hermetic execution by pre-declaring all inputs and disabling network access during the build. Add or verify two-party review gates in source control. Teams running Kubernetes-native CI have a shorter path to L3 environment hardening, because ephemeral build runners on Kubernetes provide build isolation and no shared state between runs as native properties of the platform.

The phases compound. Scripting discipline from Phase 1 makes Phase 2 tractable. Provenance tooling from Phase 2 provides the signing infrastructure Phase 3 builds on. The hermetic environment from Phase 4 is what makes the L2 provenance attestations produced in Phase 3 genuinely meaningful rather than technically accurate but practically weak. Skip a phase and you're building on an incomplete foundation.

What Verification at Deployment Actually Looks Like and Why Provenance Without a Consumption Policy Is Incomplete

Provenance generation without verification at deployment is an audit capability, not a security control. Many teams implement signing at build time and then never enforce verification at deploy time. The attestation sits in a registry, available for forensic review after a breach but providing no prevention before one.

Verification at deployment means the deployment mechanism rejects any artifact that lacks a valid provenance attestation; rejects any artifact whose attestation was signed by an unexpected identity; and rejects any artifact whose source digest doesn't match the deployed image digest. All three conditions must be enforced. Enforcing two of three leaves an exploitable gap.

Kubernetes admission controllers can gate deployments on attestation validity, consulting the attestation store and evaluating policy before permitting a workload to start. Binary authorization mechanisms, the model that inspired SLSA through Google's Binary Authorization for Borg, provide equivalent control in cloud-native environments. The enforcement point is close to deployment, which is where prevention actually matters.

GitOps is the natural complement to this. Storing declarative infrastructure and application configuration in Git and automating sync to clusters through tools like Argo CD or Flux means the desired state is always version-controlled. Drift between what provenance describes and what actually runs becomes detectable. The desired state in Git and the running state in the cluster can be compared, and divergence triggers an alert rather than going unnoticed.

The organizational requirement that closes the loop is that a provenance policy needs an owner. Someone must be responsible for defining what valid provenance means for each artifact class, for maintaining verification rules as the pipeline evolves, and for reviewing exceptions when they arise. Provenance infrastructure without policy ownership becomes stale. The tooling is tractable; the governance is consistently the harder problem, and it's the one that most implementation guides understate or skip entirely.