SLSA — which stands for Supply Chain Levels for Software Artifacts — is a framework designed to help organizations improve the integrity of their software supply chains. Along with automated testing tools, secure coding practices, and strong third-party software vetting, SLSA can be an important part of a comprehensive software supply chain security strategy.
SLSA is organized by levels, where each level represents incremental progress from the previous. The higher the level, the more confidence that the software process has not been tampered with.
The aim is that fulfilling the framework’s requirements will help companies avoid the next SolarWinds-type software supply chain attack, where a bad actor inserts malicious code into a piece of software. SLSA, in fact, helps protect against a range of software supply chain attacks.
In this blog, we’ll break down each level of the SLSA framework, along with concrete activities that can help organizations fulfill requirements. We’ll also touch on SLSA’s history and benefits.
Editor’s Note: This post was produced in partnership with our friends at Chainguard, a software supply chain security company. Chainguard helps customers navigate the SLSA framework and improve the integrity of their software supply chain. For SLSA consulting services or product demos, send them a note at https://www.chainguard.dev/contact.
History of the SLSA Framework
SLSA was released in June 2021 by Google’s security team. The framework was inspired by Google’s “Binary Authorization for Borg,” which has been used for nearly a decade (and is required for all of the company’s production workloads).
SLSA was launched during a particularly challenging year for software supply chain security — the SolarWinds and Codecov bash uploader exploits were disclosed in the months preceding SLSA’s release. Google announced the creation of the framework in a blog post, which reads in part:
The goal of SLSA is to improve the state of the industry, particularly open source, to defend against the most pressing integrity threats. With SLSA, consumers can make informed choices about the security posture of the software they consume.
The current SLSA framework is version 0.1, but version 1.0 is in development. Representatives from companies such as Google, Intel, VMware, and Datadog are helping steer the new version. There are currently no plans for an official SLSA certification program (though that could change in the future), but self-certification is an option.
SLSA Framework Benefits
All organizations that develop software want to develop secure software. Producing an application with malicious code can have devastating consequences. It can lead to significant loss of current and future revenue (due to customers leaving and reputational damage), not to mention damage to the health of the broader software ecosystem.
So, at a very basic level, organizations that fulfill SLSA requirements will likely be better equipped to prevent tampering with their software. Additionally, manufacturers that fulfill the framework’s requirements can highlight this achievement as proof of their commitment to security. This can come in handy during conversations with prospective customers, especially those of the security-minded variety.
SLSA Framework Levels
The SLSA framework starts at Level 0 — which essentially means that an organization hasn’t fulfilled any requirements — and ends at Level 4. Let’s look at the requirements for each level and what your organization can do to fulfill them.
Level 1
Level 1 of the SLSA framework is a building block step. Think of it as laying the foundation so you can create a secure software pipeline. Level 1 requires organizations to complete two key activities: Fully script or automate your build process and generate provenance documentation
Fully script or automate your build process: There are several ways to complete this step. Old-school developers might prefer to use a makefile to automate their builds. New-school programmers often use GitHub Actions to accomplish a similar objective.
Generate provenance documentation: Provenance is a somewhat new term in software development, but it essentially covers the “who,” “where,” and “when” of a piece of software. SLSA defines it as “metadata about how an artifact was built, how an artifact was built, including the build process, top-level source, and dependencies.”
Perhaps the simplest way to fulfill the Level 1 provenance requirements is to use GitHub Actions or a similar tool. This way, as you create a release, your release automatically generates a document that says, essentially, “GitHub Actions built this at this time using these inputs with this command.”
Level 2
Level 2 of the SLSA framework is focused on making sure your build process is tamper-resistant. This step has two primary requirements:
- Use version control
- Use a hosted build service that creates “authenticated provenance”
Using version control: In practical terms, this means using GitHub or GitLab (or a similar service) to track, manage, and record changes to your code. This ensures you can understand how the artifact was built and what changed along the way.
Using a hosted build service that creates “authenticated provenance”: Like Level 1, Level 2 of the SLSA framework also has a provenance requirement. The difference is that Level 2 requires provenance documentation to be authenticated via a hosted build service.
In theory, you could satisfy Level 1’s requirement by using a makefile to automate your build and then creating a document on your system with relevant provenance metadata. When you use a hosted service, a trusted third party can vouch that the build process happened as the provenance document says it happened. We’ll again highlight GitHub Actions as an example of a hosted service that can create authenticated provenance. When you use GitHub Actions, a process runs on GitHub’s servers to document your build’s “who,” “where,” and “when.”
Level 3
Level 3 is where we start to see the meat of SLSA’s security controls. It requires “source and build platforms meet specific standards to guarantee the auditability of the source and the integrity of the provenance respectively.”
Specific requirements in Level 3 are as follows:
- Source code verified history
- Source code retained for 18 months
- Isolated builds
- Builds in ephemeral environments
- Builds as code
- Non-falsifiable provenance
Source code verified history and retention: SLSA defines “verified history” as ensuring each code change is accompanied by a “strongly authenticated actor identity” (such as an author, reviewer, or uploader) and timestamp. Those identities are required to use two-factor authentication. This revision and change history must be retained for at least 18 months.
Isolated builds in ephemeral environments: Like the term suggests, isolated builds are completely independent of (and cannot be impacted by) any other build instances. Ephemeral environments exist when you use a dedicated piece of computing that only exists for your build. Using a service, like GitHub actions, that leverages a virtual machine or container to spin up your build on-demand — and then disappear after it’s complete — is a good way to fulfill this requirement.
Builds as code: SLSA calls for treating build files like code by storing these files in a version control system. This requirement helps ensure that build processes can be recreated if need be.
Non-falsifiable provenance: This requirement is intended to prevent users from tampering with build service-generated provenance. One SLSA-related project based on GitHub Actions provides the tools for accomplishing this requirement (and others).
Level 4
The final level of SLSA’s framework is intended to give “the consumer a high degree of confidence that the software has not been tampered with.” Level 4 requirements include:
- Two-person review of all changes
- A parameterless, hermetic, and reproducible build process
- Provenance documentation that captures all dependencies
- Common security, access, and super user requirements
Two-person review of all changes: This is more of a logistical challenge than a technical one. It requires organizations to identify trusted, qualified reviewers — and to make sure they have the bandwidth to conduct a thorough review. The developer proposing the change can count toward the two-person total if that developer is trusted and authenticated.
Parameterless builds: SLSA defines parameterless builds as occurring when “the build output cannot be affected by user parameters other than the build entry point and the top-level source location. In other words, the build is fully defined through the build script and nothing else.”
For example, in GitHub Actions, workflow_dispatch inputs are required to be empty. Similarly, in Google Cloud Build, user-defined substitutions must be empty.
Hermetic build process: Per O’Reilly’s “Building Secure & Reliable Systems,” hermetic builds can be defined as:
All inputs to the build are fully specified up front, outside the build process. In addition to the source code, this requirement applies to all compilers, build tools, libraries, and any other inputs that might influence the build.
Hermetic builds are designed to be self-contained and to “guarantee integrity of third-party imports—for example, by verifying cryptographic hashes of dependencies or by requiring that all fetches use HTTPS and come from trustworthy repositories.”
Reproducible builds: These are also based on verification, but they are different from hermetic builds. A reproducible build produces the identical, byte-for-byte output regardless of where or when it’s run. Successfully designing reproducible builds can be difficult, but we’d recommend you view our blog post “Three Pillars of Reproducible Builds” as a starting point.
Note: This is considered a “best effort” requirement. If you aren’t able to achieve a reproducible build, you can be exempt if you produce justification explaining why.
Jessica Black
Common Requirements: Finally, Level 4 introduces several “common requirements,” which apply to “every trusted system involved in the supply chain (source, build, distribution, etc.)”
Common requirements cover three specific areas:
- Security: Systems meet a to-be-determined set of security standards to safeguard against compromise. SLSA mentions NIST SP 800-53 as one possibility.
- Access: All access (physical and remote) should be assigned on a least-privilege basis. Access should also be logged and require multi-party approval.
- Superusers: The number of superusers — i.e. platform admins — should be small. And, any superuser who wants to make changes to the aforementioned safeguards must get approval from a second superuser.
SLSA: The Bottom Line
Although SLSA v 0.1 is a work in progress, the framework includes several practical requirements that can help organizations strengthen their supply chains. And, even if you can’t fulfill all of the framework’s higher-level requirements today, SLSA offers a path forward to help organizations achieve meaningful improvements to supply chain integrity.
For more information on SLSA and software supply chain security, consider viewing these related resources.
