Understanding the SLSA framework

If writing secure software is difficult, securing software build pipelines and supply chains can be even more challenging. The Software Supply Chain Levels for Software Artifacts (SLSA) has emerged in response to recent large-scale public attacks on digital infrastructure. It provides an industry-wide structured approach to fortifying software supply chains against threats, and is designed to evolve to address new threats as they arise.

If you’re looking for assurances that the open-source software you’re using is secure, find yourself needing to assess the security of your software vendors, or want to protect your internal systems and software from supply chain attacks, you'll likely want to learn more about SLSA. 

What is SLSA?

Pronounced “salsa”, SLSA is an open-source framework that helps you secure your software delivery pipelines to better protect yourself and your users from serious risks. SLSA is based on security practices developed internally at Google and has been developed in public since 2021. It was initially released as a response to the massive security breach now known as the SolarWinds attack (which we’ll cover below). 

SLSA is stewarded by the Open Source Security Foundation (OpenSSF) and governed by a diverse industry-wide group of specialists. As a relative newcomer on the security scene, its evolving definition targets threats to software supply chains—something not covered well by existing efforts like NIST, SSDF, and PBOM.

How SLSA works

SLSA provides documentation, automated tooling, and in-depth guidelines to help teams evaluate and communicate the security level of software artifacts and their dependencies. 

SLSA advocates for evaluating each software artifact independently; it does not endorse transitive trust. The SLSA level of your dependencies and build tooling helps inform the security of your software artifacts without guaranteeing it. 

Practitioners can self-evaluate or audit others, and you should be able to use SLSA’s language to quickly and effectively communicate about how secure your software is, what you’re expecting from third parties (such as software vendors and OSS), and the security of the software you’re providing to your customers.

SLSA tracks and levels

SLSA evaluations are organized along tracks and levels. Each track in SLSA addresses a different aspect of the software supply chain, and levels in a track indicate an artifact’s maturity therein. The currently published version (release 1.0) focuses on the “Build” track, and details four levels, from 0 to 3. Future releases will introduce additional levels and tracks (under active consideration: "Source" and "Platform Operations").

The levels within the SLSA Build track are designed to classify artifacts based on how secure the build pipeline is, and provide requirements for build systems. 

• Level 0: No assurances. The baseline level for software artifacts with no security measures in place.
• Level 1: Basic security and provenance (protects against accidents). This level focuses on documentation and consistency. Builds are consistent—artifacts only change when their source code changes. Artifacts are tagged with documentation about how they were built (i.e., provenance), and this documentation is accessible for audits.
• Level 2: Enhanced security enforcement (protects against common attacks). This level focuses on authenticity and preventing post-build artifact tampering. Software artifact provenance should be signed, and builds use tamper-resistant platforms.
• Level 3: Comprehensive security controls (protects against concerted attacks). This level focuses on tamper prevention during the build process. Artifact provenance and documentation should be made hard to forge. Build systems compliant with this level provide advanced protections, such as stringent access controls and a secured and hardened environment.

A proposed Level 4 will likely focus on aspects like the consistency and integrity of build environments and require adopting more complex protective measures such as hardware attestation and reproducible builds.

Core principles

The Build track levels above embody SLSA’s three core principles:

Trust platforms, verify artifacts

Validating platforms is time-consuming and difficult. SLSA encourages adopters to minimize the number of platforms used in a build system and to prefer shared and hosted platforms over self-managed ones. This makes auditing and securing platforms more efficient since platform users can coordinate and share related costs. For artifact verification, SLSA is biased toward automatic and rapid verification, and provides some standard tools and guidelines for the work.

Trust code, not individuals

Individuals are difficult to vet and audit—and even vetted and trusted individuals can make mistakes, be temporarily compromised, or unintentionally contribute to malicious updates in other ways. SLSA believes it's more efficient to audit, validate, statically analyze, and develop trust in written code. Code changes can be evaluated more efficiently—piecemeal, on a per-change or per-update basis.

Prefer attestations over inferences

Securing and trusting systems is difficult—systems may operate as expected but still produce compromised artifacts. SLSA is built around the idea that it is much more efficient and easy to check each artifact and audit its build process than to attempt to (automatically) infer whether an artifact is secure by auditing and analyzing the systems and people involved in building it.

How SLSA is used today

Companies may use SLSA to assess their internal infrastructure, highlight security status, and identify gaps. Or they might use it to audit software vendors, suppliers, and external dependencies. At a high level:

• Participation and use of SLSA are voluntary.
• There isn’t (yet) a formal certification process for SLSA. Companies may self-assess or run audits for each other.
• OSS software, build platforms, and industry insiders are gradually documenting their compliance levels and other contributions to supply chain security to build trust—e.g., Buildkite, Chainguard Academy, Eclipse Temurin, Tekton, and ActiveState.

Key terms

SLSA uses some specialized language and terminology. The most important concepts and terms include:

• Software artifact: A file or bundle resulting from a build process. Examples include binaries, container images, and software packages.
• Software supply chain: All the steps and activities used to make and deliver software artifacts. This includes writing code and using libraries and tools produced by others, code repositories, build systems, package managers, and deployment mechanisms.
• Auditability: The capacity to know about, inspect, and verify each step in a supply chain, usually to check compliance with security practices and standards.
• Attestation: Machine-readable and cryptographically signed data associated with a specific software artifact. It usually provides security-related context, such as what the artifact contains, how it was produced, and how it might be used.
• Provenance: An attestation that describes how, where, and by whom an artifact was produced, and which other artifacts were involved in its production.
• Build process integrity: The extent to which a build process hasn't been tampered with.
• Reproducibility: The ability to produce identical artifacts from the same source code and build environment.
• Hermetic builds: Builds that are entirely self-contained, consistent, and 100% reproducible. They do not depend on external factors like network access or the state of the build environment. 
• Two-person review: A process where at least two individuals review—and then verifiably sign off on—change proposals to a system before they are incorporated.

What threats is SLSA designed to address?

SLSA aims to protect supply chains against a full range of pervasive and sophisticated threats. It can guide your defense from vulnerabilities introduced through dependencies, build system compromises, code injection, and various insider threats. 

Real-world supply chain attack examples

Below are some examples of the kinds of attacks SLSA addresses today. (Over time, these will expand.)

Build process compromise

The now-canonical example of a supply chain attack, the SolarWinds hack from 2020, exposed the systems and data of more than 18,000 public, private, government, military, and other highly sensitive organizations. Attackers compromised the build processes at multiple companies, including SolarWinds, which allowed them to issue a malicious update to SolarWinds’s Orion IT software. The update was quickly installed worldwide and provided hackers with significant systems and data access. This hack prompted the creation of the SLSA framework, and its Level 2 and Level 3 build-process controls are designed to prevent and mitigate future similar attacks.

Malicious artifact injection

In an example from 2021, attackers gained access to Codecov’s software delivery systems and were able to replace one of Cocodev’s tool offerings with a malicious artifact. Most of Codecov’s 23,000 clients used the tool in automated scripts as part of their software build chains and were compromised in the attack.

The initial security breach would have been mitigated with the security controls SLSA recommends for build processes. The malicious artifact injection was ultimately detected through a basic provenance check (checking the SHA signature of downloaded software against the expected signature). SLSA formalizes provenance and attestation processes as part of Build Level 2.

Chained dependency and code injection into released artifacts

An attack from 2018 called the event-stream incident is an example of chained dependency and code injection through a compromised open-source software project. 

Hackers tried to steal data and cryptocurrency from the users of an app called Copay. They modified the popular event-stream package to include a new dependency in its build. Most developers didn’t notice, because the dependency only introduced malware when included in the Copay application. 

This complex attack would be detected and prevented with the optional recursive check included with regular SLSA 1.0 audits. It’s a check that explicitly catches chained dependency attacks by recursing through and validating all dependencies.

Malicious code injection and insider tampering

In a sophisticated attack from 2024 known as the XZ Backdoor attack, state actors created a fake persona and spent four years gaining trust and contributing to a popular open-source compression library called XZ Utils. They added thousands of legitimate contributions and code to many projects before making a camouflaged malicious update.

SLSA Build Level 3 protections and recursive SLSA audits provide some protection from these kinds of attacks. As a wider portion of the industry audits, reviews, and ensures the OSS tools they use are properly authenticated and attributed, this kind of attack gets harder to perform and to keep hidden. The proposed Build Level 4 would also increase protection from this type of attack, for example by encouraging hermetic builds. (Once code has been reviewed and audited, a hermetic build guarantees it hasn’t been tampered with, no matter who builds it.) Future SLSA versions will require auditable, authenticated, and verified two-person reviews for code changes, targeting attacks like this.

How to get started using SLSA

SLSA is designed with ease of adoption in mind. Moving up through Build track levels (and implementing future tracks once they’re released) should feel as minimally invasive as possible. Let’s look at how you might go about adopting SLSA on your own.

Educate and self-evaluate

To start adopting SLSA into your software supply chain, take inventory of your software artifacts and build chains. List all the components and artifacts and assign a SLSA level to each one based on its current state. Questions like "How critical is this artifact to our operations?" or "What level of exposure to risk does this artifact have?" can help guide your evaluations and prioritize compliance work to improve SLSA levels for artifacts.

Once you have an inventory for your systems, you can begin implementing automated verification tools across your codebase. SLSA provides some examples, like the SLSA-verifier on GitHub, that help check compliance with SLSA standards and identify improvements.

Having verified your artifacts to determine the baseline, you can now set a target SLSA level for each artifact. Your business needs will dictate priorities and naturally lead to a strategic plan with actions to move each artifact to its target level. The SLSA team provides example tools, references, and guidelines for how this work can be efficient, quick, automated, and scaled up.

Implementing SLSA will be a continual effort. Regularly review your progress and watch for developments in the specifications. Adapt your security strategy to match the standards as they change, and your software supply chain will remain resistant to emerging threats.

Implement the SLSA Build Track

Here’s an overview of the kind of work required to implement each level of SLSA’s Build track. For more information, refer to the how-to guides on the SLSA website. 

Level 0

• Do nothing. This level indicates there are no SLSA assurances in place.

Level 1

• Identify your build artifacts, and automatically generate, log, and distribute standardized provenance metadata.
• Standardize and document all build processes for auditability. 
• Monitor the supply chain to detect inconsistencies. 
• Use tools like GitHub Actions or Buildkite Package Registries, which has built-in support for SLSA Build Level 1.

Level 2

• Sign provenance data, attestations, and artifacts with cryptographic signatures for integrity validation and continuous monitoring.
• Secure and centralize the build process, ensuring auditability and tamper resistance.
• Consider tools like Windows signed attestation, IPFS Signed Attestation plugin, and public attestation repos like Rektor.

Level 3

• Harden build platforms with regular audits and updates, ensuring documentation authenticity. 
• Automate validations and checks to prevent tampering. 
• Continuously audit the build process, follow relevant hardening guidelines, and consider resources like SLSA attestations for toolsets (e.g., for flux).

Level 4 and beyond (future)

• Implement hermetic builds, and add audits and attestations to your build frameworks.
• Clearly define roles, responsibilities, and processes for SLSA enforcement and monitoring.
• Resources include tools like Bazel (for hermetic builds) and the OWASP Kubernetes security cheat sheet.

Keep up to date with SLSA

SLSA is maintained and modified in the open, and its administration follows public OpenSSF standards. The team behind SLSA includes a steering committee, specific working groups, and community contributions. You can contribute directly, and there are many ways to keep up to date with their work:

• Regularly look for changes posted to the authoritative location for SLSA, https://slsa.dev. Updates are available in both human-readable and machine-accessible formats. (As time of writing, the SLSA v1.1 draft is available for public review.)
• Refer to the SLSA blog for regular updates, directions, and feedback requests.
• For more granular updates, see the weekly meeting notes published. 
• Review the changes to the SLSA standard that are suggested, processed, and accepted via pull requests against https://github.com/slsa-framework. 

Buildkite Package Registries: Built-in support for SLSA provenance

Buildkite complements SLSA and can help accelerate your adoption. Buildkite Package Registries includes native provenance support features that are easy to cryptographically sign, artifact signing (for SLSA Level 1 and 2 support), and dependency management (supporting audit efforts). 

If you're looking to boost your software's security framework, consider exploring how Buildkite can help enhance your SLSA efforts. Check out the docs to learn more and get started. 

Summary

SLSA is a security framework designed to protect software-delivery supply chains from vulnerabilities and targeted attacks:

• It has structured and standardized security levels (0→3) for its Build track.
• Its levels are designed to be adopted incrementally, with each level extending lower levels.
• Implementing its guidance and complying with the requirements of each level increases the security and stability of your builds.
• SLSA provides a clear and optimized path toward securing build chains and their dependencies.
• Buildkite Package Registries offers built-in support for SLSA provenance and attestation.