SLSA: Supply Chain Levels for Software Artifacts

SLSA: Supply Chain Levels for Software Artifacts

The software supply chain has come increasingly under attack in recent years, with attacks on software dependencies and build systems alike resulting in damaging breaches that have impacted tens to hundreds of thousands of customers and users at a time.

Supply Chain Levels for Software Artifacts (SLSA) is a security framework that helps ensure the integrity of software artifacts, serving as a mode of evaluating trust in a particular software artifact. It helps you assess if the code you’re using is tamper-free and offers a way to evaluate if the source code or build system used to create software packages is trustworthy. It aims to help secure the software supply chain against attacks by providing a model for security capabilities throughout the supply chain (the current SLSA framework focuses on the build stage). The OpenSSF launched SLSA in 2021.

What differentiates SLSA from other security guidelines is its design based on automatically creating verifiable metadata rather than simply providing a list of best practices. This metadata is useful for making policy decisions. SLSA goes beyond describing the process required to secure the software supply chain—it helps you implement security in the real world and obtain the data to demonstrate it.

SLSA Framework: Levels

The SLSA framework for the build track has four distinct levels:

• Level 0 — No assurance.
• Level 1 — Documented provenance of a package’s build process, helping to identify mistakes and to provide documentation for future reference.
• Level 2 — Associates identities and systems with the software. It entails cryptographically signed provenance, generated by the build system, which aims to detect tampering after the build process.
• Level 3 — This level is meant to detect tampering during the build. It enforces security at the individual build levels to help prevent attacks against the build systems themselves (malicious builds can’t affect other builds in the system).

Using SLSA for Securing The Software Supply Chain 

SLSA is only useful if someone is inspecting and verifying it. Organizations adhering to the SLSA framework need to be able to verify SLSA attestations and ensure provenance values match their standards. It’s expected that verification is performed automatically by tools and that expectations are formed by trusted authorities (package registry) or automatically (to detect unexpected changes). Here is a look at some of the capabilities needed.

Generate a SLSA attestation during the build process

Harness SSCA, for example, when used with Harness CI Hosted Builds (Harness Cloud), ensures that the resulting artifacts have SLSA Level 3 provenance that every consumer (including the following deployment stage) can verify for artifact integrity prior to making use of this artifact. Build hardening for Level 3 compliance is achieved through:

• Built-in infrastructure isolation for every build where new infrastructure is created for every run and deleted after the run completes.
• OPA policy enforcement on CI stage templates with non-privileged, hosted containerized steps that do not use volume mounts. This disallows the build steps to access the provenance key information in compliance with SLSA specifications.

The end result is that attackers cannot tamper with the build process.

Verify a SLSA attestation and Enforce Governance Policies

SLSA attestations should be verified in either the build stage or deploy stage, and then be subject to policies that permit or deny the use of the artifact based on whether or not the artifact’s provenance meets your criteria. For example, you may only want to allow the deployment of software artifacts from a specific build repository and branch. When the pipeline runs, the authenticity of the SLSA attestation will be verified, along with the provenance data within it.

Learn More About How Harness Software Supply Chain Assurance Allows You To Govern Artifact Promotion Based On SLSA.

‍