SLSA
Supply-chain Levels for Software Artifacts
SLSA is a compliance framework from International (OpenSSF, Linux Foundation) with 9 domains and 44 controls that map to 131 other frameworks. The largest domains are Source track: source control system requirements – SLSA (11 controls), Build track: build platform requirements – SLSA (6 controls), Source track: example organization controls (optional, claimed at Source L3 and above) – SLSA (6 controls). Every control below carries what it requires and what an assessor expects to see.
Get the official standard. This page is a source-grounded companion to the published text, not a replacement for it.
Visit slsa.devFramework summaries on this platform are interpretations grounded in the published source, for educational and compliance planning purposes. They do not reproduce or replace the official standards. Refer to the authoritative source for the definitive text. Framework names and trademarks belong to their respective organisations.
Framework Domains (9)
Attestation formats: build provenance, verification summaries and verified properties – SLSA
| Code | Title |
|---|---|
| slsa::AF.1 | Build provenance content and model |
| slsa::AF.2 | Produce verification summary attestations correctly |
| slsa::AF.3 | Verify verification summary attestations |
| slsa::AF.4 | Issue SLSA verified properties only when earned |
Build track: build platform requirements – SLSA
| Code | Title |
|---|---|
| slsa::BB.1 | Industry security best practices for every implementation |
| slsa::BB.2 | Provenance exists (Build L1) |
| slsa::BB.3 | Provenance is authentic (Build L2) |
| slsa::BB.4 | Provenance is unforgeable (Build L3) |
| slsa::BB.5 | Hosted build platform (Build L2) |
| slsa::BB.6 | Isolated builds (Build L3) |
Build track: distributing provenance – SLSA
| Code | Title |
|---|---|
| slsa::BD.1 | Bind attestations to artifacts, not releases |
| slsa::BD.2 | Publish attestations where consumers can get them |
| slsa::BD.3 | Immutable attestations in an accepted format |
Build track: producer requirements – SLSA
| Code | Title |
|---|---|
| slsa::BP.1 | Choose an appropriate build platform (Build L1 to L3) |
| slsa::BP.2 | Follow a consistent build process (Build L1 to L3) |
| slsa::BP.3 | Distribute provenance to consumers (Build L1 to L3) |
Build track: verifying artifacts and assessing build platforms – SLSA
| Code | Title |
|---|---|
| slsa::BV.1 | Verify the artifact's Build level against roots of trust |
| slsa::BV.2 | Check provenance against expectations |
| slsa::BV.3 | Form and protect expectations |
| slsa::BV.4 | Verify at one or more architecture points |
| slsa::BV.5 | Assess build platforms before trusting them |
Source track: example organization controls (optional, claimed at Source L3 and above) – SLSA
| Code | Title |
|---|---|
| slsa::SE.1 | Expert code review |
| slsa::SE.2 | Review every single revision |
| slsa::SE.3 | Automated testing before acceptance |
| slsa::SE.4 | Every revision reachable from a branch was approved |
| slsa::SE.5 | Immutable change discussion |
| slsa::SE.6 | Merge trains |
Source track: organization requirements – SLSA
| Code | Title |
|---|---|
| slsa::SO.1 | Choose an appropriate source control system (Source L1 to L4) |
| slsa::SO.2 | Configure the SCS to control access and enforce history (Source L2 to L4) |
| slsa::SO.3 | Safe expunging process (Source L2 to L4) |
| slsa::SO.4 | Continuous technical controls (Source L3 and L4) |
Source track: source control system requirements – SLSA
| Code | Title |
|---|---|
| slsa::SS.1 | Repositories are uniquely identifiable (Source L1 to L4) |
| slsa::SS.10 | Protected named references (Source L3 and L4) |
| slsa::SS.11 | Two-party review (Source L4) |
| slsa::SS.2 | Revisions are immutable and uniquely identifiable (Source L1 to L4) |
| slsa::SS.3 | Human readable changes (Source L1 to L4) |
| slsa::SS.4 | Source verification summary attestations (Source L1 to L4) |
| slsa::SS.5 | Source VSA content |
| slsa::SS.6 | Change history (Source L2 to L4) |
| slsa::SS.7 | Control continuity (Source L2 to L4) |
| slsa::SS.8 | Identity management (Source L2 to L4) |
| slsa::SS.9 | Source provenance (Source L2 to L4) |
Source track: verifying source and assessing source control systems – SLSA
| Code | Title |
|---|---|
| slsa::SV.1 | Verify source revisions |
| slsa::SV.2 | Assess source control systems before trusting them |
Your Compliance Coverage
If you comply with SLSA, you already cover:
US EPA Safe Drinking Water Act (SDWA) - Cybersecurity Requirements
4%
3 controls mapped
Compare →TSA Pipeline Cybersecurity Directives
4%
3 controls mapped
Compare →ISO/IEC 27011:2024
4%
3 controls mapped
Compare →+ 128 more: NIST SP 800-124 Revision 2 - Guidelines for Managing the Security of Mobile Devices (4%), ISO/IEC 27043:2015 (4%)
See all 131 mapped frameworks ↓Maps to 131 other frameworks
Coverage is not the same as your position
This page shows what SLSA overlaps with in general. Where your organisation actually stands, against the standard you are going for and the certifications you already hold, is a different question. Same graph and the same recorded refutations, scoped to you rather than to a pair.
The Compliance Position Diagnostic, $5,000 fixed, ten business daysWhat is SLSA and who does it apply to?
SLSA is a compliance framework from International (OpenSSF, Linux Foundation) with 9 domains and 44 controls. Supply-chain Levels for Software Artifacts It is used by organisations to establish and maintain compliance with industry standards and regulatory requirements.
What does SLSA actually require?
SLSA has 44 controls organised across 9 domains. The largest domains are Source track: source control system requirements – SLSA (11 controls), Build track: build platform requirements – SLSA (6 controls), Source track: example organization controls (optional, claimed at Source L3 and above) – SLSA (6 controls). Each control defines specific requirements that organisations must implement to achieve compliance.
If I already comply with another framework, how much of SLSA do I already cover?
SLSA maps to 131 other compliance frameworks. The top mapping partners are US EPA Safe Drinking Water Act (SDWA) - Cybersecurity Requirements (4% coverage), TSA Pipeline Cybersecurity Directives (4% coverage), ISO/IEC 27011:2024 (4% coverage). Use our comparison tool to explore control-level mappings between frameworks.
How do I implement SLSA?
Start your SLSA compliance journey by running a self-assessment on our platform to identify your current compliance posture. Our AI advisory can answer specific questions about SLSA requirements, and cross-framework mapping helps you leverage existing controls from other frameworks you may already comply with. Create a free account to access all 44 controls and track your progress.
Start Your Compliance Journey
Create a free account to run self-assessments, get AI advisory, and track your compliance progress across 1,120 frameworks.
Get Started Free →Free forever, no credit card required