SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a security framework that defines four levels of build integrity controls to prevent tampering with source code, build pipelines, and released artifacts. Google created it internally in 2019 after studying supply chain compromises, then donated it to the Open Source Security Foundation (OpenSSF) in 2021. Version 1.0 shipped on April 19, 2023, consolidating four ad hoc levels into three tiered requirements (Build L1–L3) plus a separate Source track. The framework exists because attacks like the SolarWinds Orion compromise (December 2020, ~18,000 customers affected) and the Codecov Bash Uploader breach (2021) didn't exploit application vulnerabilities — they exploited unverified build and distribution pipelines. SLSA gives security teams a checklist to close exactly that gap, with each level mapping to specific, auditable controls rather than vague best practices.
What Does SLSA Actually Require at Each Level?
SLSA defines three build levels, and each one adds a concrete, verifiable control on top of the last. Build L1 requires only that you generate provenance — a signed record of how an artifact was built, including the source commit, builder identity, and build parameters — even if that provenance isn't yet enforced. Build L2 requires the build to run on a hosted, shared build service (like GitHub Actions or Google Cloud Build) that generates provenance automatically and signs it, so a compromised developer laptop can't forge the record. Build L3 requires the build platform itself to be hardened against tampering: builds must run in ephemeral, isolated environments with no way for one build to influence another, and provenance must be non-forgeable even by someone with control of the build service's config files. A hypothetical old Level 4 (two-person review of every change) was dropped in v1.0 because it proved impractical to verify at scale; it now lives as guidance rather than a required tier.
How Is SLSA Different From an SBOM or the NIST SSDF?
SLSA and SBOMs answer different questions — SLSA proves how something was built, while an SBOM lists what is inside it. A Software Bill of Materials (required for federal software vendors under Executive Order 14028 and NTIA's 2021 minimum elements guidance) is a component inventory: it tells you that a container image includes OpenSSL 3.0.7 or log4j-core 2.14.1. SLSA provenance is a separate, cryptographically signed attestation that says which commit, which builder, and which pipeline produced that container image in the first place. NIST's Secure Software Development Framework (SSDF, SP 800-218, February 2022) is broader still — a set of ~42 practices covering secure design, coding, and testing — and treats SLSA as one implementation path for its provenance-related practices (PW.4, PS.3). In practice, mature programs run all three together: SBOM for component visibility, SLSA for build integrity, SSDF for overall process governance.
Who Is Actually Requiring or Producing SLSA Provenance Today?
Real ecosystems have already built SLSA into their default publishing flow, not just their documentation. npm added native support for npm publish --provenance in April 2023, and as of 2024 it's the default recommendation for any package published from GitHub Actions with OIDC — Sigstore-signed provenance now appears on the npm registry page for adopting packages. PyPI shipped its own attestations feature (built on the same in-toto/Sigstore stack SLSA specifies) in 2023, following the same pattern after incidents like the ctx and phpass typosquatting campaigns. GitHub shipped Artifact Attestations as a generally available feature in June 2024, letting any Actions workflow emit SLSA Build L2/L3-equivalent provenance with a single actions/attest-build-provenance step. Google requires SLSA L3 for internal production deployments and open-sourced its own builder, slsa-github-generator, so any public repo can reach the same bar without hand-rolling attestation logic.
Would SLSA Have Stopped an Attack Like XZ Utils or SolarWinds?
SLSA would likely have caught SolarWinds-style build tampering but not the XZ Utils backdoor, because the two attacks targeted different layers. In the SolarWinds case, attackers modified the Orion build process itself to inject malicious code (SUNBURST) during compilation — exactly the scenario Build L3's isolated, tamper-resistant build environments are designed to prevent, since provenance would either fail to generate or fail to match the expected source commit. The XZ Utils backdoor (CVE-2024-3094, discovered March 29, 2024) is a harder case: a trusted, years-long contributor added malicious code through normal, authorized commits and a hand-crafted release tarball that didn't match the git source. Because the attacker was the legitimate maintainer with commit access, build-integrity provenance alone wouldn't have flagged it — this is precisely why SLSA's Source track (covering commit review, branch protection, and two-person control) is being developed as a companion to the Build track, and why it can't substitute for source-level review and anomaly detection.
How Do You Actually Implement SLSA in an Existing CI/CD Pipeline?
You implement SLSA by moving artifact builds off developer machines and onto a provenance-generating, access-controlled build service, then verifying that provenance before deployment. Concretely, that means: (1) migrating build/release jobs to a supported generator — GitHub's slsa-github-generator for Actions, or GitLab's built-in attestation support since GitLab 16 — instead of a maintainer running docker build && docker push from a laptop; (2) configuring the pipeline to sign provenance with Sigstore/cosign rather than a long-lived private key, since SLSA L3 explicitly requires non-forgeable, keyless-where-possible signing; and (3) adding a verification gate — using slsa-verifier or an admission controller policy — that rejects any artifact whose provenance doesn't match the expected source repo, branch, and builder identity before it reaches a registry or cluster. Most teams reach Build L2 within a single sprint since it mainly requires switching to a hosted CI runner; reaching L3 typically requires re-architecting build jobs to be fully isolated and non-configurable by individual pipeline authors.
How Safeguard Helps
SLSA provenance tells you an artifact was built the way it claims to have been built — it doesn't tell you whether that artifact is actually exploitable in your environment, which is where Safeguard closes the gap. Safeguard ingests and generates SBOMs alongside SLSA provenance attestations, then runs reachability analysis to determine which flagged components are actually reachable from your application's entry points rather than sitting in dead code paths. Griffin AI correlates that reachability data with build provenance to prioritize the small subset of findings that represent real risk, cutting through the noise that pure compliance-checklist tools produce. When Safeguard identifies a vulnerable or unattested dependency, it opens an auto-fix pull request with the corrected version and updated lockfile, so remediation doesn't stall in a backlog. Together, this turns SLSA from a static compliance artifact into an actively enforced, continuously verified part of your supply chain security posture.