Securing the Software Supply Chain with SLSA and Chainloop
Miguel Martinez
The security of software supply chains has become a critical concern for organizations worldwide. High-profile breaches like SolarWinds and Codecov have underscored the importance of traceability, verification, and security in software development. Enter Supply-chain Levels for Software Artifacts, or simply SLSA, an industry-backed security framework that helps ensure your software hasn’t been tampered with and that it can be trusted, end-to-end.
In this blog post, we explore what SLSA 1.1 brings to the table, how Chainloop can help you adopt and verify SLSA compliance, and how to get started with SLSA in your own CI/CD pipelines. We’ll learn about SLSA, go into each SLSA level, show you how Chainloop automates many of the hard parts, and provide the configuration examples.
What is SLSA?
SLSA (pronounced “salsa”) is a security framework developed by the Open Source Security Foundation (openSSF) to provide guidance and tooling for securing the software supply chain. SLSA defines a series of progressive levels, each building on the previous, to provide increasing assurance that software has not been tampered with and is properly traceable.
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 aimed 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.
By working on SLSA compliance, you’ll strengthen your software build practices by creating a secure environment for software development, verifying the integrity of software releases, and protecting against unauthorized access and tampering. This not only strengthens your software supply chain but also helps meet the requirements outlined in the U.S. Executive Order 14028 and aligns with the Secure Software Development Framework (SSDF) practices and helps you with the implementation of the Cyber Resilience Act (CRA) to ensure the software products are secure through the whole development lifecycle.
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.
Why Does SLSA Matter?
SLSA helps mitigate risks across the software lifecycle, including:
- Tampered source code.
- Insecure or unverified build systems.
- Compromised CI/CD pipelines.
- Unauthorized or undocumented dependencies.
SLSA brings visibility, trust, and resilience to your development process. Think of it like a food safety certification for your software: not only do you know what’s in it (thanks to SBOMs), but you know it was handled safely throughout its creation.
Chainloop stays up to date with the recent development of the SLSA framework and brings you support for SLSA v1.1, released in April 2025, builds on the 1.0 foundation with improvements aimed at usability, flexibility, and robustness:
- Tracks: Modular design allows you to adopt SLSA incrementally by focusing on specific aspects (e.g., the Build Track).
- Expanded Provenance Requirements: Clearer guidance on how to record and verify provenance data.
- Better Stability: SLSA 1.1 forms a solid base for future updates without breaking current implementations.
Understanding SLSA Framework
The SLSA framework defines terminology for and models to describe what it aims to protect. It all starts with the artifact - an immutable blob of data. The artifact that is authored or reviewed without modification is called the source, the beginning of the software supply chain. The build transforms the set of input artifacts into output artifacts with potential use of dependencies and is later distributed as a package to the package ecosystem along with the attestation, a signed metadata describing the package.
When talking about SLSA, we talk in terms of tracks and their levels. A track focuses on a given aspect of a supply chain, such as the build track. For now, SLSA consists only of a single track related to build, but more is in the works right now - the platform and source ones. Each track defines ascending levels of security with more requirements and hardened security, each level giving more guarantees related to supply chain security threats.
Currently, looking from SLSA 1.1 perspective, there is a single Build Track that includes three main levels, but we can actually talk about four of them - starting from level 0, which is the one that doesn’t include any security. Let’s now see what each level means for the build track and what it helps with.
SLSA Level 1: Build Process Documentation
It ensures that the entire build process 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 strengthens 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.
To summarize:
| Level | Definition | Protects Against | Resilience |
|---|---|---|---|
| 0 | No level of security | - | - |
| 1 | Provides documentation of the build process, source, and dependencies. | Honest mistakes or misconfigurations in build setups. | Gives visibility and transparency into how artifacts are built. |
| 2 | Ensures the build is run in a trusted and authenticated environment. | Tampering in the build pipeline and untrusted or unmanaged runners. | Ensures builds are tied to identity and infrastructure. |
| 3 | Applies strong security controls to the build platform. | Insider threats. | Lockdowns build and auditing to prevent or detect malicious actions. |
For more information about the levels, refer to the Chainloop SLSA documentation.
How Chainloop Helps You Achieve SLSA Compliance
Chainloop simplifies SLSA adoption by integrating directly into your CI/CD pipeline, crafting attestation, which is a cryptographically signed metadata about the build artifacts and providing a set of automatic policies and manual evidence for provenance verification, signature presence check, and build runner identification. It maps SLSA requirements to the mentioned policy checks and manual evidence so you can track your compliance posture and know exactly what’s done and what’s missing. Let’s look at the requirements for each SLSA level and what they mean from the Chainloop perspective.
| Level | Requirement | Description | Chainloop Verification |
|---|---|---|---|
| 1 | slsa-build-l1-1 | Follows consistent build process: scripted, repeatable (e.g., GitHub Actions), low variability, includes Git commit SHA. | Automated runner enforcement. |
| 1 | slsa-build-l1-2 | Ensures the build is run on a dedicated infrastructure. | Enforce approved runner list. |
| 1 | slsa-build-l1-3 | Provenance is distributed, preferably via ecosystem convention. | Manual evidence. |
| 2 | slsa-build-l2-1 | Build runs on dedicated infra, provenance is signed using keyless signing. | Keyless signature presence verification. |
| 2 | slsa-build-l2-2 | Provenance is signed using keyless signing and the runner is authenticated via OIDC token. | Runner authentication and keyless signature presence verification check. |
| 3 | slsa-build-l3-1 | Build platform prevents cross-run interference, even within the same project. | Manual evidence related to build isolation, multi-factor authentication, infrastructure access, and monitoring. |
| 3 | slsa-build-l3-2 | Build platform provenance signature is verified. | Provenance signature presence with manual secrets control and signature proofs. |
For more detailed information head over to Chainloop documentation.
Getting Started with Chainloop and SLSA
With Chainloop, you can continuously evaluate SLSA compliance posture of your projects in three simple steps:
- Start by configuring your CI workflow to perform authentication.
- Configure your contracts to use the slsa-checks policy group.
- Attach the SLSA framework to your project.
You can learn more about the whole process in the guide.
Once you have all the configuration done and everything went well you will be able to verify the SLSA level of your build platform by visiting Chainloop platform.
Summary
Ensuring the security of the whole software supply chain and the build platform itself is critical and challenging. Implementing frameworks like SLSA and continuously monitoring the compliance level helps you mitigate potential threats and ensure the maximum level of security of your build.
Introducing any compliance framework to your organization is a process, and Chainloop helps you introduce SLSA into your build pipeline and make it practical and actionable by:
- Automating provenance verification and signing - all you need to do is configure your CI/CD once.
- Mapping SLSA requirements to build policies - create a contract including the SLSA policy group and use it in your workflow to continuously monitor SLSA compliance.
- Giving real-time visibility into your SLSA compliance posture.
Give it a try and let us know what you think!
