In December 2020, attackers slipped malicious code into a SolarWinds Orion build server and shipped it to roughly 18,000 customers through a signed, trusted update. The build pipeline itself was the weak link, not any single line of source code. That single incident reshaped how the industry thinks about software supply chain security and gave rise to SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") — a framework for proving that a piece of software was built the way its source code says it was. Google published the first version internally in 2021, donated it to the Open Source Security Foundation (OpenSSF) in 2022, and the community shipped SLSA v1.0 in October 2023. If you are researching "what is SLSA framework" because a customer, auditor, or executive order now requires provenance evidence, this glossary entry breaks down the levels, the problems it solves, and how it compares to the SBOM-centric tooling sold by vendors like Sonatype.
What Is SLSA?
SLSA is a checklist-based framework, not a piece of software, that defines increasing levels of trust for how a software artifact was sourced, built, and packaged. It was created to answer a narrow but critical question: when you download a package, container image, or binary, can you verify it was produced from the exact source you expect, by a build process that wasn't tampered with along the way? SLSA does this through "provenance" — a signed, machine-readable attestation that records the source repository, commit hash, build system, and build steps used to produce an artifact. Unlike a Software Bill of Materials (SBOM), which lists what is inside an artifact, SLSA provenance describes how the artifact came to exist. The current specification, SLSA v1.0, organizes requirements into tracks (starting with the Build track) rather than the single 1-4 ladder used in the earlier draft, but the underlying goal is unchanged: make it possible to detect and reject tampered builds before they reach production.
What Problem Does SLSA Actually Solve?
SLSA solves the problem of build-time tampering, the exact gap that let the SolarWinds and 2021 Codecov Bash Uploader compromises succeed even though the published source code looked clean. In both cases, reviewing the source repository would not have caught the attack, because the malicious behavior was injected after code review and before the artifact was signed and distributed — inside the build pipeline itself. A 2023 Sonatype State of the Software Supply Chain report estimated a roughly 200% year-over-year increase in malicious package attacks targeting open source ecosystems like npm and PyPI, and a large share of those attacks specifically target CI/CD infrastructure, build scripts, and publish credentials rather than source code. SLSA closes that gap by requiring provenance that a verifier can check cryptographically: was this artifact built by the build service it claims, from the commit it claims, using a script that a human or a controlled pipeline actually authored? Without that check, an SBOM alone tells you what components you shipped, but not whether the build that produced them was compromised.
What Are the SLSA Build Levels, Concretely?
SLSA defines four levels of increasing rigor, and reaching Build Level 3 is generally treated as the bar for "trustworthy" automated builds. Build Level 1 only requires that a provenance document exists, describing how the artifact was built, even if that provenance isn't verified or tamper-resistant — it's a starting point, not a security guarantee. Build Level 2 requires the provenance to be generated by a hosted build service and signed, so a compromised developer laptop can't forge it, which is roughly what GitHub Actions with OIDC-based attestations provides out of the box today. Build Level 3 requires the build platform to isolate builds from each other (no shared state between runs) and to prevent even the build service's own operators from tampering with provenance after the fact — this is the level Google's internal Borg-based build systems targeted, and it's the reference point that Google, GitHub, and npm point to when they discuss "SLSA-compliant" pipelines. A hypothetical Build Level 4, which added two-person review of every change, was dropped from the source track scope in v1.0 as the OpenSSF working group narrowed focus to what's practically verifiable at scale.
Who Is Actually Requiring or Producing SLSA Provenance Today?
Adoption moved from theoretical to mandatory in the npm ecosystem starting in April 2023, when npm CLI 9.5.0 added native support for publishing SLSA provenance attestations using Sigstore's keyless signing, and by 2024 tens of thousands of packages, including high-traffic ones like React and Next.js tooling, publish provenance on every release visible directly on the npmjs.com package page. GitHub shipped native "artifact attestations," built on the same SLSA and Sigstore foundations, as a general-availability feature for GitHub Actions in 2024, letting any repository generate build provenance without standing up separate infrastructure. On the regulatory side, the White House's Executive Order 14028 (May 2021) and the subsequent NIST Secure Software Development Framework (SSDF) attestation requirements that took effect for federal software vendors in 2023-2024 don't name SLSA explicitly, but agencies including CISA have pointed to SLSA provenance as one accepted way to demonstrate the build-integrity controls SSDF requires. PyPI's Trusted Publishing rollout, which eliminates long-lived API tokens in favor of short-lived OIDC credentials tied to a specific CI workflow, is a direct building block toward SLSA Build Level 2-3 provenance for the Python ecosystem.
How Does SLSA Differ From an SBOM, and From Sonatype's Approach?
SLSA and SBOMs are complementary, not competing, controls, and the difference matters because Sonatype's product suite (Nexus Repository, Nexus IQ, and its OSS Index vulnerability database) has historically been built around the SBOM and component-composition side of that equation rather than build provenance verification. An SBOM, in formats like CycloneDX or SPDX, answers "what open source components, versions, and licenses are inside this artifact" — it's the ingredient list. SLSA provenance answers "was this artifact actually built from the source and process it claims to be built from" — it's the chain-of-custody record for the factory that made the product. Sonatype's core strength is scanning dependency trees against a component intelligence database (Sonatype's own research team has cataloged well over 550,000 malicious open source packages as of their 2024 reporting) and flagging known-vulnerable or known-malicious components before they enter a build. That's valuable, but it doesn't verify that the build pipeline producing your final artifact wasn't itself tampered with after a clean dependency check passed — which is precisely the SolarWinds and Codecov failure mode. Organizations that rely solely on SBOM-generation-and-scan tooling can pass every component check and still ship a compromised binary if the build step between "dependencies verified" and "artifact signed" isn't independently attested.
Do You Need SBOMs and SLSA Provenance Together?
Yes, and most emerging compliance frameworks now expect both, because each one closes a gap the other leaves open. NIST SP 800-218 (SSDF) and the EU Cyber Resilience Act, which enters phased enforcement starting in 2026 for reporting obligations and 2027 for full compliance, both reference component transparency (SBOMs) and build integrity controls in the same breath rather than treating them as substitutes. A practical way to think about it: an SBOM tells an auditor or downstream consumer what's in an artifact so they can react quickly when a component like Log4j (CVE-2021-44228, disclosed December 2021) turns out to be vulnerable; SLSA provenance tells them whether they can trust that the artifact matching that SBOM was actually produced by the pipeline it claims, rather than by an attacker who modified the build after the SBOM was generated. Vendors that only do one half of this — comprehensive SBOM and vulnerability data without verifiable build provenance, or vice versa — leave customers to stitch the other half together manually, usually across separate tools that don't share a single source of truth for a given release.
How Safeguard Helps
Safeguard treats SLSA provenance and SBOM generation as a single, continuously enforced control rather than two separate reports pulled from different tools. Every build Safeguard observes is automatically evaluated against SLSA Build Level criteria — provenance existence, signed attestation from a hosted build service, and build isolation — and the result is surfaced alongside the CycloneDX/SPDX SBOM for the same artifact, so security and compliance teams see component risk and build-integrity risk in one place instead of reconciling two data sources by hand. For teams already publishing npm or GitHub Actions attestations, Safeguard verifies those signatures automatically and flags any artifact that reaches production without matching provenance — closing exactly the gap that let a clean SBOM ship alongside a tampered build in incidents like SolarWinds. Safeguard also maps SLSA levels and SBOM completeness directly to the frameworks auditors actually ask about — NIST SSDF, the EU Cyber Resilience Act's upcoming reporting deadlines, and SOC 2 change-management criteria — so a single dashboard answers both "what's in this artifact" and "can we prove how it was built," rather than requiring separate tooling for component intelligence and provenance verification the way a Sonatype-plus-manual-attestation stack typically does. For organizations evaluating how to move from SBOM-only visibility to full build-integrity assurance, Safeguard's platform is built to make that the default state of every release, not a one-time audit exercise.