What is SLSA?

SLSA (pronounced “salsa”), or Supply chain Levels for Software Artifacts, is a security framework consisting of standards and controls that prevent tampering, improve integrity, and secure packages and infrastructure. While cyberattacks like SolarWinds and Codecov have demonstrated the importance of protecting software from tampering and malicious compromise, the complexity of the software development lifecycle can leave many feeling unable to adequately understand or respond to these specific security issues.

Released by Google’s Open Source Security Team in 2021, SLSA was created as a framework to help software creators understand where and how they can harden their supply chain security practices, and help software consumers evaluate the integrity of a software product or component before they decide to use it. SLSA was also designed around the creation of verifiable metadata, so that software consumers can set automated policies to prevent the deployment of code that does not meet their preferred SLSA level.

Today, SLSA is a vendor-neutral project supported by the Open Source Security Foundation and is actively evolving its standards and supporting tools with industry input. In this guide, you will learn about SLSA tracks, levels, and security requirements, as well as emerging tools that can help you meet these requirements.

SLSA Tracks and Levels

Evolving from v0.1, SLSA v1.0 shifted to its current track structure, dividing requirements for key pillars of supply chain security into separate categories. Previously, the single unnamed SLSA track captured elements of different areas, making achieving high levels of SLSA difficult if a build fell short in some aspects. By restructuring SLSA into multiple tracks, organizations can focus on hardening one aspect of their security without being blocked by the status of a different track.

SLSA levels are designed to function as a ladder so that developers and organizations can incrementally work towards achieving a security posture appropriate for their risk profile. Some software projects may take more time to advance up the ladder, so this framework offers a piecemeal approach that may be more realistic (and encouraging) than trying to meet all of the requirements at once.

As of this writing, SLSA offers a build track with three ascending levels of security, each containing a set of security requirements that expands on those of the prior level. The SLSA project has proposed adding additional tracks in a prospective version.

Note that these tracks, levels, and/or their requirements may shift with the release of future SLSA versions.

Build Track

Focusing on an artifact’s provenance, the build track outlines three levels designed to provide verification that artifacts meet build expectations. Establishing provenance gives consumers information about who built an artifact, what inputs were used, and what process was used to build it. Comparing an artifact’s expected and actual provenance can help to stop supply chain threats in their tracks by ensuring artifacts are constructed from trustworthy materials, by credible sources. SLSA recommends its SLSA Provenance format for meeting provenance expectations.

Build Level 1

Provenance showing how the package was built

Level 1 sets a foundation for working towards subsequent build track levels. Software production methods must be consistent so standard expectations for future builds are set. In addition, artifact provenance containing information on the build must be automatically generated by the build platform. Software producers are responsible for distributing provenance metadata with package releases.

While Level 1 does not prevent tampering, fulfilling its requirements represents an important first step in securing your software supply chain. Labeling your software with this level can also help consumers make informed decisions about whether it has been sufficiently secured and verified for their applications. For more information on getting started with reaching Level 1, visit SLSA’s quick start guide.

Build Level 2

Signed provenance, generated by a hosted build platform

Adding to the requirements of Level 1, Level 2 requires the use of a hosted build service like GitHub Actions, Google Cloud Build, or Travis CI rather than a developer’s local environment. The hosted service must sign the provenance it generates through the use of digital signatures, a method of verifying the authenticity and integrity of the software artifact.

The stricter requirements for Level 2 help provide more protection against software tampering and enable greater levels of trust that the provenance data is accurately represented. For more information, check out SLSA’s guide on reaching level 2.

Build Level 3

Hardened build platform

As the highest level of the build track, Level 3 aims to increase trust and harden infrastructure through a variety of requirements designed to meet specific threats. The requirements are as follows:

• Isolated: The build steps must be run in an isolated environment without risk of influence from other build processes, such as a container or VM, that has been created specifically for the build. Environments must not be reused.
• Unforgeable: It must be impossible for the build service’s users to falsify provenance information. All provenance information must be generated by the build service in a trusted control plane, except for noted exceptions.

Generating provenance compliant with Level 3 requirements can help end users verify the integrity of the software before implementing it. Recently, SLSA released the open source SLSA 3 Container Generator for GitHub Actions that helps ease the process by allowing you to build automated provenance generation into your container workflows. To learn more about how it works, visit the General availability of SLSA 3 Container Generator for GitHub Actions announcement blog post. You can also check out SLSA’s guide on reaching level 3.

SLSA Tools and Practices

The SLSA framework and its supporting tools and practices are still actively evolving. Some of the previously listed level requirements can be met using popular build and version control systems. More specific requirements may require additional tooling, and SLSA hosts some supporting tools in its GitHub repositories. As mentioned in the description of Level 3, SLSA released a tool for automating provenance generation with GitHub Actions in February 2023.

To verify the SLSA provenance of a piece of software, you can use the slsa-verifier tool, which can verify a provenance generated by the slsa-generator tool or Google Cloud Build. Other tools, like Chainguard’s Enforce or Sigstore’s open source Policy Controller allow you to create policies around SLSA requirements in your Kubernetes cluster.

Developers are also encouraged to include the corresponding SLSA level badge (Level 1, Level 2, Level 3) in their README once their codebase meets the level’s requirements.

Learn more

In this guide, you learned about how SLSA helps secure the software supply chain, the requirements for its three build track security levels, and some of the tools used to implement or confirm these levels. This knowledge will help you work towards achieving SLSA levels for your software projects, assess external software based on its SLSA levels, and use admissions controllers to set SLSA-based policies in your codebase.

While SLSA provides a strong framework for verifying the authenticity and integrity of software, it is important to note that it does not protect against every type of supply chain attack. For example, SLSA requirements cannot prevent attacks enabled through vulnerable code, vulnerable build platforms, or collusion between high level actors. Still, SLSA offers a powerful framework for defending against common supply chain threats, and will likely emerge as a standard component of modern software as tooling and community adoption evolves.

To learn more about SLSA, you can visit the SLSA website, read an in-depth overview of SLSA requirements, or explore the SLSA repository on GitHub.