SLSA (Supply-chain Levels for Software Artifacts) is the single most misunderstood framework in the supply chain security space. Teams either dismiss it as bureaucratic paperwork or chase Level 4 compliance as if it were a badge of honor. Both reactions miss the point. Level 3 is where the curve flattens — you get nearly every defensive benefit, you satisfy the federal attestation regime, and you don't need to rearchitect your build system to get there. Level 4 adds hermetic, fully reproducible builds on top, and for the vast majority of organizations the incremental cost outruns the incremental risk reduction by an order of magnitude.
What do the four SLSA levels actually require?
SLSA defines four progressively stricter levels of build integrity, with each level adding specific controls around provenance, isolation, and reproducibility. Level 1 just asks you to document your build process and generate provenance — any automated build that emits a provenance document qualifies. Level 2 adds source and build platform integrity: version-controlled source, a hosted build service, and signed provenance generated by the build platform itself rather than the user.
Level 3 is where things get interesting. The build platform must be hardened, non-forgeable provenance must be generated in an isolated environment, and the user cannot tamper with the provenance. That means a GitHub Actions runner cannot produce an L3 attestation for itself if the workflow can also modify the attestation — the signing has to happen in a trust boundary the workflow can't cross. Level 4 layers on hermetic builds (all dependencies declared and fetched into an isolated environment with no network access during build) and two-person review for all changes. It's the only level that requires reproducible builds as a strong recommendation.
The gap between L2 and L3 is meaningful security. The gap between L3 and L4 is mostly engineering cost.
Why is Level 3 the practical ceiling for most organizations?
Level 3 is the practical ceiling because it closes the attacks that actually happen while L4 defends against theoretical ones most threat models don't include. The attacks that drove SLSA's creation — SolarWinds, Codecov, the 3CX compromise, the Ultralytics PyPI hijack in late 2024 — all involved attacker control of the build environment or the ability to inject code without leaving a verifiable trail. L3's non-forgeable provenance defeats every one of those because the attestation would either fail to verify or would reveal the injected steps.
L4's hermetic build requirement, by contrast, defends against a narrower class: a compromised dependency that reaches out to the network mid-build, or a non-deterministic build that hides a malicious step. Those are real threats, but they're expensive to exploit and they leave traces. Enforcing hermeticity means vendoring every dependency, pinning every toolchain binary by digest, and accepting that any transitive dependency that touches the network breaks your build. For a company shipping a kernel or a cryptographic library, that's worth it. For a team shipping a SaaS product, you're spending six months of platform engineering to defend against an attack that rarely clears the cost-benefit bar.
How widespread is SLSA Level 3 adoption in 2026?
SLSA Level 3 adoption accelerated dramatically once the major CI platforms shipped out-of-the-box support, and as of early 2026 the install base is in the tens of millions of artifacts per month. GitHub's artifact attestations, which produce SLSA v1.0 L3 provenance for any workflow using actions/attest-build-provenance, crossed 50 million attestations issued across public and private repos. npm provenance, which uses the same infrastructure under the hood, now covers roughly 40 percent of the top 1,000 packages by weekly download count — packages like express, react, typescript, and @angular/core all publish signed provenance linking each release back to the exact GitHub Actions workflow that built it.
PyPI's Trusted Publishers feature, launched in 2023 and now backed by PEP 740 attestations, hit similar adoption curves — the cryptography, requests, and numpy projects all ship L3 provenance today. Google's internal build systems have produced L3-equivalent provenance since before SLSA was a public spec, and many Chainguard Images, Red Hat UBI variants, and Bitnami containers now include SLSA attestations in their OCI manifests. The infrastructure is no longer the bottleneck; consumer-side verification is.
What does SLSA Level 3 buy you for compliance?
SLSA Level 3 satisfies the verifiable provenance requirement in CISA's Secure Software Development Attestation Form, which is the instrument agencies use to collect the attestations required by OMB M-22-18 and Executive Order 14028. The form, finalized in 2024 and in active use through 2026, asks whether the producer maintains provenance data for internal and third-party code components. A signed SLSA v1.0 L3 attestation is the cleanest way to answer yes — it's machine-verifiable, it names the builder, it captures the source revision, and it's standardized enough that federal assessors know what they're looking at.
Beyond the federal attestation regime, SLSA L3 maps directly to NIST SSDF practices PS.3.1 (archive and protect each software release) and PS.3.2 (collect, safeguard, and share provenance data). It also satisfies the provenance requirements in the EU Cyber Resilience Act, which starts biting in 2027 for products placed on the EU market. Getting to L3 now means you're not scrambling when auditors start asking for attestations in 2026 procurement cycles — and they already are, in DoD, CISA, and increasingly large enterprise contracts.
When should you actually pursue Level 4?
Pursue Level 4 only if your threat model explicitly includes nation-state-grade adversaries targeting your build toolchain, or if you're shipping software where reproducibility itself is the product. The clearest case is cryptographic libraries and operating system kernels: when Debian, NixOS, and Arch invest in reproducible builds, they're buying the ability to have independent parties verify that the binary matches the source. That's worth the cost because the binary is the trust root for millions of downstream users.
For most product teams, L4 is yak-shaving. You'll spend months converting every curl | sh install script, every dynamically fetched compiler plugin, every go mod download step into a hermetic equivalent. You'll break your build every time a transitive dependency quietly adds a post-install hook. And the residual risk you're eliminating — an attacker who already has code execution in your build environment injecting a non-deterministic payload — is better addressed by tightening L3 controls (minimal runner permissions, scoped OIDC tokens, workflow hardening) than by adding a hermeticity requirement on top.
What are the common failure modes when teams adopt SLSA?
The most common failure mode is generating provenance nobody verifies. Teams wire up actions/attest-build-provenance, check the box, and never configure their admission controllers, registries, or deployment pipelines to actually require and validate the attestation. Provenance that isn't verified is just metadata; the security property only exists at the verification step. Real SLSA deployments close the loop with cosign verify-attestation in CI, policy-as-code (Kyverno, Gatekeeper, or OPA) at cluster admission, and registry-level policy (Harbor, JFrog Xray, Artifactory) that refuses unsigned or L-insufficient images.
The second failure mode is over-indexing on the builder and under-indexing on the source. SLSA L3 says the builder must be trustworthy and the provenance must be non-forgeable, but it doesn't say much about whether the commit the builder pulled was itself authentic. If your GitHub branch protection is weak, an attacker who gets a PR merged will produce a perfectly valid L3 attestation for malicious code. Couple SLSA with signed commits (Sigstore gitsign or GPG), required reviews, and CODEOWNERS enforcement — otherwise you're signing the wrong thing very accurately.
How Safeguard.sh Helps
Safeguard.sh verifies SLSA provenance at ingestion and enforces policy across the artifacts moving through your pipeline. Our SBOM generation and ingestion module parses in-toto attestations alongside CycloneDX and SPDX formats, so an artifact with an L3 provenance statement lands in our graph with its builder, source revision, and workflow identity preserved. Reachability analysis then cuts 60-80% of the CVE noise that would otherwise compete for attention, letting you focus on the vulnerable code paths actually invoked by signed, provenanced artifacts. Griffin AI autonomous remediation takes that filtered set and proposes patches, often against the exact commit hash recorded in the provenance. For teams evaluating third parties, our TPRM module ingests vendor SBOMs and checks whether their release artifacts carry verifiable SLSA attestations, so vendor risk scoring reflects real build integrity rather than self-reported assurances. Add 100-level dependency depth scanning and container self-healing, and you have a verification surface that makes SLSA provenance actionable rather than ornamental.