SLSA Framework
What is SLSA provenance and how Chainloop helps you verify your SLSA compliance.
Supply-chain Levels for Software Artifacts (SLSA) is a security framework designed to safeguard the integrity of software supply chains. Developed by the Open Source Security Foundation (OpenSSF), SLSA provides a structured approach to improving the security posture of software artifacts throughout their lifecycle, from development to deployment. The primary goal of SLSA is to ensure that software has not been tampered with and can be securely traced back to its source.
SLSA v1.0, released in April 2023, represents the first stable version of the framework. It introduces a simplified and modular structure, focusing on specific aspects of software supply chain security, such as build systems and provenance verification. This release aims to make the framework more accessible and practical for adoption by organizations across industries.
Key features of SLSA v1.0 include:
- Tracks: A division into tracks that focus on distinct areas of supply chain security, enabling incremental adoption.
- Provenance: Enhanced guidance on verifying the origin and integrity of software artifacts.
- Stability: A solid foundation for future expansions without breaking changes.
While achieving SLSA compliance, your build platform creates a secure environment for software development, protects against unauthorized access and tampering, and provides a mechanism for verifying the integrity of software releases. This not only strengthens your software supply chain but also helps meet the requirements outlined in Section 4e(iii), 4e(iv), and 4e(ix) of U.S. Executive Order 14028 and aligns with the Secure Software Development Framework (SSDF) practices, including PO.5 and PS.1.
Chainloop helps you adopt, incorporate and implement SLSA into your Software Development Life Cycle to reduce the risk of supply chain attacks, improve transparency in software development processes, and build trust with consumers of your software.
SLSA Levels: Requirements, Benefits, and Problem Solving
SLSA defines three progressive levels of compliance that represent increasing rigor in securing the software supply chain. Each level addresses specific risks and builds upon the previous one.
Level 1: Build Process Documentation
The first level of SLSA specifies the following requirements and addresses the following problems:
- Requirements:
- Document all processes involved in building an artifact.
- Include metadata detailing sources and dependencies.
- What it means:
- Provides visibility into the build process, enabling consumers to assess risks and identify potential issues.
- Problems addressed:
- Helps detect honest mistakes or misconfigurations in the build process.
- Establishes a baseline for transparency in software development.
Chainloop verifies the requirements for SLSA Level 1 by using the following requirements and policies:
Requirement | Description | Chainloop Policy |
---|---|---|
slsa-build-l1-1 | Follows consistent build process: scripted, repeatable (e.g., GitHub Actions), low variability, includes Git commit SHA. | runner-automated (automatic) |
slsa-build-l1-2 | Provenance includes build platform, process, inputs. Ensures buildType , externalParameters , and optionally resolvedDependencies . | slsa-provenance-present (automatic) |
slsa-build-l1-3 | Provenance is distributed, preferably via ecosystem convention. | slsa-provenance-present (automatic), convention-agreed (manual proof) |
slsa-build-l1-1
Software producer follows a consistent build process so that others can form expectations about what a correct build looks like. We understand the requirement as:
- Build should be scripted.
- Build should use declarative and repeatable build system such as like GitHub Actions, GitLab CI, etc.
- Build variability should be minimized, so ensure packages are locked, etc.
- Git commit SHA should be embedded into the provenance file.
slsa-build-l1-2
Provenance exists describing how the artifact was built, including the build platform, build process, and top-level inputs. What Chainloop does:
- Ensures that the values for
buildType
exist. - Ensures that the values for
externalParameters
in the provenance file exist. - Optionally ensures the values for
resolvedDependencies
.
slsa-build-l1-3
Software producer distributes provenance to consumers, preferably using a convention determined by the package ecosystem. We understand the requirement as:
- Verification of existence of a provenance material.
Official SLSA Level 1 documentation.
Level 2: Protection Against Tampering
SLSA level 2 specifies the following requirements and addresses the following problems:
- Requirements:
- Use a build version control for source code.
- Employ a hosted build service to generate signed provenance.
- What it means:
- Ensures that artifacts are traceable to their source and have not been tampered with during the build process.
- Problems addressed:
- Mitigates risks of unauthorized changes or tampering by requiring signed provenance and controlled infrastructure.
Chainloop verifies the requirements for SLSA Level 2 by using the following requirements and policies:
Requirement | Description | Chainloop Policy |
---|---|---|
slsa-build-l2-1 | Build runs on dedicated infra, provenance is signed, and includes externalParameters and builder . | slsa-signature-present (automatic) |
slsa-build-l2-2 | Provenance authenticity is verified via signature validation. | slsa-signature-present (automatic) |
slsa-build-l2-1
Build platform runs on dedicated infrastructure, not an individual’s workstation, and the provenance is tied to that infrastructure through a digital signature. What Chainloop does:
- Verifies that the SLSA provenance is generated by one of the trusted builders known to the user.
- Verifies presence of the
externalParameters
section and thebuilder
section in the SLSA provenance file.
slsa-build-l2-1
Downstream verification of provenance includes validating the authenticity of the provenance. What Chainloop does:
- Verification of the SLSA provenance certificate signature.
Official SLSA Level 2 documentation.
Level 3: Advanced Threat Protection
SLSA level 3 specifies the following requirements and addresses the following problems:
- Requirements:
- Hardened build systems with security controls.
- Provenance must be non-falsifiable and auditable.
- What it means:
- Provides stronger guarantees about artifact integrity by ensuring that both source and build platforms meet rigorous standards.
- Problems addressed:
- Protects against sophisticated threats such as insider attacks or compromised build environments.
Chainloop verifies the requirements for SLSA Level 3 by using the following requirements and policies:
Requirement | Description | Chainloop Policy |
---|---|---|
slsa-build-l3-1 | Build platform prevents cross-run interference, even within the same project. | Manual proofs:build-platform-multifactor build-platform-isolated build-platform-connections build-platform-access build-platform-monitoring controls-build-platform-evidence |
slsa-build-l3-2 | Build platform restricts access to signing secrets; provenance signature is verified. | Automatic:slsa-signature-present Manual proofs: build-platform-certificate controls-build-platfrom-secrets-evidence |
slsa-build-l3-1
Build platform implements strong controls to prevent runs from influencing one another, even within the same project.
The process of verification of the slsa-build-l3-1
is currently fully manual in Chainloop.
slsa-build-l3-2
Build platform implements strong controls to prevent secret material used to sign the provenance from being accessible to the user-defined build steps.
The process of verification of the slsa-build-l3-2
is currently fully a mixture of manual and automatic checks in Chainloop with the
automation ensuring:
- Verification of the SLSA provenance certificate signature.