Supply-chain Levels for Software Artifacts

What Is SLSA? (Supply-chain Levels for Software Artifacts)

In DevOps, securing your software supply chain is paramount, ensuring that your applications are not compromised by malicious actors. That’s not new. You can’t follow any cybersecurity content, channels or news outlets without seeing software supply chain security pop up.

But when it comes to software supply chain security, the DevOps community needed a benchmark. That’s where SLSA comes in.

Let’s delve into the world of SLSA and uncover what it is, why it’s important, the different levels, some use cases and why this framework is such a useful benchmark.

What Is SLSA?

SLSA, or Supply-chain Levels for Software Artifacts, is a framework developed by Google to help ensure the integrity and security of software artifacts throughout their supply chain. In April 2023, the new version (SLSA version 1.0) was released, and that’s the version we will discuss here.

SLSA provides a set of guidelines that outline the necessary security measures from development to deployment. The goal? To mitigate the risk of software supply chain attacks by establishing a set of best practices and standards that software developers and DevOps teams can follow.

Why Is It Important?

As software supply chains grow more complex and interconnected, the risk of attacks has become a major concern for organizations of all sizes.

Attackers can exploit supply chain vulnerabilities to gain unauthorized access to systems, inject malicious code or steal sensitive data.

The consequences of these attacks are devastating, resulting in reputational damage, financial losses and legal liabilities. By implementing SLSA, development and DevOps teams can establish a strong foundation for securing their software supply chain.

SLSA provides a set of security requirements and recommendations that cover areas like software signing, artifact provenance, build and release processes, vulnerability scanning and attestation.

Following these guidelines helps organizations mitigate the risk of attacks and enhances the overall security posture of their software applications.

SLSA Levels

There are four levels within SLSA, each representing a different degree of security maturity. In the newest version, there are also tracks. The Build track is outlined below:

Build L0: No Guarantees, No Requirements.
This level represents a lack of SLSA. It is intended for development or test builds of software that are built and run on the same machine, like unit tests.

Build L1: Provenance Exists.
At Build L1, organizations must maintain a build environment that is consistent and reproducible. This means that the build environment must be documented and changes to the environment must be tracked. Additionally, the build process must be able to be reproduced using the same inputs and build environment.

To achieve Build L1 compliance, organizations must also track critical components, including dependencies and their versions. The purpose of tracking critical components is to ensure that any changes or vulnerabilities in these components can be quickly identified and addressed.

Build L2: Hosting Build Platform.
After achieving L1, organizations must record build environment details and keep them up to date. This means documenting not only the build environment itself, but also any tooling or scripts used in the build process.

Build L2 compliance relies on proving a repeatable build process and verifying the integrity of critical components. This includes performing regular vulnerability scans of the components and ensuring that any vulnerabilities are quickly addressed.

Build L3: Hardened Builds.
After meeting L1 and L2, organizations must use automated tooling to enforce consistent builds and verify that only authorized individuals can modify the build environment. This means that the build process is automated and repeatable, with clear checks and balances to ensure that only trusted individuals can make changes to the process.

Organizations must also ensure that cryptographic signatures are used to sign artifacts and that these signatures are verified throughout the supply chain. This includes verifying the signature of the build artifacts during the build process as well as verifying the signature at each step of the supply chain.

SLSA Use Cases

SLSA can be applied to many different use cases, depending on the organization’s requirements and the nature of the software being developed. Below are a few of the most common:

Open-source software: Many organizations rely on open-source software components in their applications. However, open-source software comes with some major security risks if the code isn’t properly managed. SLSA helps ensure the integrity of open-source software components throughout the supply chain, from build to deployment, mitigating the risk of software supply chain attacks.

Cloud-native applications: Cloud-native applications are typically built using a complex ecosystem of containerized applications, microservices and APIs. Securing the supply chain of these components is critical to ensure the integrity of the overall application. SLSA can provide guidelines for securing the supply chain of container images, microservices and other components used in cloud-native applications.

Software as a Service: Organizations that provide SaaS solutions need to ensure the security of their software supply chain to protect their customers’ data and maintain their reputation. SLSA can be applied to the development, deployment and maintenance of SaaS applications to enhance their security posture and build trust with customers.

Making SLSA Accessible

There are several software security benchmarks and frameworks out there, and it can be difficult to decide which one to start with. SLSA is a robust set of guidelines, but it’s also an incredibly complex system to navigate. That’s why we chose to start with SLSA when developing our software supply chain security platform anun by CyberArk Labs. We wanted SLSA to be more accessible to all organizations. By using our platform, users can quickly run continuous SLSA assessments and prevent attacks on their builds without a heavy lift by their teams.

Want to learn more about anun and stay informed on the latest updates, like our next framework release (including NIST)? You can learn more here or try anun for yourself.