Category: Software Supply Chain
Supply-chain Levels for Software Artifacts
Also known as: SLSA, salsa, SLSA framework
Simply put
SLSA (pronounced 'salsa') is a security framework made up of standards and controls designed to protect software supply chains from tampering, vulnerabilities, and targeted attacks. It provides incrementally adoptable levels, allowing organizations to improve their software supply chain security posture in stages. The framework gives practitioners a common language for discussing and measuring supply chain integrity from source code to deployed service.
Formal definition
SLSA is an incrementally adoptable, industry-established security framework consisting of a checklist of standards and controls targeting the software delivery supply chain. It addresses integrity and tamper-resistance across the full software lifecycle, from source through build to package distribution. The framework defines tiered levels of assurance, enabling organizations to adopt controls progressively rather than requiring full conformance immediately. SLSA is maintained under the Open Source Security Foundation (OpenSSF) and is intended to establish a common vocabulary and measurable criteria for supply chain security guarantees.
Why it matters
Software supply chain attacks have become a significant and growing threat vector, targeting the processes and infrastructure used to build and distribute software rather than the end applications themselves. When an attacker compromises a build system, a source repository, or a package distribution channel, they can introduce malicious code that propagates to every downstream consumer without any visible change to the original source. The SolarWinds attack demonstrated how a compromised build pipeline could be used to distribute backdoored software to thousands of organizations, illustrating that securing only the application code is insufficient if the delivery infrastructure itself is vulnerable.
Who it's relevant to
Software Engineers and Developers
Developers benefit from SLSA guidance when establishing or evaluating build pipelines, as the framework provides concrete, incremental requirements for source control hygiene and build scripting. Adopting SLSA controls helps developers ensure their build processes are auditable and resistant to tampering.
DevOps and Platform Engineers
Platform and DevOps engineers responsible for CI/CD infrastructure are the primary implementers of SLSA controls. The framework's requirements around build environment isolation, provenance generation, and artifact signing typically fall within this team's scope of responsibility.
Security Engineers and AppSec Teams
Security teams can use SLSA as a common vocabulary and measurable benchmark for assessing and communicating the supply chain security posture of internal and third-party software. The tiered structure allows security practitioners to prioritize improvements incrementally rather than requiring immediate full conformance.
Open Source Maintainers
Maintainers of open source projects are directly relevant to SLSA adoption because their packages are frequently consumed by downstream organizations. Producing SLSA-conformant artifacts with signed provenance gives consumers greater confidence that published packages have not been tampered with between source commit and distribution.
Risk and Compliance Teams
For teams responsible for vendor risk management and software procurement, SLSA offers a structured way to evaluate the supply chain security maturity of software suppliers. The framework's defined levels provide a basis for comparing assurance claims across different vendors or projects.
Inside SLSA
Levels (SLSA 1 through 4)
A tiered progression of increasingly rigorous supply chain security requirements, where each level builds on the previous one. Higher levels provide stronger guarantees about build integrity and provenance authenticity, with SLSA 4 representing the most comprehensive set of controls currently defined.
Provenance
Verifiable metadata describing how, when, and by whom a software artifact was built. Provenance records typically include the build system identity, input sources, build parameters, and the resulting artifact digest, enabling consumers to audit the artifact's origins.
Build Integrity Requirements
Controls specifying that builds must be performed by a designated build system, that the build process must be isolated from developer influence at runtime, and that the build environment must be ephemeral and hermetic at higher levels. These requirements are intended to prevent tampering during the build phase.
Source Requirements
Expectations around version control, including that all source changes are tracked, reviewed, and retained in a way that supports auditability. Higher SLSA levels may require two-party review of source changes before they influence a build.
Artifact Integrity Verification
Mechanisms such as cryptographic digests and signatures that allow downstream consumers to confirm that an artifact has not been modified after it was produced. SLSA uses these to link provenance claims to specific artifact versions.
Threats Addressed
A defined set of supply chain attack scenarios that SLSA levels are designed to mitigate, including compromised source repositories, tampered build processes, use of compromised dependencies, and distribution of modified artifacts. Each level maps to specific threat mitigations.
Trust Boundaries
Explicit delineation of which actors and systems are trusted at each stage of the software supply chain, including source control systems, build platforms, and artifact repositories. SLSA requirements are scoped to these boundaries.
Common questions
Answers to the questions practitioners most commonly ask about SLSA.
Does achieving a higher SLSA level mean my software is secure?
No. SLSA levels attest to the integrity and provenance of the build process, not to the security of the software itself. A high SLSA level confirms that artifacts were built in a verifiable, tamper-resistant manner and that provenance records are accurate, but it does not evaluate code quality, vulnerability presence, or runtime security posture. Separate controls such as static analysis, dependency scanning, and penetration testing address those concerns.
Can I reach SLSA Level 4 by simply adding provenance metadata to my existing pipeline?
No. Higher SLSA levels require structural changes to the build environment itself, not just the addition of metadata. Level 3 and above typically require a hardened, isolated build platform where the build service generates and signs provenance in a way that the build process itself cannot tamper with. Retrofitting metadata generation onto an existing pipeline without those environmental controls does not satisfy the requirements.
Where should I start if my organization wants to adopt SLSA?
Most organizations begin at SLSA Level 1, which requires generating provenance for builds. This establishes the documentation baseline and creates organizational familiarity with provenance concepts before undertaking the more significant infrastructure changes required for Levels 2 and 3. Auditing existing pipelines to identify where provenance is absent or unverified is a practical first step.
How does SLSA interact with artifact signing standards such as Sigstore?
SLSA defines what provenance must contain and what build environment properties are required, while tools such as Sigstore provide the cryptographic signing and transparency log infrastructure used to generate and verify that provenance. They are complementary: SLSA sets the policy requirements, and signing infrastructure provides the technical mechanism for producing tamper-evident attestations that satisfy those requirements.
Do SLSA requirements apply to third-party dependencies, or only to artifacts my organization builds directly?
SLSA requirements, as applied to a given build, typically govern the artifacts that build process produces. Verifying the SLSA level of upstream dependencies requires separately obtaining and validating their provenance attestations. Organizations that want end-to-end supply chain integrity must therefore verify provenance for consumed dependencies in addition to attesting to their own build processes.
How should teams handle the provenance verification step in a consumer workflow?
Consumers should retrieve the signed provenance attestation alongside the artifact, verify the signature against a known trusted key or transparency log entry, and then evaluate whether the attested build properties meet their policy requirements before using the artifact. This verification step is typically integrated into the deployment pipeline or artifact intake process rather than performed manually, and the specific verification tooling will depend on the provenance format and signing infrastructure in use.
Common misconceptions
Achieving a high SLSA level means a software artifact is secure or free of vulnerabilities.
SLSA levels address supply chain integrity, specifically whether an artifact was built from the claimed source without tampering. They do not assess the security quality of the source code itself, the presence of known vulnerabilities in dependencies, or runtime security posture. A SLSA 4 artifact may still contain serious software vulnerabilities.
SLSA compliance is binary and can be claimed for an entire organization or product portfolio at once.
SLSA levels are applied per artifact or per build pipeline, not to an organization as a whole. Different components within the same product may satisfy different SLSA levels depending on their individual build and source control configurations.
Generating provenance alone is sufficient to satisfy SLSA requirements at a given level.
Provenance generation is one component of SLSA, but each level also requires specific controls around the build environment, source integrity, and in higher levels, the authenticity and non-forgability of the provenance itself. Provenance that can be forged by a developer or build operator does not meet the guarantees SLSA is designed to provide.
Best practices
Evaluate each build pipeline independently against SLSA level requirements rather than applying a single organizational claim, since pipeline configurations typically vary across teams and artifact types.
Begin with SLSA level 1 to establish provenance generation and create visibility into build origins, then incrementally adopt higher levels as build infrastructure matures and tooling supports stronger guarantees.
Verify provenance metadata for third-party artifacts your builds consume, not only for artifacts your organization produces, since upstream dependencies may introduce integrity risks regardless of your own SLSA posture.
Integrate provenance verification into your artifact ingestion workflows and CI/CD pipelines so that artifacts failing provenance checks are rejected before they reach downstream build or deployment stages.
Use build platforms that provide native SLSA provenance generation with non-forgeable attestations, such as those where the provenance is generated by the build service itself rather than by scripts under developer control.
Maintain documentation mapping each artifact and pipeline to its current SLSA level, including known gaps relative to the next level, to support prioritization of remediation efforts and to provide accurate claims to downstream consumers.