How Does SLSA Help Strengthen Software Supply Chain Security?

A relatively new way of strengthening your software supply chain security is to apply Supply Chain Levels for Software Artifacts (SLSA) in tandem with other tools such as software bills of materials (SBOMs), software composition analysis (SCA) for open source, and static application security testing (SAST) for proprietary code. Let’s take a look at what SLSA is and how its different levels work.

What is SLSA?

Supply Chain Levels for Software Artifacts (SLSA) is a security framework, a specification, and a common language designed to describe and improve software supply chain security. When deployed, it automates decisions about the integrity of the artifacts you are using and evaluates the trustworthiness and security of source code used in software packages. 

Released in June 2021, SLSA is a cross-industry collaboration, maintained as part of the Open Source Security Foundation (Open SSF). It is based on a framework inspired by Google’s “Binary Authorization for Borg,” which has been used by Google for nearly a decade and is required for all of its production workloads. Representatives from other companies such as Intel, VMware, and Datadog collaborate with colleagues at Google to develop and maintain SLSA.

SLSA’s design is based on automatically creating verifiable metadata, which helps implement security by getting the data needed to justify your policy decisions. It is organized into a series of levels that describe increasing security guarantees. We’ll look at these levels a little further on.

Why is SLSA necessary?

SLSA is necessary because the number of attacks against the software supply chain continues to escalate, and the gravity of those attacks is worsening. Hence, the need to safeguard the integrity of your source code, strengthen security, and avoid future breaches.

SLSA meets this particular need by providing a clear, consensus-based industry standard of compliance requirements and protection measures. As such, it’s a significant element of software supply chain security strategy, when working alongside other security tools and practices.

How SLSA works

SLSA delineates four key tracks and levels of software supply chain security, each of which provides increasingly strict and hardened security benchmarks and guarantees. To effectively implement SLSA, it is important to understand and address the security considerations at each level: 

Level 1: Source code build process documentation

Users start by identifying the provenance of the sources and dependencies of code in use and documenting the processes for building artifacts. Doing so provides a list of what is in the code, enabling users to better assess security risks and make security decisions. This information helps teams conduct code reviews, implement version control systems, track changes, and mitigate the risk of unauthorized modifications.

Level 2: Protection against tampering using a hosted build service

This level ensures that the build process is tamper resistant. It involves version control and the use of a hosted build service that creates “authenticated provenance.”

Using a version control service like GitHub or GitLab to track, manage, and record changes to  code builds a clear understanding of how an artifact was built and how it has changed. Using a hosted build service provides independent, third-party documentation of code provenance. This is more thorough than Level 1 because it verifies the build process and confirms the provenance by supplying an attestation to confirm adherence to the SLSA requirements.

An attestation is metadata that describes the artifact’s name, what it is, how it was produced, who produced it and generated the attestation, the event that started the build, and execution information that includes a record of the steps that were executed during the build. It also lists artifacts that were used as input.

This information is published alongside the associated software so that anyone who wants to use the artifacts can automatically verify them. Producing unsigned provenance satisfies Level 1 criteria because it offers basic code source identification and can aid in vulnerability management. However, you need verification and a cryptographic signature if you want to protect yourself from tampering and reach Level 2.

For example, if attackers try to get users to download a malicious package or a contaminated update, Level 2 involves a controller component that checks policy. This requires verification of provenance signed by the builder before the package can run. Attackers can’t fake provenance with stolen container registry credentials, so the controller blocks the use of the package and the attack is prevented.

Level 3: Hardening builds with extra protection

Implementing Level 3 means that a package has a verified source and build. It prevents tampering during the build and significantly reduces the impact of compromised package upload credentials by requiring attackers to perform a difficult exploit of the build process. It offers stronger protections than levels 1 and 2 by preventing specific classes of threats, such as cross-build contamination.

Level 3 applies more stringent standards that ensure provenance integrity and that the source can be audited.These standards include:

• Source-code verified history that is retained for 18 months. This ensures 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, which are independent of any other build instances, and can’t be impacted by them. An ephemeral environment is when you use a dedicated piece of computing that only exists for your build.
• Builds as code. In SLSA, build files must be treated like code by storing files in a version control system, so that any of these build processes can be recreated if required.
• Non-falsifiable provenance, which stops users from tampering with build service-generated provenance.

Level 4: Two-person review for the highest level of trust

This level requires two people to review all changes. The build process must be secure (hermetic) to guarantee that the list of dependencies is complete. Ideally, the process should also be reproducible because this attribute provides many auditability and reliability benefits, although it isn’t mandatory. This combination provides the highest level of trust and confidence.

SLSA forms part of software supply chain security best practice

Securing the software supply chain is vital. Organizations should employ secure build practices, such as using trusted build servers, verifying the integrity of source code and dependencies, and employing code signing to guarantee the authenticity and integrity of the resulting artifacts. Implementing the levels of SLS provides a thorough framework to address security considerations and should form part of a suite of software and application security best practices.

These best practices should include secure coding, dependency management, enforcing secure build processes, software composition analysis (SCA) for open source, static application security testing (SAST) for proprietary code, and ensuring secure distribution and delivery. By combining these tools and processes with SLSA, organizations can significantly enhance the security and integrity of their software systems. Proactive measures at each level help mitigate risks, safeguard against vulnerabilities, and ensure the trustworthiness of software artifacts throughout the software supply chain.

FAQs