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. SLSA v1.1, released in April 2025 as an incremental update to v1.0 clarifies the terminology used in the framework, expands provenance requirements and strengthens the security requirements.

Key features of SLSA v1.1 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.

Let’s look at each level to see what it means and how Chainloop helps you verify it.

SLSA Level 1: Build Process Documentation

It ensures that the entire build proces is documented and recorded. This gives basic visibility into how the software is made, but doesn’t protect against tampering. Chainloop ensures that the build is run on a dedicated infrastructure, but doesn’t verify its authenticity.

SLSA Level 2: Protection Against Tampering

It ensures that the build is run on an authenticated, hosted runner with access to the build file. Chainloop checks this using an OIDC token from the build platform and also requires the provenance information to be signed using keyless signing. This helps prevent attackers from tampering with the code or build process, since all changes are tracked and the provenance is securely signed.

SLSA Level 3: Advanced Threat Protection

Currently the most advanced level of SLSA. It strengthen the build system with security controls and auditing. Provenance is non-falsifiable, so even insiders or compromised systems have a much harder time sneaking in malicious changes. Chainloop uses a mixture of automatic and manual proofs to ensure this SLSA level.

Detailed SLSA levels requirements

Let’s now look into deeper details of each SLSA level and their requirements.

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	Ensures build is run on a dedicated infrastructure.	runner-automated (automatic)
slsa-build-l1-3	Provenance is distributed, preferably via ecosystem convention.	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 runner environment presence.
• Ensures runner is one of the allowed runners.

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 using keyless signing.	signature-present (automatic)
slsa-build-l2-2	Provenance is signed using keyless signing and the runner is authenticated via OIDC token.	signature-present, runner-authenticated (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 and signed using keyless signing.

slsa-build-l2-1

Downstream verification of provenance includes validating the authenticity of the provenance. What Chainloop does:

• Verifies that the SLSA provenance is generated and signed using keyless signing and that the runner is authenticated via OIDC token and provides the workflow file reference.

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 provenance signature is verified.	Automatic: 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 signature.

Official SLSA Level 3 documentation.