SLSA Framework

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, established the first stable version with a focus on build systems and provenance verification. SLSA v1.2 is the current version, introducing a comprehensive source track alongside the existing build track, creating a complete framework that addresses security from source code management through the build process. Key features of SLSA v1.2 include:

• Tracks and Levels: A division into two primary tracks (source track and build track) with progressive levels within each track, enabling incremental adoption tailored to your organization’s maturity.
• Source Track: Focuses on version control and code review practices used to produce source code, with four levels addressing repository management, change history, technical controls, and two-party review.
• Build Track: Focuses on the build process and generated software artifacts, ensuring provenance and integrity throughout the build lifecycle.
• Provenance: Verifiable metadata that documents the origin and integrity of both source code and software artifacts, enabling traceability throughout the supply chain.
• Stability: A solid foundation for future expansions without breaking changes.

While achieving SLSA compliance, your software supply chain creates a secure environment for software development, protects against unauthorized access and tampering, and provides a mechanism for verifying the integrity of software from source code to final 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.3.1, PO.3.2, PO.5, PS.1, PS.2, PS.3.2, PS.3.3, and PW.7. 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 v1.2 defines two complementary tracks for securing the software supply chain: Source Track: Focuses on version control and code review practices with four progressive levels (L1-L4) that ensure source code integrity, from basic version control to two-party review requirements. Build Track: Focuses on the build process with three progressive levels (L1-L3) that represent increasing rigor in securing how software artifacts are built and attested. Each level within both tracks addresses specific risks and builds upon the previous one. Let’s look at the source track levels first, then explore the build track levels.

​

Source Track Levels

​

Source Level 1: Version Controlled

Source Level 1 ensures that source code is managed using a modern version control system that provides basic traceability and visibility into code changes.

​

Source Level 2: History & Provenance

Source Level 2 adds requirements for preserving complete change history, creating a full audit trail of all changes with verified identity of contributors and tamper-resistant history.

​

Source Level 3: Continuous Technical Controls

Source Level 3 requires that technical protections (like required reviews, status checks) are always active and documented, ensuring consistent enforcement.

​

Source Level 4: Two-Party Review

Source Level 4 is the highest level, ensuring that no single person can unilaterally make changes to protected branches, reducing insider threats and ensuring code review quality.

​

Detailed Source Track Requirements

Let’s now look into deeper details of each source track level and their requirements. Official SLSA Source Track Requirements documentation.

​

Source Level 1: Version Controlled

The first level of SLSA Source Track specifies the following requirements and addresses the following problems:

• Requirements:
  • Use a modern version control system with unique identification
  • Ensure revisions are immutable and uniquely identifiable
  • Provide human-readable display of changes between revisions
  • Generate Source Verification Summary Attestations
• What it means:
  • Provides basic version control and traceability, enabling visibility into code changes and their history.
• Problems addressed:
  • Prevents untracked or unofficial changes to source code
  • Establishes a baseline for source code management and transparency

Chainloop verifies the requirements for SLSA Source Level 1 by using the following requirements:

​

slsa-source-l1-1

The organization has selected a Source Control System (SCS) that is capable of meeting the desired SLSA Source Level requirements. What Chainloop does:

• Automatically verifies that the source code management platform is a supported SCS (GitHub or GitLab) through runner context validation.
• GitHub and GitLab inherently support the necessary features for version control, immutability, and change tracking required by SLSA.

​

slsa-source-l1-2

Each repository in the source control system has a unique identifier (e.g., URL, namespace/name). What Chainloop does:

• Automatically verifies that the source code management platform is a supported SCS (GitHub or GitLab) through runner context validation.
• GitHub and GitLab assign unique URLs to each repository, ensuring repositories can be uniquely referenced and distinguished from one another.

​

slsa-source-l1-3

Once a revision is committed, its content cannot be modified, and each revision has a unique identifier. What Chainloop does:

• Automatically verifies that the source code management platform is a supported SCS (GitHub or GitLab) through runner context validation.
• Git inherently makes commits immutable with unique SHA-1/SHA-256 hashes, ensuring revisions cannot be modified and are uniquely identifiable in both GitHub and GitLab.

​

slsa-source-l1-4

The source control system provides human-readable diffs showing changes between revisions. What Chainloop does:

• Automatically verifies that the source code management platform is a supported SCS (GitHub or GitLab) through runner context validation.
• GitHub and GitLab provide diff views in their UI by default, allowing users to easily view changes between any two revisions.

​

slsa-source-l1-5

The Source Control System generates a Source Verification Summary Attestation (Source VSA) to indicate the SLSA Source Level of any revision at Level 1 or above. What Chainloop does:

• Automatically verifies that the source code management platform is a supported SCS (GitHub or GitLab) through runner context validation.
• Chainloop generates attestations that include all policies and validations performed, with VSA format support coming soon.

​

Source Level 2: History & Provenance

SLSA Source Level 2 specifies the following requirements and addresses the following problems:

• Requirements:
  • Implement access controls on the source repository
  • Establish a safe process for content expungement when legally required
  • Preserve complete change history with timing, actors, and ancestry relationships
  • Maintain technical controls continuously from an established start point
  • Implement identity management system for source control access
  • Generate contemporaneous source provenance attestations
• What it means:
  • Ensures complete audit trail of all changes with verified identity of contributors and tamper-resistant history.
• Problems addressed:
  • Prevents alteration of change history
  • Prevents forged change metadata
  • Protects against replacing tagged content with malicious content

Chainloop verifies the requirements for SLSA Source Level 2 by using the following requirements and policies:

​

slsa-source-l2-1

The organization must configure access controls to restrict sensitive operations on the Source Repository using SCS identity management capabilities. What Chainloop does:

• Automatically verifies that force pushes are blocked, branch deletions are blocked, and linear history is required through branch protection policies.
• Requires manual confirmation that access controls are configured and users are assigned to appropriate roles with limited update permissions to specific branches. GitHub requires enabling branch protection rules, GitLab protects main/master by default but other branches require manual configuration.

​

slsa-source-l2-2

Organizations may remove content for legal or privacy compliance, but only through a documented, tracked process with strict safeguards. What Chainloop does:

• Requires confirmation that the expunging process is documented, all removals are tracked, and the SCS requires an Administrator plus at least one additional trusted person to trigger any expunging.

​

slsa-source-l2-3

Complete change history is preserved for all revisions including timing information, actors who made changes, and ancestry relationships. What Chainloop does:

• Verifies that force pushes are blocked to prevent rewriting history.
• Verifies that branch deletions are blocked to preserve complete history.
• Verifies that linear history is required, ensuring ancestry relationships are maintained.

​

slsa-source-l2-4

Technical controls are only effective if they are used continuously in the history of a branch. What Chainloop does:

• Automatically verifies that force pushes are blocked, branch deletions are blocked, and linear history is required, ensuring technical controls protecting change history are continuously enforced.

​

slsa-source-l2-5

Identity management system is implemented to ensure that actors making changes are properly identified. What Chainloop does:

• Verifies that commits are signed using cryptographic signatures, ensuring all commits can be attributed to verified identities through commit signing.

​

slsa-source-l2-6

Generate tamper-resistant attestations documenting how revisions were created and integrated into protected branches. What Chainloop does:

• Automatically verifies that the source code management platform is a supported SCS (GitHub or GitLab) through runner context validation.
• Chainloop generates attestations that include all policies and validations performed.

​

Source Level 3: Continuous Technical Controls

SLSA Source Level 3 specifies the following requirements and addresses the following problems:

• Requirements:
  • Enforce technical controls continuously on protected branches
  • Document controls in contemporaneously produced attestations
  • Designate protected branches and record their controls
• What it means:
  • Provides assurance that technical protections are always active and cannot be bypassed or disabled without detection.
• Problems addressed:
  • Prevents skipping required checks
  • Prevents abuse of rule exceptions
  • Prevents highly-permissioned actors from bypassing controls

Chainloop verifies the requirements for SLSA Source Level 3 by using the following requirements:

​

slsa-source-l3-1

Organizations must enforce technical controls continuously for specific Named References within the Source Repository. What Chainloop does:

• Automatically verifies that the source code management platform is a supported SCS (GitHub or GitLab) through runner context validation.
• GitHub and GitLab enforce technical controls, and Chainloop verifies these controls are active through automated policies.

​

slsa-source-l3-2

The SCS must allow organizations to designate which branches or tags receive technical controls (Protected Named References). What Chainloop does:

• Automatically verifies that the source code management platform is a supported SCS (GitHub or GitLab) through runner context validation.
• GitHub and GitLab support designating protected branches and tags with per-branch technical controls, which are validated through Chainloop’s automated policies.

​

Source Level 4: Two-Party Review

SLSA Source Level 4 specifies the following requirements and addresses the following problems:

• Requirements:
  • Changes to protected branches require agreement from two or more trusted persons
  • Reviews must address security-relevant code properties
  • Reviewers must approve the final revision, not intermediate versions
• What it means:
  • Provides the highest level of assurance by ensuring no single person can unilaterally make changes to protected branches.
• Problems addressed:
  • Prevents malicious code from being submitted to the source repository
  • Prevents single actor from controlling multiple accounts
  • Prevents use of robot accounts to bypass review
  • Prevents code modification after review
  • Prevents submission of unreviewable changes
  • Protects against commit graph attacks

Chainloop verifies the requirements for SLSA Source Level 4 by using the following requirements and policies:

​

slsa-source-l4-1

Changes to protected branches require agreement from two or more trusted persons through code review. What Chainloop does:

• Verifies that pull request reviews are required with a minimum of two reviewers.
• Verifies that code owner reviews are enforced to ensure knowledgeable reviewers.
• Verifies that stale reviews are dismissed when new changes are pushed, ensuring reviewers approve the final revision.

​

Build Track Levels

​

SLSA Build 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 Build 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 Build 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 Build Track Requirements

Let’s now look into deeper details of each build track level and their requirements. Official SLSA Build Track Requirements documentation.

​

Build 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:

​

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.

​

Build 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:

​

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.

​

Build 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:

​

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.

​

Manual Evidence Explained

Chainloop uses a number of manual evidence to verify the SLSA Build Track requirements that you need to ensure are fulfilled in order to get SLSA Build Level 3 compliance. Let’s look into some of 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 Build Level 3. Chainloop enforces this by requiring you to verify your build platform configuration and marking this as fulfilled.

​

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 Build 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 platform 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 Build 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 suggests undergoing an annual security audit targeted at your build platform and the practices around it. Some reference about the good practices for your build platform hardening:

• GitHub
• GitLab