SLSA Framework Levels and Their Compliance Implications

Each SLSA Build Level imposes a specific, additive set of technical controls, from basic provenance generation to hermetic, isolated builds, and understanding what each level demands operationally is the most useful guide for teams plotting a compliance path and justifying the investment to stakeholders.

Build integrity attacks as the dominant supply chain threat

SolarWinds (2020) showed malicious updates reaching over 18,000 organizations including U.S. agencies, subverting the build or release path rather than the application code itself trantorinc.com. JetBrains, the same year, demonstrated a related failure mode, where compromise of a CI/CD server handed attackers administrative access to everything downstream trantorinc.com. Neither incident involved a vulnerability in the software being shipped. Both involved the pipeline that built and shipped it.

The pattern didn't stop in 2020 trantorinc.com. The XZ Utils backdoor, discovered in 2024 and tracked as CVE-2024-3094, and the keyv/cacheable npm worm (tracked as keyv-shai-hulud) active August 4, 2026, both slipped past component-level checks by subverting the build or publishing path rather than the source code a reviewer would actually read. That's the throughline: scanning what's inside a package doesn't catch an attacker who has quietly taken over how the package gets made.

The scale backs up the urgency. Software supply chain attacks more than doubled globally in 2025, and over 70 percent of organizations reported at least one incident tied to third-party software that year trantorinc.com activestate.com. Global costs from these attacks reached $60 billion, with projections putting that figure at $138 billion by 2031 trantorinc.com activestate.com. Perimeter defenses and code scanners weren't built to catch a compromised build server signing off on tampered output as if nothing happened. Closing that specific gap, between commit and shipped artifact, is what SLSA was built to do.

SLSA and the Problem It Was Designed to Solve

SLSA, pronounced "salsa," stands for Supply-chain Levels for Software Artifacts.

That's a meaningful distinction. A checklist gets initialed and filed away. Metadata that a policy engine can check at deploy time either matches expectations or it doesn't, and there's no room for a well-meaning auditor to wave it through anyway.

SLSA is also deliberately tool-agnostic: organizations adopt its requirements with whatever CI/CD tooling and workflows they already run, rather than adopting a specific prescribed platform. The current stable version is SLSA v1.2, released in November 2025, with v1.1 having held the stable designation as of April 2025 trantorinc.com. The Build Track remains the primary, fully defined track, and as of v1.2 the Source Track specifications have also reached full approval trantorinc.com.

SLSA is not an SBOM: SLSA answers how the software was built, while an SBOM answers what is inside it (related but distinct concepts, both valuable). They're related, and both worth having, but they answer different questions.

Why provenance is the foundation of every SLSA level

Every SLSA level, from the most minimal to the most demanding, rests on one artifact: provenance. A SLSA provenance attestation is a signed document that records the source repository and exact commit, the identity of the build platform and builder, the build command or configuration that was invoked, the dependencies resolved during the build, and the artifact that came out the other end. Put together, that record lets a consumer check that what they received matches what was supposed to have been built, from the source that was supposed to have been used.

Even unsigned, provenance carries real value. At the lowest maturity level, it establishes traceability and prevents dumb, costly errors, like shipping the wrong build to production, even though it can't detect tampering that happens after the record is generated. Signing is what changes that equation. Once provenance is cryptographically signed, altering it after the fact invalidates the signature. Tampering becomes detectable rather than invisible.

SLSA is not, precisely, what it might be mistaken for. An SBOM, typically in SPDX or CycloneDX format, is a machine-readable inventory of components used for vulnerability management and license compliance. SLSA doesn't require SBOM generation at any level. Provenance also needs somewhere to live: the recommended practice is storing it alongside the artifact, in a package registry such as GitHub Releases, PyPI, or an OCI registry, or in a transparency log like Rekor. Producers must publish in at least one such location and should publish in more than one. Higher SLSA levels increase confidence that a generated SBOM is accurate and untampered, and SLSA L3 with reproducible builds provides the strongest such assurance.

SLSA Build Level 1 requirements and limitations

Nobody should be citing L0 as a compliance posture, since L1 establishes a provenance foundation teams can build on and is a meaningful improvement over L0 even if the guarantee is limited (per JFrog). It's a starting line, not a level.

Operationally, this means the build process has to be fully scripted or automated. A hosted CI/CD tool, such as GitHub Actions, can satisfy this level by generating release metadata automatically as part of a fully scripted or automated build process. That provenance captures the source repository, the commit hash, resolved dependencies, the build command, and a cryptographic digest of the output.

What it doesn't do matters just as much. L1 provenance is unsigned, so an attacker who alters the metadata after it's generated leaves no detectable trace behind. L1 simply assumes the build platform can be trusted, without any mechanism to verify that trust. Still, L1 delivers real value. It establishes a provenance foundation that later levels build on top of, and it's a meaningful step up from having no record at all. The operational lift is genuinely low, mostly a matter of automating builds that may already be semi-automated and wiring in provenance generation, without standing up any new infrastructure beyond a standard hosted CI system. For stakeholders asking what L1 buys them, the honest answer is: repeatable, documented builds that support basic audit and incident-response needs, and not much more. As a prerequisite baseline, Level 0 means no SLSA implemented and no provenance, appropriate only when development or test builds, such as unit tests, are built and run on the same machine.

SLSA Build Level 2 as the Practical Target for Most Teams

Signing addresses tampering that unsigned provenance (L1) cannot detect, since L1 establishes traceability and prevents errors such as releasing the wrong version but cannot detect post-generation tampering. If provenance gets modified after it's signed, the signature breaks and the tampering becomes visible.

L2 also requires a real infrastructure change: builds have to run on a hosted, dedicated build platform, not a developer's laptop. That separation between the CI/CD system and artifact distribution is the mandate at the heart of L2. Pairing this with version control practices, enforced code review and commit signing, supports the traceability L2 is asking for.

L2 isn't the finish line, though. It still doesn't touch risks that occur during the build itself: compromised credentials, a shared build environment, or insider access to the runner can all introduce malicious changes without ever invalidating the signed provenance that comes out. Even so, L2 is where most teams should be aiming first. It meaningfully narrows the attack surface and raises the cost of evading detection, at an implementation cost that's proportionate for most commercial and open-source projects. It's also the level that translates cleanly into a stakeholder conversation: signed provenance is evidence attached directly to the artifact, something that can be shown to a customer, an auditor, or a procurement reviewer without a lot of extra explanation. Dependency hygiene tends to travel alongside L2 work, and it should: pinning dependency versions instead of trusting version ranges, and routing package pulls through a private registry that mirrors approved packages rather than pulling straight from the public internet.

Which environments genuinely need what SLSA Build Level 3 demands

Level 3 introduces three distinct control families. Build isolation means every build runs in an ephemeral environment, walled off from other processes, so that runs can't influence one another even inside the same project. Secret protection means the credentials used to sign provenance are kept out of reach of user-defined build steps, so a build script has no path to access or misuse the signing keys. A hardened build platform rounds it out: controls that establish real confidence a package came from the official source and the official build process, making forged provenance extremely difficult to produce.

Isolation specifically prevents a compromised build from affecting another build in the same system, and prevents insider threats or compromised credentials from injecting changes without detection. Reproducible builds are one of the mechanisms L3 leans on to get there, since identical inputs producing identical outputs gives independent parties a way to verify a build without trusting the original builder's word for it.

None of this makes L3 a complete answer to software risk. It says nothing about dependency composition risk, vulnerabilities sitting in source code, or how an artifact behaves at runtime, all of which sit outside its scope. So who actually needs it? High-security environments (government, critical infrastructure, financial services under DORA, medical device manufacturers under FDA 524B) and projects with contractual or regulatory requirements for non-falsifiable provenance. That non-falsifiable record isn't just a technical nicety, either: in the middle of an incident response or a legal dispute, it narrows how much deniability is even available to argue. The cost of getting there is real too: ephemeral environments, secret management infrastructure, and platform hardening all take genuine engineering time, and stakeholders deserve that stated rather than glossed over. SLSA L3 provides the highest degree of confidence, within the current Build Track, that a generated artifact's provenance is authentic and untampered, but it does not directly address the precision or accuracy of a generated SBOM.

The regulatory landscape mapped onto SLSA levels and its compliance deadlines

FDA Section 524B has applied to manufacturers of cyber devices since March 29, 2023, requiring an SBOM as part of premarket submissions, and SLSA provenance strengthens the basis for trusting that SBOM in the first place.

DORA took effect on January 17, 2025, strengthening operational resilience and third-party risk expectations for financial services and financial-sector ICT dependencies in the EU. The Cyber Resilience Act's reporting requirements land on September 11, 2026, for manufacturers of any product with digital elements, and that date makes traceability and vulnerability handling mandatory rather than aspirational.

NIST SP 800-204D, published in February 2024, addresses build integrity head-on, emphasizing cryptographically signed attestations as a foundational mechanism across CI/CD pipelines, which in SLSA's own vocabulary is squarely L2 and L3 territory. SLSA practices also line up with supply chain risk controls under ISO/IEC 27001, a useful overlap for organizations already operating inside that framework trantorinc.com. Organizations that strengthen provenance and build integrity now end up better positioned for customer reviews, audits, procurement scrutiny, and whatever regulation comes next, regardless of whether SLSA itself is ever named explicitly in a contract. For European manufacturers specifically, the CRA's September 2026 deadline is the closest hard date on the calendar, and it's a genuinely useful anchor when the investment conversation needs a fixed point to argue from. The compliance-and-future-proofing table from Checkmarx serves as the organizing structure, mapping each regulation to geography, sector, and date. EO 14028 and the NIST SSDF apply to U.S. federal software vendors, with the EO dated May 12, 2021 and NIST Section 4e guidance dated February 4, 2022, and SLSA directly supports SSDF practices PS.1 (protect software) and PS.3 (archive and protect each software release). NIS2 covers critical infrastructure, digital services, cloud, data centers, health, energy, transport, manufacturing, and more across the EU as of October 18, 2024, raising the baseline for supply chain oversight.

A realistic compliance path from L0 to L3

Start with an SBOM, not with SLSA itself. Identifying components and dependencies first gives a team an actual inventory to reason about before it starts layering build controls on top. From there, L1 is genuinely the easy part: wire automated provenance generation into a CI/CD pipeline that's probably already mostly automated, and the marginal effort is low relative to the informational payoff.

L2 is where the real infrastructure work begins: move builds onto a dedicated hosted platform, implement cryptographic signing, and enforce version control hygiene, meaning code reviews, signed commits, and restricted repository access. Dependency hardening runs alongside this naturally: pin dependency versions in build files instead of leaving them floating on a range, route package pulls through a private registry, Artifactory, Nexus, or GitHub Packages are all reasonable choices, and integrate software composition analysis tooling to scan at every commit or build.

L3 is a different kind of project. It calls for dedicated engineering investment: ephemeral build environments have to be designed, secrets have to be isolated from build scripts, and the platform itself has to be hardened against forgery.

A common and costly mistake is skipping L1 and L2 to chase L3 directly. Teams that do this tend to stall, because the foundational provenance pipeline that produces L3's guarantees was never actually validated in the first place. The incremental structure of SLSA exists precisely to prevent that failure mode.

Reproducibility deserves particular attention here, because it's often the quiet source of failure. Unpinned transitive dependencies that update silently in the background are a primary cause of environment drift, and that drift undermines the accuracy of provenance even when every other control looks correct on paper. Locking environments declaratively, using tools that manage build environments in a fully reproducible way, ensures the environment recorded in provenance is actually the one that ran, and that it can be reconstructed exactly for independent verification at L3. Onboarding matters too: bringing a new developer or contributor into a SLSA-compliant pipeline should take one command, not several days of manual setup, because compliance controls sitting on top of a fragile, hand-assembled environment are only as durable as that environment is. Provenance should sit alongside artifacts in the repository, and attaching an input-derived build hash to each deployment means a newly discovered CVE can be traced back to specific builds without anyone grepping through logs. As a target: L2 is the realistic near-term goal for most commercial teams, and L3 should be scoped first to the highest-risk pipelines rather than rolled out uniformly across everything at once.

The case for SLSA investment for stakeholders who don't see the urgency

Stakeholders who control budget rarely respond to abstract risk. They respond to dates, dollar figures, and evidence they can hand to someone else. The CRA's September 2026 deadline is the most immediate hard date for European product manufacturers, a useful anchor for investment conversations, and DORA's January 17, 2025 requirements strengthen operational resilience and third-party risk expectations for financial services and financial-sector ICT dependencies in the EU. Neither of these is a hypothetical future obligation. Both already have a clock running.

The cost argument stands on its own too. Supply chain attacks more than doubled globally in 2025, and global losses from them are projected to nearly triple by 2031 trantorinc.com activestate.com. Against that backdrop, the cost of reaching L2, a dedicated build platform and signed provenance, reads less like discretionary spend and more like insurance with a defined, bounded premium. L3's cost is higher and should be presented that way, honestly, scoped to the pipelines where regulatory exposure or contractual obligation actually demands it, rather than sold as a universal upgrade every team needs on day one.

What SLSA ultimately offers a stakeholder conversation is specificity. Not a vague promise of "better security," but a signed, artifact-attached record that can be produced on demand for a customer's security questionnaire, an auditor's request, or a regulator's inquiry. That's a concrete deliverable, and concrete deliverables are what get budget approved.