The SolarWinds attackers didn't break in through a vulnerability in the product's code. They compromised the build pipeline and injected malicious code into a legitimate, properly signed release - one that sailed past every signature check because the signature itself was valid. Traditional code signing had no answer for this, because it only guarantees who signed something, not how it was built.

That's the gap the Supply-chain Levels for Software Artifacts (SLSA) framework was designed to close. A build process meeting SLSA Level 3 - with isolated, ephemeral build environments - would have made that kind of injection significantly harder to pull off undetected. This post explains what SLSA is, what it guarantees (and doesn't), and the real-world challenges of adopting it in enterprise settings

What is SLSA?

Modern software supply chains are complex. Build systems, CI/CD pipelines, and third-party dependencies form a large and often opaque attack surface. High-profile incidents like SolarWinds and multiple dependency confusion attacks showed that securing source code alone is insufficient if the build and distribution process itself cannot be trusted.

The SLSA framework, originally introduced by Google in 2021 and now maintained under the Open Source Security Foundation (OpenSSF), addresses this gap. It defines a set of incremental security properties for build systems - a maturity model with levels that describe increasing degrees of assurance.

SLSA is a security framework, a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure.

Its requirements have been refined by security experts from Intel, The Linux Foundation, Google, the Cloud Native Computing Foundation, and others.

Key Concepts

Before going further, two terms worth understanding:

• A Provenance is a machine- and human-readable file describing where, when, and how a software artifact was produced - typically including the source code repository and revision, the build definition, and information about the build system.

• An Attestation is a digitally signed provenance.

The Three SLSA Build Levels

SLSA defines three incremental levels for build security:

Build L1 - Provenance exists

A provenance document exists, though its contents are not yet considered fully trustworthy or complete. If you've already automated your build process, you likely satisfy this level.

Build L2 - Hosted build platform

The build ran on a hosted build system (not a developer's local machine), the provenance was generated by a trusted system (such as the build platform itself), and it is signed - making it a proper attestation.

Build L3 - Hardened builds

The build ran in an isolated, ephemeral environment - free from caches, remote sessions, and interference from other builds. A fresh environment is provisioned for every build.

What a SLSA Attestation Does (and Doesn't) Guarantee

A SLSA attestation at Build L2 provides confidence that the software artifact was built from the intended source code. Build L3 adds assurance that the build environment itself was hardened against tampering.

What SLSA build attestations do not cover:

• Whether the source code contains vulnerabilities

• Whether source code was reviewed (that's the domain of SLSA's Source Track, covered separately by build policies)

• Which dependencies are included (that's where SBOMs come in)

• Whether the software came from a trusted publisher (that's what traditional code signing addresses)

SLSA is one important piece of a broader supply chain security picture - not a silver bullet.

Why It Matters

SLSA gives customers, operations teams, and auditors a standardized, automated way to verify that software build processes comply with security standards. The axios example in section 3 illustrates this well: when attestations are present and routinely verified, malicious releases can be caught and blocked automatically - even when the attacker has valid publishing credentials.

The US Executive Order on Improving the Nation's Cybersecurity (May 2021) affirmed the need for exactly this kind of universal framework - and industry adoption is growing.

Real-World Challenges in Enterprise Adoption

1. SLSA Was Designed for Open Source - Enterprises Are Different

SLSA's original design assumes that build infrastructure and source code details are publicly visible, which works well for open-source projects. For most enterprise organizations, sharing that information isn't feasible.

SLSA addressed this with the concept of a Verification Summary Attestation (VSA). A trusted third party verifies the SLSA attestations and produces a concise summary - effectively a certified statement that a given artifact meets a specific SLSA Build Level.

This matters for two reasons:

1. Consumers of the software get confirmation from a neutral party that it was built to a recognized security standard - enabling standardized, automated audits.

2. The attestation can be distributed and verified without requiring any knowledge of the producer's internal pipeline.

2. Build System Support Is Fragmented

Every team uses different tooling. GitHub Actions, GitLab CI, TeamCity, Azure DevOps - the list goes on. Very few of these systems can produce SLSA attestations natively, and even fewer can sign them (a requirement for Build L2).

Organizations adopting SLSA face the task of auditing every build system they use, understanding how each one implements attestations, and adapting every build pipeline accordingly. This is a significant operational undertaking without centralized tooling.

SignPath provides SLSA attestation generation for a growing range of build systems, with centralized control that can be enforced consistently across every release.

3. Attestations Are Only Valuable If Someone Verifies Them

This is the industry's most under-discussed problem. You can have perfectly generated, signed, high-level SLSA attestations - and gain zero security benefit if nothing in your deployment pipeline actually checks them.

The axios case is instructive again: the mechanism to catch the malicious release existed. NPM supports SLSA attestations. The legitimate releases had them. But routine, automated verification wasn't in place at the consumer side.

The software ecosystem is improving, technology stack by technology stack. For container images, the tooling is already more mature - Ratify, Kyverno, and similar tools can enforce attestation verification in deployment pipelines today. SignPath is working to extend this further, with upcoming features to ensure deployed containers are not only built from trusted source code but also verifiably compliant with modern security standards.