Supply Chain Levels for Software Artifacts (SLSA)

SLSA’s two fundamental principles

SLSA contains two fundamental principles. First, non-unilateral changes to software artifacts are not allowed anywhere else in the development process. Second, software artifacts must meet specific requirements. In securing the software development lifecycle, SLSA simplifies software supply chain integrity requirements to benefit the industry and the open-source ecosystem. Figure 1 from SLSA.dev gives an overview of the well-known supply chain threats.

SLSA has defined four security levels as follows:

SLSA outlines four steps to becoming “SLSA Compliant.” Let’s cover these steps and dig deeper into what they mean for you. But, before we get started, let’s define what is meant by the term tamper-evident. It’s a term that will be used a lot in the coming sections.

SLSA Level 1 - Basic security steps

At SLSA Level 1 build processes should be fully automated and generate provenance. Using a “build script,” all build steps are documented. Consumers can use this information to make risk-based security decisions. Artifact provenance refers to a specific artifact’s history of ownership, custody, and origin. This first level is not tamper-evident and the requirements are best efforts.

Requirements
Build - Scripted build
Provenance - Available

To be level 1 compliant, you do not need a version control system (like Git) or a build system like Jenkins. SLSA 1 recommends a version control system.

The only hard requirement is for a build script and a centrally available report after the build that states: 1) the unique build itself, 2) where the build process was performed, aka provenance, and 3) repeatable instructions to execute the build.

Scripted builds

What does it mean to have a scripted build? Let’s explore this with another question. Do you build production software on a local machine by running commands? These commands may be as simple as a maven build, webpack compile, or docker build command locally.

SLSA Level 1 requires the execution of these commands to be managed in a reusable script such that anyone can run the script to repeat the build. The usage of centralized scripts reduces the probability that a given software artifact builds differently over time. If the build process changes because there is no consistency with how builds are done, you create the possibility for non-predictable behaviors from the very beginning.

There are many companies where this is a reality and it’s a security issue because the developer’s machine is vulnerable. Most likely, the developer uses their machine for more than just building software. If a malicious actor is successful at exploiting the developer’s machine, they can tamper with the build process. The result is a binary, built on a developer’s exploited machine, where the intruder can compile in code that compromises the confidentiality, integrity, availability, and safety of the software being built.

Provenance

Provenance is a fancy word for “the origin of something.” It identifies who built the software artifact and any additional metadata about the builder. This includes, but is not limited to:

Date and time of build
Artifact identifier, generally the SHA256 of the build software artifact
Name of the person doing the build
Contact information of the person doing the build
The machine the build was done on
A link to either the git repo or shared drive location of the build script used.

Here is a simple example showing how to document provenance. Generally, you’d want these to be machine readable. Although, if you are not using a version control system, which means you are storing your source code on a shared drive, or at worst on someone’s local machine, starting with human referenceable is a great entry point.

SLSA Level 2 - After the build

Version control and a hosted build service that generates authenticated provenance are required for this level. The build steps should run as a service, not on the developer’s computer. These additional requirements provide consumers with greater confidence in the software’s origin. A build service that is trusted prevents tampering at this level by enforcing provenance. The requirements for Level 2 are best effort for source and dependencies, but a higher level of credibility is needed for the build stage.

Requirements

• Source - Version controlled
• Build - Scripted build
• Build - Build service
• Provenance - Available
• Provenance - Authenticated
• Provenance - Service generated

The build

For the build the requirements are for a version control system and a remote build system. Simply stated, you need to manage your source code in either GitHub, GitLab, Bitbucket, or some other type of version control system. This can also be your company’s internally hosted Subversion system. The point of the version control system is to have a single source of truth for your source code where you can trace changes.

The term “hosted build system” may throw people off. At its simplest, it’s a common Jenkins instance where everyone in the company who builds software uses that instance. Level 2 means the end for local builds. All builds must be done via this hosted system.

Provenance

There are three extra requirements at this phase: Authenticated, Service Generated, and Identified Source Code. Authenticated Provenance is provenance which can be validated by someone else. What does this mean in practice? Let’s use an example.

If Danielle is responsible for deploying software as a release manager, she will want to validate that the software artifact she is about to deploy was indeed the one built by Bill. Danielle needs a way to independently obtain the provenance (the report we talked about in SLSA 1) and validate that it was indeed the one generated by Bill. To do this properly, the provenance should be signed by Bill at the time it’s generated. This leads us to the next requirement, Service Generated.

In SLSA 1, Bill could manually create the provenance and sign it, just like he’d sign any other software artifact, so that other people can validate that he was the person who built it. But, signing things locally is tricky due to the same issue we discussed about the developer’s machine being exploitable. A malicious actor could create false provenance and sign it with the developer’s keys if they are accessible from the developer’s compromised machine. This is why SLSA 2 provenance must be generated by a non-local service, and signed by the service as well.

Enhancing security with authenticated provenance

Let’s say that an organization has 100 developers and all of them are building locally right now. If a developer’s machine is exploited, the bad actor has a lot of leeway to move around and do bad things. The bad actor only needs to exploit one out of one-hundred machines. While some developers do not trust anything or anyone, there are many other developers who will happily click links on emails sent directly to them from unknown third parties.

Externalizing the build, provenance generation, and signing reduces the opportunity for a malicious actor to exploit software builds by making it far less likely for an exploited developer to be the entry point for the broader internal systems.

Lastly, there is identifying the source code. Quickly refer back to the SLSA Level 1 Provenance example. The only additional aspect to add here is a line that states the location of the source code. If can be something like this:

SLSA Level 3 - Back to source

At this stage you might be thinking that, with the possible exception of the provenance requirements, you are already meeting the SLSA requirements. In SLSA Level 3 you’ll start to encounter higher expectations. As a system moves towards Level 3, its builds become more reliable, its build definitions come from the source, and its continuous integration (CI) system becomes more robust.

At Level 3, build definitions and configurations are verified to be derived from text files stored in a version control system. An accurately derived definition can be fetched directly through a trusted channel, or from a trustworthy provenance chain that can be traced back to a version control system. The requirements at this level are best effort for dependency, higher credibility for the source, and the highest level (resilience) for the build stage.

Requirements

Source - Version controlled
Source - Verified history
Build - Scripted build
Build - Build service
Build - Build as code
Build - Ephemeral environment
Build - Isolated
Provenance - Available
Provenance - Authenticated
Provenance - Service generated
Provenance - Non-falsifiable

The build

SLSA Level 3 introduces the idea of ephemeral and isolated build environments. The goal of these two requirements is to 1) achieve complete separation between concurrent builds within a build system and 2) ensure that every time a build is run in an environment it is specifically for that build only, and not meant for any other type of work.
What’s important and different about these new requirements? Let’s start with what’s important. In many systems we run lots of different services and software on one machine. This makes it easy for an adversary to exploit the software being built on that machine by simply exploiting some other piece of software which is running on it at the same time.

Exploiting your server through a CVE

Let’s say your Jenkins instance is hosted on a Windows server. It’s the same Jenkins you’ve used at your company for the last 15 years. It gets upgraded frequently, and if it disappeared, the whole company’s software delivery would come to a screeching halt. But, that Windows server is also hosting many other types of software.

One particular piece of software is an internal app your team built as part of an employee reward program. This application is not updated frequently because it was simply a pet project. Over time, many Common Vulnerabilities and Exposures (CVEs) are recorded for the rewards app. But, you don’t consider this application to be critical or important, so you do not take any corrective action.

Denying horizontal access

One day, an adversary finds this application and leverages the CVE inside it to obtain access to the Windows server. The adversary has the ability to access your processes and figures out how to inject malicious code as your software builds. This code gives them the ability to see all unencrypted data being sent between your apps and their end users. This data isn’t only passwords and usernames, it’s personally identifiable data, as well as payment information. The perfect type of data to bundle and sell on the dark web.

The adversary can exploit everything you are building because they were allowed into your build environment through the insecure rewards app. It was a door into the machine your entire build system runs on.

To avoid an issue like this, being able to spin up machines and containers that cannot be horizontally accessed is a key trait of SLSA Level 3. If you have this system in place and an adversary is able to exploit one of your machines, the blast-radius is only limited to what was built on that particular machine or container. No other builds can be affected.

Provenance

Non-falsifiable is a quick way of saying, “You can’t say you didn’t do it.” What exactly do we mean by that? At SLSA Level 3, non-falsifiable provenance aims to ensure that once provenance is generated by the build service, on behalf of the builder (Like Bill in the SLSA 1 provenance example), the user cannot, with any legitimacy, say “No, that’s wrong.”

This is also where the idea of tamper-evident data comes into play. Let’s say Bill realizes something was incorrect after the build. He decides to go to the system generated provenance report and modify its contents. Bill then calls up Danielle to deploy the artifact. When Danielle runs her independent verification, she sees that the provenance was falsified because the provenance SHA that was recorded by the build system does not match the provenance SHA that Bill had her reference.

This simple example of Bill making changes could be far-fetched for some companies. A more realistic example is an adversary getting into the provenance data and mutating the data such that Danielle deploys a bad version of the software built by the build system, on behalf of Bill, without either of them realizing what has happened.

SLSA Level 4 - Across the Chain

In SLSA Level 4, the build environment is fully accounted for, dependencies are tracked, and insider threats are eliminated. The requirements at this level are higher credibility for dependency and the highest level (resilience) for the build and source stages. This is the first time that dependencies are properly addressed, and a requirement for two different trusted people to review a change is introduced. We also have two new concepts for the build process: hermetic and repeatable builds.

Requirements

Source - Version controlled
Source - Verified history
Source - Retained indefinitely
Source - Two-person reviewed
Build - Scripted build
Build - Build service
Build - Build as code
Build - Ephemeral environment
Build - Isolated
Build - Parameterless
Build - Hermetic
Build - Reproducible
Provenance - Available
Provenance - Authenticated
Provenance - Service generated
Provenance - Non-falsifiable
Provenance - Dependencies complete
Common - Security
Common - Access
Common - Superusers

Reproducible Builds

With reproducible builds your build process should be repeatable by someone other than whoever executes the build process on a daily basis. This is usually a very complex process because many of your builds have external dependencies such as build flags and argument attributes that can be changed by the developers. Even if your build script is fixed, the behavior of the script is subject to change depending on its input attributes.

SLSA Level 4 has a primary focus on ensuring that the exact same build behavior can be replicated by controlling the input factors that can alter build behavior. If the build is not intended to be reproducible, then provenance must state the specific attributes used for that build. Simply stating the attributes does not, in and of itself, guarantee a reproducible build. The only way to guarantee a reproducible build is to ensure all build logic is encapsulated in the build script, and that no external variables can alter the behavior of the script.

Hermetic Builds

A hermetic build is an airtight build process that does not allow anything in or out of the build while it’s processing. Every single dependency needed to build must be declared upfront. These dependencies include: the software being built, the tools used to build the software, build scripts, configuration files, and more.

When a hermetic build starts, nothing else can be pulled into the build process. SLSA Level 4 describes it as a build with no network access. In practice this means that once you have pulled in and verified every dependency you need to build the software, the network connection is such that nothing can access the build environment from the inside or the outside. When all dependencies are properly supplied, the build process happens within the environment without any need to access the internet to grab anything extra.

The Human Factor

The hardest part of hermetic builds is the human aspect. Hermetic builds require a complete knowledge of the build process and most people aren’t remotely prepared to understand their build process.

Furthermore, many teams and developers like to do things in their own unique way. Having a large number of unique ways to build means there is an exponential amount of information the organization needs to manage to execute its builds hermetically. Maturing and scaling to hermetic builds means that all of this build variation must be reduced to a small subset of standard build processes and technology.

DevOps Automated Governance and Kosli

In 2019 a team of software professionals including Michael Nygard, Stephen Magill, Sam Guckenheimer and John Willis produced a paper called DevOps Automated Reference Architecture, also known as DevOps Automated Governance (DAG).

It describes how to capture all the data required to ensure security and compliance to various standards. Using digitally signed events, they were able to first describe and then implement the automation of a tamper-evident environment.

Several banks implemented this architecture, and the results were described in the best-selling novel Investments Unlimited. In 2023, two of the authors of Investments Unlimited joined a Norwegian company called Kosli which was already working with European organizations to implement governance approaches similar to DAG..

Extending the SLSA framework with Kosli

In the table below you will see that Kosli, when implemented, meets additional requirements not specified in the SLSA framework. That’s because SLSA currently has a narrow focus on ensuring that the developer and build environment are remediated as exploitable vectors. High consequence organizations require additional attestations and gates which SLSA does not address.

There’s significant overlap between SLSA and other security/compliance models. For example, PCI-DSS, NIST 800-204C, and ISO27001 certification specify many of the same requirements. Many of these frameworks contain control objectives that cover the source, build, test, evaluation, and deployment of software. And, while introducing SLSA will definitely help to meet the expectations of such frameworks, there are still many aspects of provenance that need to be addressed.

In the table below are examples of further requirements that Kosli addresses, and how they map as extensions to SLSA. Kosli takes the SLSA framework beyond securing the developer and build system to ensure a broader security posture and compliance criteria.

The challenges with implementing SLSA

A very important thing to consider about SLSA is that it’s a framework and not an implementation guide. Although there’s some good advice and examples, an organization needs to use a number of different tools, including some internally developed tools, to implement a SLSA framework. This is where the challenge really begins.For example, most people will turn to their existing DevSecOps reference structure to start filling in the check boxes for SLSA requirements. For organizations of sufficient complexity this represents a huge task. See Figure 1 below.

Going through the Reference Architecture as a box checking exercise is an approach that introduces two problems. First, how do you record a tamper-evident ledger of all the complex attestations needed to ensure the provenance required? SLSA 4 has 21 requirements, while we have worked with organizations that have built over 50 attestations.

Second, how can you ensure that the actual evidence artifacts, for example, commit logs, build logs, vulnerability scan logs, etc., are archived, tamper evident, chained to the original attestation event, and most importantly, easily accessible for audit?

Figure 1 is probably more complex than that found in most organizations. However, it shows the level of complexity teams face when trying to find evidence.

Figure 1 - DevSecOps Reference Architecture

Credit: https://www.sonatype.com/

A sample audit email discussion

Evidence Vault - The Secure Source of Truth

Kosli has introduced something called Evidence Vault where every change made on your system, with the details of all of the required attestations for that change, is one click away (see Figure 2). Then, from the attestation, you are only one click away from the actual artifact of the evidence (see Figure 3).

Figure 2 - Kosli, Evidence for ‘audit-package’

Figure 3 - Digitally signed