Understanding SLSA: A Guide to Software Supply Chain Security and Levels

Table of Contents

What is SLSA

Problems in the Software Supply Chain Types of Supply Chain Attacks Real‑World Examples

SLSA Levels Detailed Explanation Limitations

Implementing SLSA

Other Tools

What is SLSA

SLSA [1] stands for Supply chain Levels for Software Artifacts (pronounced “salsa”).

SLSA is a security framework that provides a checklist of standards and controls to ensure the safety of software build and deployment processes, preventing threats arising from source‑code tampering, compromised build platforms, or malicious artifact repositories.

Problems in the Software Supply Chain

Any software supply chain can introduce vulnerabilities; as systems become more complex, applying best practices to guarantee artifact integrity becomes critical. Without clear standards and a systematic roadmap, defending against the next attack is difficult.

Types of Supply Chain Attacks

Threats:

A – Unauthenticated modifications submitted B – Source‑code repository leakage C – Building from tampered source D – Build‑process leakage E – Use of compromised dependencies F – Upload of modified packages G – Package‑registry leakage H – Use of compromised packages

Real‑World Examples

Integrity Threat

Known Example

How SLSA Helps

A – Unauthenticated modifications submitted

Researchers

[2] attempted to inject a vulnerability into the Linux kernel via a patch posted to a mailing list.

Two‑person review caught most (but not all) of the vulnerabilities.

B – Source‑code repository leakage

PHP

[3]: attackers compromised PHP’s self‑hosted git server and injected two malicious commits.

A better‑protected source‑code platform would make attacks harder.

C – Building from tampered source

Webmin

[4]: attackers altered the build infrastructure to use source files that did not match version control.

A SLSA‑compliant build server records provenance, allowing consumers to detect such tampering.

D – Build‑process leakage

SolarWinds

[5]: attackers compromised the build platform and installed a persistent malicious implant.

Higher SLSA levels require stronger controls on the build platform, reducing the chance of compromise.

E – Use of compromised dependencies

event‑stream

[6]: attackers added a harmless dependency, later updating it to include malicious behavior that did not match the GitHub commit (attack F).

Applying SLSA recursively to all dependencies would block this vector because provenance would show the artifact was not built by an authorized builder.

F – Upload of modified packages

CodeCov

[7]: attackers used leaked credentials to upload malicious artifacts to Google Cloud Storage, from which users could download them.

Provenance in GCS indicates the artifact was not built as expected from the source repository.

G – Package‑registry leakage

Package‑mirror attacks

[8]: researchers demonstrated attacks on several popular package registries that could serve malicious packages.

Similar to (F), provenance shows the artifacts were not built as intended from the expected source.

H – Use of compromised packages

Browserify typosquatting

[9]: attackers uploaded a malicious package with a name similar to a legitimate one.

SLSA does not directly address this threat, but linking provenance back to source control enables other mitigations.

SLSA Levels

Level

Description

Example

1

Documented build process

Unsigned provenance

2

Anti‑tamper build service

Hosted source/build with signed provenance

3

Additional resistance to specific threats

Host security controls, unforgeable provenance

4

Highest confidence and trust

Two‑person review + sealed builds

Detailed Explanation

Level

Requirements

0

No guarantees. SLSA 0 indicates the absence of any SLSA level.

1

The build process must be fully scripted/automated and generate provenance.

Provenance is metadata about how an artifact was built, including the build process, top‑level source, and dependencies. Understanding provenance lets consumers make risk‑based security decisions. SLSA 1 provenance does not prevent tampering but provides basic source identification and aids vulnerability management.

2

Requires version control and a hosted build service that generates authenticated provenance.

These additional requirements increase consumer confidence in the artifact’s origin. At this level, provenance can prevent tampering to the extent that the build service is trusted. SLSA 2 also offers an easy upgrade path to SLSA 3.

3

The source and build platform must meet specific standards to guarantee auditability of the source and integrity of provenance.

We envision a certification process where auditors verify platform compliance, allowing consumers to trust the results. SLSA 3 provides stronger anti‑tamper protection against specific threats such as cross‑build contamination.

4

Requires two‑person review of all changes and a sealed, reproducible build process.

Two‑person review is an industry best practice for catching errors and preventing malicious actions. Sealed builds ensure the dependency list is complete. While reproducible builds are not strictly required, they add auditability and reliability. Overall, SLSA 4 gives consumers high confidence that software has not been tampered with.

Limitations

SLSA can help reduce supply‑chain threats in software artifacts, but it has several limitations:

Many artifacts have extensive dependency graphs, which can become very large.

Security teams must identify and focus on critical components in the supply chain; manual effort can be substantial.

An artifact’s SLSA level is not transitive, and its dependencies have their own levels, meaning a SLSA 4 artifact can be built from SLSA 0 dependencies, leaving residual risk.

Automating these tasks helps, but fully reviewing every artifact in a large graph is impractical for most consumers; auditors and certifiers can assert compliance for specific parts, which is especially valuable for closed‑source software.

As part of the SLSA roadmap, the team will continue to explore ways to identify critical components, assess overall supply‑chain risk, and define the role of certification.

Implementing SLSA

SLSA is a standard, but how can it be applied in practice?

We can map our CI/CD workflow against the SLSA Requirements [10] checklist to see which security level we currently achieve.

Are there tools that can help us assess and guide improvements?

Currently only a few tools exist, and most are limited to GitHub.

OpenSSF Scorecard [11] is an automated tool from the Open Source Security Foundation that evaluates open‑source projects against a set of security criteria, assigning a 0‑10 score for each check. These scores help maintainers understand where to improve and allow consumers to assess the risk of dependencies.

Other Tools

slsa‑verifier [12] – Verifies that a build’s provenance complies with the SLSA standard.

Sigstore [13] – A new standard for signing, verifying, and protecting software.

References

[1] SLSA: https://slsa.dev/

[2] Researchers: https://lore.kernel.org/lkml/202105051005.49BFABCE@keescook/

[3] PHP: https://news-web.php.net/php.internals/113838

[4] Webmin: https://www.webmin.com/exploit.html

[5] SolarWinds: https://www.crowdstrike.com/blog/sunspot-malware-technical-analysis/

[6] event‑stream: https://web.archive.org/web/20210909051737/https://schneider.dev/blog/event-stream-vulnerability-explained/

[7] CodeCov: https://about.codecov.io/apr-2021-post-mortem/

[8] Package‑mirror attacks: https://theupdateframework.io/papers/attacks-on-package-managers-ccs2008.pdf

[9] Browserify typosquatting: https://blog.sonatype.com/damaging-linux-mac-malware-bundled-within-browserify-npm-brandjack-attempt

[10] Requirements: https://slsa.dev/spec/v0.1/requirements

[11] OpenSSF Scorecard: https://github.com/ossf/scorecard

[12] slsa‑verifier: https://github.com/slsa-framework/slsa-verifier

[13] Sigstore: https://github.com/sigstore