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:

RequirementDescriptionChainloop Policy
slsa-build-l1-1Follows consistent build process: scripted, repeatable (e.g., GitHub Actions), low variability, includes Git commit SHA.runner-automated (automatic)
slsa-build-l1-2Provenance includes build platform, process, inputs. Ensures buildType, externalParameters, and optionally resolvedDependencies.slsa-provenance-present (automatic)
slsa-build-l1-3Provenance 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:

RequirementDescriptionChainloop Policy
slsa-build-l2-1Build runs on dedicated infra, provenance is signed, and includes externalParameters and builder.slsa-signature-present (automatic)
slsa-build-l2-2Provenance 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 the builder 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:

RequirementDescriptionChainloop Policy
slsa-build-l3-1Build 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-2Build 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.

Official SLSA Level 3 documentation.