Would you be able to prove how your software was built – from what source, on what infrastructure, under what controls – if a customer asked? The Supply-chain Levels for Software Artifacts (SLSA, pronounced "salsa") framework is a structured answer to that problem.
SLSA is a security framework built around two fundamental questions: can you prove what built your software, and can you prove what source it came from? It answers both through a series of levels, each adding stronger guarantees around provenance, signing, and build or source controls.
SLSA is a technical standard for producing verifiable evidence that your software is what you say it is, not a compliance checkbox.
A cross-industry consortium led by Google, in collaboration with the Open Source Security Foundation (OpenSSF) and the Linux Foundation, introduced SLSA in 2021. They built it in direct response to high-profile software supply chain attacks that exposed critical infrastructure vulnerabilities. The SolarWinds compromise, Codecov Bash Uploader breach, and Linux hypocrite commits all shared a common pattern: attackers tampered with build processes or injected malicious code into trusted software without detection.
The consortium designed SLSA to establish a standardized framework for securing the software supply chain based on real-world threats and security gaps. Since its initial release, SLSA has evolved significantly, particularly with the formalization of its track-based level structure. As a vendor-neutral framework, it is an increasingly common benchmark for software supply chain security compliance, mapping closely to requirements in regulations like the EU Cyber Resilience Act (CRA), the Digital Operational Resilience Act (DORA), and the Federal Risk and Authorization Management Program (FedRAMP).
SLSA is progressive in that it defines a series of levels of increasing supply chain security guarantees. Version 0.1 defined four conformance levels across three domains: build, source, and dependencies.
Version 1.0 revised that approach, splitting evaluation into separate tracks for each domain. Teams can measure and advance progress on one security dimension without being blocked by another. The current version, SLSA 1.2, formalizes both the build track and the source track, which together address the integrity of how software is built and where it originates.
The build track focuses on the provenance of an artifact, the verifiable evidence of how, where, and by whom it was built. The build track has four levels:
SLSA Build Level 1 requires builds to produce provenance metadata, which includes details on what was built, how, by whom, and on what platform. This doesn't guard against tampering, but it introduces transparency that is frequently lacking today. With provenance in place, you can reduce the risk of release errors and give your teams a working inventory of software components and build platforms.
You can configure most CI/CD systems to generate provenance in standard formats such as SPDX or CycloneDX. This improves accountability and visibility without heavy overhead, making it the practical starting point for SLSA compliance.
Cloud-native systems support Level 1 by automatically storing and serving artifacts with attached metadata and provenance, providing the required visibility into what was built and how.
Level 2 advances software supply chain security by requiring builds to run on trusted, dedicated infrastructure platforms like Google Cloud Build or GitHub Actions rather than a developer's local machine. This deters casual tampering and mitigates risk from insider threats or attackers who face legal or financial consequences. The build platform digitally signs the provenance and ties it to the infrastructure, so artifacts are harder to fake or manipulate without a traceable, intentional attack.
To meet Level 2, the organization must use a hosted build system that automatically generates and signs provenance. Downstream consumers must also verify the authenticity of that provenance. Level 2 pushes teams toward more secure, auditable build platforms and strengthens release integrity at scale.
Cloud-native artifact management platforms offer hosted build environments that generate signed provenance and ensure artifacts are stored securely, verified on upload, and distributed globally. Integrations with CI/CD tools like CircleCI, GitHub Actions, and Google Cloud Build are straightforward.
Level 3 runs the build process in a hardened, isolated environment, like a dedicated container or virtual machine, where no other build process can interfere and signing material is strictly protected. Provenance cannot be forged or bypassed without a serious exploit, which blocks the vast majority of adversaries, including those operating with compromised credentials.
Level 3 requires a secure build environment with strict process isolation and protected signing material. A cloud-native artifact management platform supports this by enforcing build isolation, working with established hardened CI systems, and securely storing signed provenance.
The build track tells you how an artifact was built. The source track tells you where the code came from and whether the process that produced it can be trusted. SLSA 1.2 formalizes the source track as a standalone progression with four levels, each adding stronger guarantees about version control, history integrity, enforced controls, and code review.
Together, the build and source tracks address the integrity picture end to end: was this code reviewed and controlled before it was built, and was the build itself trustworthy?
Where does your organization stand on the SLSA scale? Find out which SLSA level you're operating at and how that maps to frameworks like CRA, DORA, and FedRAMP. Take the free Security Maturity Assessment to benchmark your software supply chain in a few minutes.
Achieving SLSA compliance requires strong provenance, integrity guarantees, and a secure, verifiable software supply chain. While cloud-native registries inherently align with these requirements, self-managed or on-premises registries introduce risks that may compromise compliance – especially at SLSA Build Level 2, which mandates a separation between CI/CD and artifact distribution.
Cloud-native artifact management platforms offer several advantages that directly support SLSA compliance:
Choosing a cloud-native registry directly simplifies and strengthens SLSA compliance by leveraging built-in capabilities around reproducibility, integrity, and security.
Attempting to achieve SLSA compliance with on-premises or bespoke solutions introduces significant challenges that compound as you move up the levels:
That last point is the most consequential failing because it directly undermines SLSA Build Level 2's requirement for separation between CI/CD and artifact distribution. A hosted environment solves what the framework treats as a minimum requirement.
