What Is SLSA and Why Your Vendors Should Care

Supply-chain Levels for Software Artifacts , SLSA, pronounced 'salsa' , is a security framework developed by Google and now maintained by the OpenSSF that defines a graduated set of requirements for protecting the integrity of software artifacts throughout the build and distribution process. SLSA addresses a specific and increasingly exploited attack vector: the compromise of software between the source code repository and the software artifact that reaches end users , the build pipeline, the artifact repository, and the distribution channel. SolarWinds, XZ Utils, and the 3CX supply chain attack all exploited this gap. SLSA provides a structured framework for closing it.

The SLSA level system is the conceptual key. SLSA defines four levels of progressively stronger assurance about software provenance and build integrity. Level 1 requires that the build process generates provenance , documentation of how the artifact was built. It is the entry level and provides minimal security assurance: the provenance can be forged, the build process is not isolated, and no verification is required. Level 2 adds that the build service generates the provenance, rather than the developer, which makes the provenance more credible. Level 3 requires that the build service generates provenance that is unforgeable by the developer , because it is signed by the build service. Level 4 adds hermetic, reproducible builds , the build is completely isolated from the network, dependencies are fully specified, and the same inputs produce the same outputs verifiably.

The practical significance of SLSA levels for TPRM is that SLSA compliance claims without level specification are essentially meaningless. A vendor who is SLSA Level 1 compliant has documented their build process. A vendor who is SLSA Level 3 compliant has unforgeable build provenance from an isolated build service. These are materially different security postures. The TPRM team that asks 'are you SLSA compliant?' and receives 'yes' without asking 'at what level?' has obtained a confirmation that could describe anything from a text document about the build process to a cryptographically verified, isolated build pipeline.

The attacker's perspective clarifies why level matters. The SolarWinds attack compromised the build pipeline , the process between the source code and the compiled artifact. At SLSA Level 1, this attack is largely undetected: the provenance is generated by the same process the attacker controls, and the forged provenance reflects the malicious artifact. At SLSA Level 3, the build service generates unforgeable provenance , so a malicious artifact that was not built by the authenticated build service cannot produce valid Level 3 provenance. The higher the SLSA level, the more an attacker must compromise to produce a valid artifact with valid provenance.

The adoption reality is the governance context. SLSA Level 4 , the highest assurance level , is extremely difficult to achieve at scale. Many major software vendors are at Level 1 or 2. Level 3 is achievable with investment in build infrastructure. Level 4 is a significant architectural commitment. For TPRM purposes, the relevant question is not whether a vendor has achieved Level 4, but whether they are actively progressing through SLSA levels and whether their current level is appropriate for the risk of the software they deliver.

Why this matters

SLSA matters for TPRM because software supply chain attacks , specifically the compromise of build pipelines and artifact distribution , are among the most impactful and most difficult to detect attack vectors currently being exploited. The enterprise that confirms a vendor is SLSA compliant without knowing the level has not confirmed meaningful build integrity assurance. The enterprise that understands SLSA levels can ask the right questions and set appropriate expectations for the software it deploys.

The downstream blast radius is the specific supply chain concern. Software that is compromised in the build pipeline contains the attacker's code in every compiled artifact distributed to every customer. A single build pipeline compromise reaches every enterprise that deploys that software , as SolarWinds demonstrated at scale. SLSA Level 3 and 4 requirements make this attack significantly harder to execute without detection.

Where most teams get this wrong

The most consistent failure is accepting SLSA compliance confirmation without asking the level , treating SLSA as a binary certification rather than a graduated framework. The second failure is not having a minimum SLSA level requirement for critical software vendors , accepting any level regardless of the software's risk profile.

• SLSA confirmed without level , binary compliance question produces uninformative answer
• No minimum level requirement for critical software vendors
• SLSA Level 1 accepted for high-criticality software with significant blast radius
• No understanding of what each level prevents , attacker perspective not applied
• No SLSA progression requirement , vendors not expected to improve over time

What good looks like

Mature software supply chain programmes ask for SLSA level specifically, set minimum level expectations that scale with software criticality, and request provenance attestations as evidence rather than accepting questionnaire responses alone.

• Ask for SLSA level specifically , not binary compliance
• Set minimum level by criticality , Level 2 minimum for most commercial software, Level 3 for critical
• Request provenance attestation as evidence alongside level claim
• Ask for SLSA roadmap , what level the vendor is targeting and timeline
• Verify provenance for critical software artifacts using tooling

Tooling

SLSA Verification , Sigstore/cosign for provenance verification; SLSA framework tooling at slsa.dev

Sigstore's cosign tool provides the mechanism for verifying SLSA provenance attestations , confirming that a software artifact's provenance claim is valid and matches the artifact. For TPRM practitioners, asking a vendor to provide their SLSA provenance attestation for a specific release and verifying it using cosign is the practical test that confirms whether the claimed SLSA level produces verifiable artifacts.

Build Systems , GitHub Actions with SLSA generator, Google Cloud Build with SLSA support

Major CI/CD platforms now include SLSA provenance generation as a supported feature. GitHub Actions' SLSA generator produces Level 3-compliant provenance for GitHub Actions builds. For TPRM assessments, asking whether the vendor's build system supports SLSA provenance generation and at what level provides a specific build infrastructure question.

Governance challenges

The governance challenge with SLSA in TPRM is the expertise gap. SLSA is a technical standard that requires understanding of build infrastructure to evaluate meaningfully. TPRM teams that do not have build security expertise may struggle to assess SLSA level claims without developer support. The governance resolution is building a reference guide for SLSA levels that enables TPRM analysts to ask the right questions and interpret responses appropriately, supplemented by developer team consultation for critical software vendors.

• Define SLSA level requirements by software criticality tier
• Ask for SLSA level and provenance attestation , not binary compliance
• Request SLSA roadmap for vendors at lower levels
• Verify provenance attestations for critical software artifacts
• Build TPRM analyst understanding of SLSA levels , what each level prevents

If you are a small team

For your three most critical software vendors , the products where a supply chain compromise would be most damaging , ask two specific questions. First: at what SLSA level is your build process compliant, and can you provide a provenance attestation for your most recent release? Second: is your build system integrated with Sigstore or an equivalent provenance verification framework, and can we verify the attestation independently? Those two questions will tell you far more about actual build integrity than a binary SLSA compliance confirmation.

• Ask for SLSA level specifically for top three critical software vendors
• Request provenance attestation for a recent release
• Ask whether provenance can be independently verified
• Set minimum SLSA level requirement for critical software

What to require

Ask directly:

"At what SLSA level is your build process compliant , and can you provide a verifiable provenance attestation for your most recent major release that confirms the artifact was built from the stated source code by an authenticated build service?"

Expect as evidence

• Specific SLSA level , not binary compliance
• Provenance attestation for a recent release
• Verification method for the attestation
• SLSA roadmap if below target level

A vendor who confirms SLSA compliance should be asked for the level. Compliance at Level 1 and compliance at Level 3 are not the same assurance. The level determines what the compliance confirmation means.

How to evidence it

• SLSA level requirements by software criticality
• Provenance attestation records
• Verification of provenance for critical software
• Vendor SLSA roadmap tracking

Key Takeaway

SLSA compliant: confirmed. Level: 1. What Level 1 means: the build process is documented. What it prevents: nothing the attacker would care about. SLSA Level 1 is documentation. Level 3 is unforgeable provenance from an isolated build service. Level 4 is hermetic, reproducible builds. The SolarWinds attack , compromising the build pipeline to insert malicious code into signed artifacts , is prevented by Level 3 because the malicious build cannot produce valid Level 3 provenance. The level determines what the compliance confirmation means. Binary SLSA compliance questions produce binary answers that describe nothing useful about build integrity.

More on Third-party oversight

• Build Pipeline Integrity
• Vendor Patch Cadence Reality
• Artifact Registry Security