Cybersecurity glossary
What is Supply-chain Levels for Software Artifacts (SLSA)?
Learn what SLSA is, how the current build levels work, and how SLSA differs from build provenance, artifact signing, and reproducible builds.
Definition
Supply-chain Levels for Software Artifacts (SLSA) is a security framework for improving software supply chain integrity through defined build levels, provenance requirements, and controls that reduce tampering risk.
Why SLSA matters
Software supply chain attacks often succeed before code reaches production: source can be altered, builds can be poisoned, dependencies can be swapped, and release artifacts can be replaced. Consumers need a way to reason about how much protection surrounds the artifact they are about to trust.
SLSA provides a common vocabulary for that assurance. It is not a single tool, signature, or metadata file. It is a framework for raising build integrity from little evidence to hardened, verifiable artifact production.
What SLSA brings together
Provenance
Artifacts carry evidence about source, builder, inputs, and build process.
Trusted builders
Builds move from ad hoc local execution toward controlled hosted platforms.
Isolation
Higher levels require stronger separation so one build cannot corrupt another.
Verification
Consumers can enforce policy based on expected source, builder, and artifact digest.
How teams progress through SLSA build levels
Understand Build L0
At L0, SLSA makes no specific build integrity guarantees; this is the baseline to improve from.
Generate provenance for L1
Emit provenance that identifies the artifact, source, builder, and build invocation.
Use hosted builds for L2
Move builds to a hosted platform that generates provenance and reduces reliance on developer machines.
Harden the build platform for L3
Require stronger isolation, tamper resistance, and controls around how provenance is generated.
Verify at consumption
Check provenance, builder identity, source, and artifact digest before release promotion or deployment.
Extend beyond build
Pair build-level progress with source controls, dependency governance, signing, and monitoring.
SLSA levels and related concepts
| Item | Meaning | Boundary |
|---|---|---|
| Build L0 | No SLSA build guarantees are claimed | Useful as a baseline, not as assurance |
| Build L1 | Provenance exists for the artifact | Provenance alone does not prove a hardened builder |
| Build L2 | A hosted build platform generates provenance | Hosted does not automatically mean strong isolation |
| Build L3 | The build platform is hardened against tampering and cross-build influence | Still needs verification, dependency controls, and secure source practices |
| Reproducible build | Independent rebuilds can match the output | Complementary evidence, not the SLSA level definition |
SLSA implementation checklist
- Inventory release artifacts and decide which ones need SLSA verification first.
- Generate provenance automatically for each release artifact digest.
- Move production builds away from developer laptops and into trusted hosted builders.
- Protect build definitions, workflow files, and release credentials with review requirements.
- Harden runner isolation, ephemeral environments, and provenance generation paths.
- Verify provenance before deployment, not only after an incident.
- Document the SLSA build level claimed for each artifact and what evidence supports it.
- Combine SLSA with artifact signing, SBOMs, VEX, and vulnerability management.
The practical takeaway
Supply-chain Levels for Software Artifacts (SLSA) is a maturity framework for artifact build integrity, not a synonym for provenance, signing, or reproducible builds. Provenance is evidence, signing protects objects, reproducibility verifies outputs, and SLSA organizes build controls into levels.
Use SLSA to make trust claims precise: which artifact, which level, which builder, which provenance, and which verification policy.
Related security terms
Build Provenance
A key evidence artifact used by SLSA verification.
Artifact Signing
A cryptographic control used to protect artifacts and attestations.
Reproducible Build
An independent verification property that complements SLSA controls.
Pipeline Poisoning
A CI/CD attack pattern that SLSA build controls are designed to reduce.
Build Pipeline
The automation where SLSA build-level requirements are implemented.
Frequently asked questions
What is SLSA in simple terms?
SLSA is a framework for making software artifacts harder to tamper with by improving how they are built, documented, and verified.
How many SLSA levels are there?
In the SLSA v1.0 build track, levels are Build L0 through Build L3. Older SLSA drafts used a four-level model ending at L4, but current build-track guidance consolidated requirements into L0-L3.
What does SLSA Build L1 mean?
Build L1 means the artifact has provenance that describes how it was built, giving consumers basic source-to-artifact traceability.
What does SLSA Build L2 add?
Build L2 requires provenance from a hosted build platform, improving confidence that the build was run by a controlled service rather than an arbitrary local process.
What does SLSA Build L3 add?
Build L3 requires a hardened build platform with stronger isolation and controls that prevent one build from tampering with another or with provenance.
Is SLSA the same as build provenance?
No. Provenance is evidence about a build. SLSA is the framework that defines what evidence and build-system controls are needed at each level.
Does SLSA require reproducible builds?
SLSA and reproducible builds are complementary. SLSA focuses on controlled, attestable build processes; reproducibility lets others independently rebuild and compare outputs.
References
Explore authoritative guidance and frameworks related to supply-chain levels for software artifacts (slsa).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.