What Is SLSA (Supply Chain Levels for Software Artifacts)?
Supply Chain Levels for Software Artifacts (SLSA) is a security framework that helps ensure the integrity of software artifacts. It aims to prevent cyberattacks by providing a model for security capabilities in the supply chain. The OpenSSF launched SLSA (pronounced salsa) in 2021, which grew to around 30 contributors within a year.
SLSA is inspired by Google’s established process for production workloads. SLSA helps address questions about trust—it helps you determine if the code you’re using is free of tampering and evaluate if the source code or build system used to create software packages is trustworthy.
What differentiates SLSA from other security guidelines is its design based on automatically creating verifiable metadata rather than simply providing a list of best practices. This metadata is useful for making policy decisions. SLSA goes beyond describing the process required to secure the software supply chain—it helps you implement security in the real world and obtain the data to demonstrate it.
This is part of a series of articles about supply chain security.
In this article:
Why Is SLSA Important?
All software can contain vulnerabilities and introduce supply chain risk. When software systems become more complex, it is important to implement best practices and controls to ensure the integrity of each artifact. In other words, the source code you depend on is the code you use.
A solid plan to ensure security throughout the supply chain as the system grows is essential for addressing future breaches. SLSA provides a clear, consensus-based industry standard for developers and enterprises. It specifies recognizable compliance requirements and protection measures.
SLSA’s design is highly adaptable and based on the broader security ecosystem. Anyone can adopt and implement the framework—you could be a user wanting to ensure the software you use is at a specific SLSA level. It is also useful for developers building an open source project, ensuring their infrastructure is SLSA-compliant. Alternatively, an organization might use SLSA as a guide to secure its internal supply chain and ensure compliance across all dependencies.
Related content: Read our guide to supply chain risk (coming soon)
SLSA Use Cases
SLSA prevents tampering with the software supply chain in different ways, depending on the use case. Here are the three main use cases for SLSA.
Protecting organizations
The most basic use case for SLSA is internally within organizations to minimize and mitigate risks posed by internal sources. This case is the easiest context to implement SLSA principles because it doesn’t require extending trust to a third party outside the organization.
Small companies or teams can use SLSA to ensure the binary code deployed to production is identical to the code tested and reviewed in its original form. Large enterprises can use SLSA to require at least two people to review all production changes and scale security to hundreds or thousands of teams and employees.
Protecting consumers
SLSA can help reduce risks for consumers using open source products. This use case involves mapping the built software packages and dependencies to their sources. Consumers only need to trust a handful of secure build systems instead of relying on thousands of developers with permission to upload to various packages.
If an uploaded package is built from a different source than the legitimate repository, the package registry will reject it during upload. The client will reject the package upon download if the package is not from a trusted builder.
Securing vendors
SLSA is also useful for reducing the risks to consumers of services and software provided by a vendor. Vendor software differs from open source products because there is no standard (canonical) source repository for mapping. Thus, security must focus on the credibility of the vendor’s claims.
You can demand that vendors implement SLSA as part of the contract. You should ensure that vendors are SLSA-certified by reputable third-party auditors.
SLSA Levels
SLSA requirements fall into four levels contributing to supply chain security. These levels help you define the security posture you want to achieve. A system without guarantees is considered Level 0:
- Level 1: Build process documentation—all processes for building an artifact must be fully documented and include metadata detailing sources and dependencies (provenance). Consumers use this information to assess security risks and make decisions.
- Level 2: Protection against tampering—requires version control and a hosted build service to generate provenance, giving the consumer more confidence in the software source. The build service’s trust level determines the tampering prevention.
- Level 3: Extra protection against certain threats—the build and source platforms meet the standards to enable auditing and ensure provenance integrity. Consumers can rely on the auditor’s certification.
- Level 4: Achieving the highest trust and confidence levels—requires two people to review all changes. The build process must be secure (hermetic) and reproducible, ensuring a complete list of dependencies.
SLSA levels are not transitive—each artifact has an independent SLSA rating, so companies can prioritize risks and upgrade the integrity and security guarantees in parallel. An artifact’s level only describes its build process and integrity safeguards, not its dependencies. Each dependency has a separate SLSA rating—a Level 4 artifact might include Level 0 dependencies.
Getting Started with the SLSA Framework
Here is a guide for launching an SLSA program. These steps will help you achieve SLSA 1, establish a foundation of trust in the system, and ensure that all applications generate the correct provenance information.
To achieve Level 1 security, you must introduce an automated build pipeline and generate provenance metadata. This process should not exceed two hours for a single project.
Step 1: Setup
Set up a CI/CD or build service if you haven’t already implemented one. While not a strict requirement at this level, using a build service simplifies the subsequent steps. It also helps prepare you for higher levels, where it is a requirement.
Step 2: Generating provenance
Create source data during the build processes. Provenance information is essential from the start to allow tracking software to the source and define the various components of the complex supply. This information should be verifiable and describe details about the software artifact’s creation.
Higher SLSA levels have stricter requirements for provenance data and provide stronger integrity guarantees. However, these also require a deeper and more technical understanding of the predicate (true/false function).
Step 3: Providing provenance data to consumers
At this stage of the SLSA 1 process, you should define the ideal state for your project. Consider the best level for urgent, short-term needs and identify the most realistic, achievable level. Achieving an ideal security posture can take years, so it’s important to have mid-term milestones.
You can advance SLSA levels for different artifacts in parallel, gradually increasing the SLSA level for each artifact. You can prioritize risks independently and pursue different levels for different product parts.
Once you have laid the foundations for Level 1, you can continue to higher SLSA levels that further enforce your software artifact’s integrity. Improving your SLSA security posture involves centralized monitoring, authentication, automated compilation, and secure development processes.
Supply Chain Attack Protection with Aqua Security
Aqua Security provides enterprise-class security solutions to secure cloud native applications and environments from software supply chain attacks. Detect malware and anomalous activity that only manifests at runtime, without putting production environments and sensitive data at risk. Aqua Dynamic Threat Analysis (DTA) deploys containers in a secure sandbox environment and documents the entire attack killchain, providing unprecedented insight to security and forensics teams and establishing a security gate to block promotion of malicious artifacts into production.
