How to Secure Your Software Builds with SLSA

Since its original announcement by Google in June of 2021, Supply Chain Levels for Software Artifacts (or SLSA, which is pronounced “salsa”) has been adopted by some very large and respected organizations. One reason for its solid rate of adoption is that it’s backed by Google, which has a good track record for fixing large-scale problems, but the main driver might actually be the fact that it was released at just the right time. In the last 2 to 3 years, attacks on the software supply chain have increased by an average 742% as bad actors have discovered the economies of scale that come with attacking a software vendor in order to compromise their software, which is then propagated downstream to their customer base.

Following the very public supply chain attacks on SolarWinds, CodeCov, Kaseya and others, as well as the US government’s requirements for securing the software supply chain, the technology industry as a whole has begun to take seriously the call for massive improvements in the security of their software supply chain.

What Is the SLSA Initiative?

SLSA is a joint effort by Google, the Linux Foundation, as well as many industry-representative organizations to create an end-to-end framework that can ensure security and integrity through all stages of the software supply chain. The goal is to have this framework incorporated into the software development process in general, and build systems in particular, throughout the industry. The thinking is that Integrating integrity requirements and controls into the source → build → release pipeline for software products is the best way to ensure the software supply chain is secure and trustworthy.

SLSA is based on Google’s experience with its own in-house Binary Authorization for Borg process. They’ve used this authorization practice internally for nearly a decade to ensure that only known and approved binaries are included in any builds that are executed. But to ensure the SLSA initiative isn’t just Google pushing their best practices on the rest of the software industry, they’ve involved the likes of Citibank, Intel, Datadog and others to lend SLSA a measure of neutrality, as well as to ensure that it won’t be controlled by any one vendor moving forward. If this situation seems familiar, that’s because it is: when Kubernetes came on the scene, Google and the Linux Foundation worked together to form the Cloud Native Computing Foundation (CNCF) to promote the advantages of Kubernetes to a wider audience.

Advantages of Building with SLSA-Compliant Systems

The number one advantage of having a build system that complies with any of the SLSA maturity levels is the ability to:

• Automate software builds 
• Validate everything going into the build 

This way, you can be confident that the software you are giving your customers only contains the components you selected and used during your development and testing processes. You can also be sure that you alone are in control of the dependencies that go into the application, and that the binaries have not been modified in any way (maliciously or otherwise).

If a vulnerability is identified in any component, it’s much easier to update dependencies and create another build of the application since you have automation around the build process. For example, you could search through the provenance that your builds have created to find out where log4j is being used, as well as which versions of it are being used. Then, you could update the dependency version in the affected applications and run the build again. Thus, issues can be fixed within a few minutes of the initial notification.

The higher levels of maturity in the SLSA framework add extra guarantees and control points to ensure more centralized oversight and reproducibility. This means that previous releases can be updated and rebuilt if a client cannot migrate/update to the latest release for some reason.

SLSA Maturity Levels

The SLSA framework offers several maturity levels for security-conscious organizations to aspire to, but even attaining just SLSA Level 2 can mean your processes are in very good shape. Large organizations that want to work with new technology/external auditors will likely start to look for SLSA 3 and higher (along with other industry standards like SOC-2, FIPS 140 and CMM).

Level	What Is Involved?
0	There are no security and integrity guarantees wrt to built artifacts. SLSA 0 is where most organizations will find themselves starting out.
1	The build process must be fully scripted/automated and generate provenance.
2	The source code must be version controlled, and the automation scripts for the build must be run by some kind of dedicated build service.
3	A few additional standards are added into the mix, but the big jump to get to SLSA 3 is moving from self-auditing to being audited by an external auditor.
4	To reach level 4, you must have the rest of the specifications in place, such as two-person code reviews. In addition, all builds must be reproducible.

SLSA Source Requirements

As an organization moves into higher SLSA maturity levels, there is an increased focus on not only tracking the history of changes within the source repository in an immutable way, but also having more structure around who can approve changes that will eventually appear in the build. 

Any modern version control system (like Git or Perforce) will include the functionality to track the version history required for SLSA by default. In Git, that history can be viewed by retrieving commit IDs which are unique to one specific change in the source repository. For higher levels of maturity (like SLSA 3), you’ll need to use strong authentication with timestamps for the reviews. 

SLSA Build Requirements

Level 1 simply requires that you have a way to build your artifacts automatically, and that your build produces provenance in the form of metadata. That metadata needs to include details about which source code was used in the build, and which dependencies are included. Much of this information will overlap with the information that would typically be found in an SBOM, but they serve different purposes. 

The higher levels of maturity require that your build is not only reproducible, but that ephemeral  environments are used throughout the build process. To get to the highest level, your build must be able to run and successfully complete without requiring any parameters or other user inputs.

Conclusions: Getting Started with the SLSA Framework

SLSA may seem daunting at first glance, but it really won’t take much for most organizations to get to Level 2. Any organization that uses modern application development practices, and has a CI/CD pipeline in place has already laid much of the required groundwork, allowing you to focus on the extra features.

Some good places to start include:

• Read the original blog post (from June of 2021) in which Google first announced that they were “Introducing SLSA, an End-to-End Framework for Supply Chain Integrity” in conjunction with the Linux Foundation. 
• The SLSA framework’s website, SLSA.dev, hosts a lot of documentation, including the specification, use cases, and a guide to getting started. 
  • The latter is of particular interest, since it contains more details about the sections of the specification and what’s required to make the journey through the maturity levels. It also has information about available tools that can help you get there. 
• The slsa-framework repo on GitHub contains documentation and examples.

On the other hand, if you prefer to get started right away, you can leverage an out-of-the-box solution like the ActiveState Platform. It includes a secure build service that automatically builds open source components from source code in a manner that adheres to the requirements for SLSA Level 4.

Read Similar Stories