SLSA Framework Levels and What They Require in Practice

SLSA is an open framework for build integrity, provenance, and tamper resistance. Not a tool, not a vendor product. A specification that defines a graduated set of requirements an organization must satisfy to demonstrate that its software artifacts are what they claim to be and were built the way they claim to have been built.

Google proposed the framework in 2021; it's now maintained by the Open Source Security Foundation. Its intellectual heritage is not academic. SLSA descends directly from Google's internal Binary Authorization for Borg system, mandatory for all Google production workloads for more than eight years. Contributing organizations include Chainguard, Citi, the Cloud Native Computing Foundation, Datadog, Intel, Kusari, the Linux Foundation, and Verizon. That breadth signals simultaneous adoption pressure from enterprise, cloud-native, financial services, and infrastructure communities — a different and harder thing to achieve than any single community driving a standard.

The current specification is v1.2, approved in November 2025. It defines two tracks. The Build track runs from L0, which represents no provenance whatsoever, through L3, which requires a hardened, tamper-resistant build platform. The Source track, promoted from experimental to approved status in v1.2, addresses how code enters a repository and reaches protected branches, a question entirely separate from how artifacts are compiled. The old v0.1 model required four levels, including hermetic builds at L4. That model was retired with v1.0 in 2023; hermetic and reproducible build requirements are now deferred to a future Build L4 not yet in the current specification.

Provenance, as SLSA uses the term, is the "who, where, and when" of a software artifact: which source code, which build system, which platform, at what time. SLSA concerns itself with whether the build process that produced an artifact can be trusted. It doesn't enumerate the components inside that artifact. That is the responsibility of a Software Bill of Materials. The two are complementary, and conflating them leads organizations to underinvest in both.

The incidents that made SLSA urgent are instructive. The SolarWinds attack delivered a tampered build to more than 18,000 organizations. Log4Shell exposed millions of applications through a transitive dependency most teams didn't know they carried. In both cases, the artifact appeared legitimate, the build process appeared normal, and no cryptographic mechanism existed to challenge either appearance. Between 2019 and 2022, supply chain attacks increased 742%, per Sonatype research. By 2025, global costs had reached $60 billion, with projections approaching $138 billion by 2031. Wiz's 2025 State of Code Security Report found that 61% of organizations have secrets exposed in public repositories. These aren't edge cases. They're the normal operating environment.

Build L0 and L1: Establishing a Provenance Record Where None Existed

L0 is not a level in any meaningful security sense. It's a baseline acknowledgment that no provenance exists and no controls are in place. L0 is acceptable only when a developer builds and tests software on the same local machine with no artifact ever leaving that context.

L1 has exactly one concrete requirement: the build platform must automatically generate provenance describing how the artifact was built, and that provenance must be available to consumers. It imposes no requirement about where the build runs, nothing about who signs the provenance, and nothing about whether that provenance could be forged.

At L1, an attacker who controls the build platform can produce entirely fabricated provenance. The provenance establishes a record; it doesn't establish a trustworthy one. This isn't a design flaw. It's a deliberate staging of requirements that reflects how software organizations actually mature — teams that have never emitted provenance for any pipeline gain something real at L1: a documented artifact lineage they can build on. The specification's authors understood that demanding L3 controls from an organization that doesn't yet have consistent provenance generation is how frameworks die unused.

A focused team can complete the technical integration for a single pipeline in two to four weeks. The harder work at L1 is organizational. Getting every pipeline, across every team, to emit provenance consistently requires engineering discipline around pipeline configuration and genuine visibility into the full scope of pipelines in operation, many of which are poorly documented in most organizations. I've seen enterprises discover, mid-program, that they had two or three times as many active pipelines as anyone had cataloged. That consistency, scaled across an enterprise, takes considerably longer than the tooling integration itself.

Build L2: Why Moving the Build Off Developer Machines Changes the Trust Model

L2 introduces two requirements that together alter the fundamental trust model of the build. The build must run on a hosted, managed platform rather than on a developer's laptop or a self-managed runner. And provenance must be generated by the platform itself, not by user-controlled code inside the build script.

The second requirement is where the security consequence lives. When the platform generates provenance rather than the build script, the build author can't overwrite it. A malicious or misconfigured script can't forge what the platform attests to. The provenance becomes a statement from a third party, the build system itself, rather than a self-attestation from whoever wrote the pipeline. That is a structurally different claim, and it matters.

On GitHub Actions, the SLSA GitHub Generator signs provenance using Sigstore's keyless signing tied to the runner's OIDC identity, and the signature is stored in the Rekor transparency log. GitHub Artifact Attestations provide SLSA v1.0 Build L2 out of the box for repositories already using GitHub Actions. npm trusted publishing auto-generates provenance attestations. For teams already on these platforms, L2 can be a configuration step rather than an infrastructure project. GitLab CI, Google Cloud Build, and Buildkite also qualify. The toolchain, including cosign, in-toto attestations, and the Sigstore components, is mature enough that most organizations can complete integration in four to eight weeks.

What L2 still doesn't prevent is a compromised developer account pushing malicious code, which will get that code built faithfully by the managed platform. The provenance will be accurate and cryptographically signed; it'll simply attest to a compromised build. L2 addresses who controls the build attestation, not who controls the source. That boundary matters enormously, and it's precisely where L3 begins.

Build L3: What Hardening the Platform Actually Requires from Engineering

L3 is where the requirements become infrastructure obligations rather than configuration choices. Three controls distinguish it from L2: isolation between build runs, signing keys inaccessible to user-defined build steps, and mandatory two-party code review before any source code enters the build.

Isolation, in concrete terms, means no build run can influence another. Shared caches, shared state, and shared secrets accessible across jobs are disqualifying. CI systems that persist state between builds, whether through shared volume mounts, improperly scoped secret stores, or reused containers, fail this requirement outright.

Signing key isolation means the keys that sign provenance are controlled by the build platform, not by users. Even a malicious insider with complete access to the build configuration can't forge provenance, because the signing material is outside their reach.

Two-party review requires that source code pass branch protection with required reviewers before it can be built. A single compromised developer account can't get malicious code into a production build without a second approver. That human control layer is something cryptographic signing alone cannot provide, a point that gets underemphasized in conversations that focus narrowly on key management.

The requirement that consumes the most engineering time at L3 is hermetic builds. A hermetic build pipeline can't resolve dependencies from PyPI, npm, or any external registry at build time. All dependencies must be vendored or pre-mirrored before the build runs. This is an infrastructure change, not a configuration toggle, and it reaches into every pipeline that currently resolves external packages during build execution. Build systems like Nix and Bazel are well-suited here because hermetic, reproducible builds are their native operating mode. For teams using conventional CI configurations, the transition requires establishing internal mirrors or vendoring processes and auditing every pipeline for external network calls at build time. That audit consistently surfaces more external calls than teams expect, and its scope determines how long L3 takes more than any single technical decision.

Two primary platform paths exist for reaching L3. On Google Cloud Platform, Cloud Build with private worker pools and no internet egress except to Artifact Registry, verified at admission control through Binary Authorization, represents the lower-effort path for GCP-heavy organizations. On GitHub, the architecture is more portable across multi-cloud environments, but achieving equivalent hermetic isolation requires more deliberate configuration.

The 2025 npm Mini Shai-Hulud attack illustrates why L3's isolation requirements matter. The compromised packages in that attack carried cryptographically valid SLSA provenance attestations. The platform behind them didn't meet L3 isolation requirements. A platform that did would have blocked the primary attack vector. Valid provenance from a non-isolated platform isn't the same as valid provenance from an isolated one, and that distinction is exactly what L3 encodes.

Most organizations should plan three to six months for L3 implementation. The timeline is driven primarily by dependency vendoring and platform hardening, not by the controls themselves.

The Gap Between Generating Provenance and Actually Verifying It

The most common SLSA failure mode in production is not a misconfigured build platform. It's provenance that exists, is signed, is stored in a transparency log, and is never verified before the artifact runs in production. Provenance that no gate consults documents build history without blocking anything.

Verification requires three things that generation doesn't. Policy-as-code must define which builder identities are trusted for which artifact types; hardcoded strings in admission control configurations become stale as platforms change and must be maintained as living configuration. Admission control must sit between the registry and the runtime, rejecting artifacts whose provenance fails verification. A check that runs post-deployment, or only in CI without a production gate, doesn't close the loop. And a named artifact's SLSA level reflects only its own build — it says nothing about the SLSA level of its dependencies. An L3-attested artifact can depend on L0 components, and the provenance chain won't surface that without additional tooling.

Kyverno handles Kubernetes admission control in this layer. GUAC handles provenance graph querying across complex dependency graphs. Binary Authorization handles GCP workloads. The architecture is available and has been for some time. What's scarce is the organizational discipline required to configure and maintain it — policy maintenance is unglamorous and doesn't close tickets.

The practitioners who have deployed SLSA at scale tend to agree: the industry has largely solved provenance generation. Registries are enabling it by default, platforms are automating it, and the toolchain is mature. Verification discipline — the policy maintenance, the admission control configuration, the dependency-level provenance querying — is the harder and less-finished problem. Whether that discipline catches up with the generation adoption already underway is what the next several years of this field will reveal.

How to Triage Which Pipelines Need Which Level

Attempting to bring every pipeline to L3 simultaneously is the most reliable way to stall an SLSA program. The dependency vendoring and platform hardening that L3 requires is not uniformly justified across every build in an organization, because the blast radius of a compromised build varies enormously depending on where the artifact goes.

A triage model used in production allocates levels by artifact destination. L3 applies to production-bound pipelines: builds that ship binaries or container images to customers or cloud infrastructure, where a tampered artifact reaches the largest number of users and the cost of a breach is highest. L2 applies to internal tooling, developer tools, staging pipelines, and internal services where the audience is limited and recovery is faster. L1 applies to everything else, establishing a provenance record without the infrastructure overhead that L2 and L3 require.

This tiered approach is defensible to auditors and tractable to engineering teams because it aligns investment with risk. A team that can't justify dependency vendoring at L3 for a low-blast-radius internal tool shouldn't be required to complete it. A team shipping software to federal agencies or financial institutions has a different calculation entirely, and they usually know it before the conversation starts.

Per Kusari's implementation guidance, scaling L1 consistently across an entire organization typically takes several months even after the technical integration is complete. The process change — ensuring every team emits provenance from every pipeline — is the long pole.

Regulatory context shapes prioritization as well. Executive Order 14028 and NIST Special Publication 800-218, the Secure Software Development Framework, both require SBOM generation. SLSA provides the build integrity complement. Organizations pursuing federal compliance need both, and neither substitutes for the other.

Where SBOMs Fit Alongside SLSA and What Each One Cannot Do Alone

An SBOM is the ingredient list. SLSA is the food safety certification. They answer different questions, and absent the other, each leaves a consequential gap.

An SBOM answers whether this artifact contains Log4j 2.14.1, what libraries are present, at what versions, under which licenses. It's a statement about composition. SLSA answers whether this artifact was built from the source code you think it was, whether the build process was tampered with, whether what you received matches what the publisher intended to ship. It's a statement about process integrity.

An artifact can carry perfect SLSA L3 provenance and still contain a vulnerable dependency. The SBOM surfaces that; SLSA doesn't. Conversely, an SBOM generated from a compromised build is itself untrustworthy without provenance to corroborate its lineage. The two instruments aren't redundant. They're load-bearing in different places.

Both are only as reliable as the pipeline that produces them. Provenance and SBOM generation embedded from the beginning of the development workflow, rather than attached at release, preserves the chain of custody that makes them meaningful. Bolting either on at the end of the pipeline breaks that chain and undercuts the assurance both are meant to provide.

SLSA provenance now covers Helm charts, JAR and WAR files, and standalone binaries in addition to container images, per Harness's April 2026 release notes. Organizations that ship more than Docker images no longer face the artifact-type gap that once forced different assurance standards onto different parts of the same release process.

What the v1.2 Source Track Adds and Where the Build Track Is Heading

The Source track answers a question the Build track was never designed to address: how do we know this source code is what the organization intended? The Build track assumes trusted source as its starting point. The Source track audits that assumption directly, focusing on change management, specifically how code enters a repository, how it reaches protected branches, and whether that history is retained and tamper-protected.

Promoted from experimental to approved in v1.2 in November 2025, the Source track introduces requirements for source history retention, continuous tamper protection on repositories, and its own Verification Summary Attestations. These sit upstream of build-level attestations, establishing confidence in the code before the build begins.

The relevance is concrete. The 2025 npm attack succeeded partly through GitHub Actions misconfiguration and OIDC token theft. The attack vector was the source and CI configuration, not the compiled artifact. Build track provenance was technically accurate; the source feeding it was compromised. The Source track is designed to close exactly that gap, and organizations that have deployed L2 or L3 build controls without addressing source integrity have a meaningful exposure that isn't visible anywhere in their provenance metadata.

Future Build L4, not yet in the specification, is expected to require pinned dependencies for every build, full hermeticity at build time, a complete listing of all dependencies in provenance to enable recursive SLSA verification across the dependency graph, and reproducible builds that allow other platforms to independently corroborate provenance. Each requirement extends the trust boundary further upstream and further into the dependency chain.

Build L2 is becoming table stakes. Registries and platforms are enabling it by default. The differentiation question is shifting toward whether organizations build the verification discipline to match their generation capability, whether they extend Source track controls to their repositories, and whether they enforce provenance rigor in development environments as consistently as they're beginning to enforce it in CI pipelines.

Consistent, reproducible build environments across developer machines and CI systems are a prerequisite for reliable provenance. When different developers or CI runners carry subtly different tooling, provenance claims are weakened by drift that goes undetected until it matters. Dependency management and reproducibility at the environment level, not just the artifact level, separates organizations that find L3 tractable from those that find it perpetually deferred. Build L4, when it arrives, will expose that deferred work immediately.