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 evidence 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 evidence)

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.	Automatic: runner-authenticated Manual evidence: 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 evidence: 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 a mixture of manual and automatic checks in Chainloop with the automation ensuring:

• Verification of the runner authentication.

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 a mixture of manual and automatic checks in Chainloop with the automation ensuring:

• Verification of the SLSA provenance signature.

Official SLSA Level 3 documentation.

Manual Evidence Explained

Chainloop uses a number of manual evidence to verify the SLSA requirements that you need to ensure are fulfilled in order to get SLSA Level 3 compliance. Let’s look into some them and how to verify them when using certain build platforms.

Forcing Multi-factor Authentication

The requirement for forcing multi-factor authentication is one of the SLSA requirements for SLSA Level 3. Chainloop enforces this by requiring you to verify your builld platform configuration and marking this as fullfiled.

GitHub

For GitHub, you can verify that your build platform is forcing multi-factor authentication by checking your organization security settings that can be accessed via https://github.com/organizations/[YOUR_ORGANIZATION]/settings/security and checking if the Require two-factor authentication for everyone in the YOUR_ORGANIZATION organization option is enabled.

GitLab

For GitLab, you can verify and configure your organization to for multi-factor authentication by going to the Admin section, selecting Settings -> General, expanding the Sign-in restrictions and enabling the Enforce two-factor authentication option.

Build Environment Isolation

SLSA Level 3 requires that the build environment is isolated from the rest of the system. Chainloop enforces this by requiring you to verify that your build platform is using an isolated environment, not interfering with other runs.

GitHub

You need to ensure that you are using the hosted runners or that your self-hosted runners used in GitHub are isolated. You can learn about your runners and their types in your GitHub organization settings, in the Actions -> Runners section.

GitLab

You need to ensure that you are using the hosted runners or that your self-hosted runners used in GitLab are isolated. You can learn about your GitLab runners and their types in your Project section, by going to Settings -> CI/CD -> Runners.

Limited Build Platform Human Access

The number of users with the access to the build plartform should be limited and kept to a minimum.

GitHub

You can check the user permissions of your GitHub in the Settings -> Access section of your GitHub organization and you can manage repository level access by visiting the Settings -> Collaborators and teams section of the repository of interest.

GitLab

You can manage repository level access by visiting the Project -> Manage -> Members section of the GitLab project of interest.

Build Platform Strong Controls

SLSA Level 3 requires that the build platform has strong controls in place and that your organization follows good practices.

There is not a single setting that we can verify and Chainloop suggest undergoing an annual security audit targeted at your build platform and the pracitices around it.

Some reference about the good practices for your build platform hardening:

• GitHub
• GitLab