SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is an open security framework that grades how trustworthy the build process behind a software artifact is. It defines a checklist of controls, organized into ascending levels, that let a producer prove — and a consumer verify — that an artifact was built the way it claims, from the source it claims, without tampering along the way. Maintained by the Open Source Security Foundation (OpenSSF) under the Linux Foundation, SLSA reached its stable v1.0 specification in April 2023 and has become the common vocabulary teams use to describe build integrity.
Why It Matters
Most high-profile supply chain attacks do not break the source code — they break the build. In the SolarWinds Orion incident, attackers compromised the build system and slipped malicious code into an update that was then legitimately signed and shipped to thousands of organizations. Inspecting the source repository would not have caught it, because the source was clean; the corruption happened between commit and release.
SLSA exists to close exactly that gap. It shifts the question from "do I trust this code?" to "can I prove this artifact came from that code, built by that system, with nothing injected in between?" As regulators lean harder on build integrity — the US Executive Order on cybersecurity and NIST's Secure Software Development Framework both point at provenance — SLSA gives organizations a concrete, gradeable target instead of a vague aspiration.
How It Works
SLSA is organized into tracks, each focused on one part of the supply chain. The Build track is the ratified, widely adopted track in v1.0; a Source track is under active development for later releases. Within a track, higher levels demand stronger, harder-to-forge guarantees.
The central artifact is provenance: signed, machine-readable metadata describing how the artifact was produced — which source commit, which build platform, which parameters. At lower levels provenance simply exists; at higher levels it becomes progressively harder to fake, because the build platform generates and signs it in an isolated environment the build steps cannot influence.
A consumer then verifies that provenance against expectations: that it came from the expected source repository, was produced by an expected builder identity, and is cryptographically intact. Verification is what turns provenance from a nice document into an enforced control.
The Build Track Levels
| Level | Core requirement | What it protects against |
|---|---|---|
| Build L0 | No guarantees; no provenance required | Nothing — baseline for unmeasured builds |
| Build L1 | Provenance is generated automatically and describes how the artifact was built | Mistakes and undocumented, ad hoc builds |
| Build L2 | Build runs on a hosted platform that generates and signs provenance | Tampering with the artifact after the build |
| Build L3 | Build runs in isolated, ephemeral environments; signing keys are unforgeable and hidden from build steps | Tampering during the build and provenance forgery |
The jump from L2 to L3 is the meaningful one for security teams: L3 requires that user-defined build steps cannot reach the signing key or influence other builds, which is what makes the provenance genuinely non-falsifiable rather than merely present.
Best Practices
- Start at L1 quickly, then climb. Emitting provenance from your existing CI is a low-effort first step that immediately improves visibility. Treat L1 as table stakes and plan the path to L3 for critical artifacts.
- Use a hosted, managed build platform. Reaching L2 and L3 is far easier on a platform that generates and signs provenance for you and isolates the signing material — rather than bolting signing onto a self-managed runner.
- Sign provenance with keyless identity. Pairing SLSA with Sigstore lets you bind provenance to a workload identity without managing long-lived keys.
- Verify at consumption, not just production. Provenance you never check is documentation, not a control. Enforce a policy that rejects artifacts whose provenance fails to match the expected source and builder.
- Pin and record dependencies. Provenance is most useful when the inputs it records are themselves pinned, so a rebuild is reproducible and auditable.
How Safeguard Helps
Safeguard treats SLSA provenance as a first-class signal, not an afterthought. When your builds emit provenance, Safeguard ingests and verifies it as part of the artifact's risk picture — confirming the artifact traces back to the expected source and builder before it is trusted downstream. Provenance and build metadata sit alongside the component inventory in SBOM Studio, so "what is in this artifact" and "how was it built" live in one place instead of two disconnected tools.
The Safeguard CLI fits into CI to generate and check attestations at build time, making an L1-to-L3 progression a pipeline configuration change rather than a re-architecture. And Griffin AI, Safeguard's analysis engine, correlates provenance gaps with vulnerability and reachability findings, so a missing or unverifiable provenance record on a critical service surfaces as a prioritized risk rather than a silent omission. For related build-integrity concepts, see our concepts library.
Create a free account to start verifying build provenance, or read the documentation to see how SLSA verification fits into your pipeline.
Frequently Asked Questions
Is SLSA a certification you can be awarded? No. SLSA is a framework and a self-assessed or tool-verified target, not a certification with an official issuing body. An artifact "is at Build L3" because its provenance demonstrably meets the L3 requirements, which any consumer can verify independently — there is no certificate to hang on the wall, and the grade applies per artifact rather than to a whole company.
What happened to the old SLSA levels 1 through 4? The v0.1 draft used four numbered levels. The stable v1.0 specification reorganized the framework into tracks and renamed the build-focused grades to Build L0 through L3. The former Level 4 requirements, such as hermetic and reproducible builds, were deferred to future work rather than mapped one-to-one, so "SLSA 4" no longer refers to a current requirement.
Does SLSA replace an SBOM? No — they answer different questions and work best together. An SBOM lists the components inside an artifact, while SLSA provenance attests to how that artifact was built and where it came from. A complete picture pairs the component inventory from an SBOM with the build integrity guarantees from SLSA.
Which SLSA level should my team target? Aim for Build L1 across everything as a fast baseline, then prioritize Build L3 for artifacts that ship to customers or run in sensitive environments. L3 delivers the strongest guarantee because it makes provenance forgery impractical, but it requires an isolated, hosted build platform, so it is worth the investment on your highest-risk artifacts first.