SLSA Framework

What Is the SLSA Framework?

SLSA is a security framework for strengthening the integrity of software artifacts by improving the trustworthiness of the software build and supply chain. It provides a structured set of practices and requirements that help organizations prevent, detect, and respond to supply chain threats.

At its core, SLSA is about being able to answer questions like:

Where did this artifact come from?
How was it built, and by what system?
What inputs were used (source, dependencies, build steps)?
Has anything been tampered with between source and release?

SLSA is intentionally pragmatic: it does not assume you can remove all risk. Instead, it gives teams a ladder of maturity so you can start with achievable controls and build toward stronger guarantees over time.

How SLSA Works

SLSA is typically described as a set of increasing levels of assurance. Each level represents stronger protections and better evidence that your build outputs are legitimate. Think of it as moving from “we hope this build is clean” to “we can prove how this was built and limit who or what could have altered it.”

What the levels are trying to achieve

Across the levels, SLSA pushes you toward outcomes such as:

Documented and automated builds rather than manual, ad-hoc releases.
Trusted build environments with hardened, isolated execution.
Tamper-resistant provenance generated by the build system, not by developers.
Policy-based verification before artifacts are deployed.

Each step reduces attack surface. For example, if a developer’s laptop can produce production releases, then a single compromised endpoint can ship malware. If only a hardened CI system can produce releases, and it emits cryptographically verifiable provenance, attacks become harder and more detectable.

Why levels matter (even if you never “finish”)

SLSA is useful even if you don’t aim for the highest level everywhere. Not all artifacts are equal: a public package, a container base image, and a small internal script may require different levels of rigor.

A mature SLSA program often looks like this:

Critical production services: higher assurance requirements.
Internal tools: mid-level protections.
Experimental prototypes: basic controls, but still avoid the most dangerous gaps.

This graduated approach keeps SLSA from becoming an all-or-nothing initiative that stalls.

Key Concepts in SLSA

To understand SLSA, you need to grasp a few concepts that recur in real implementations.

Provenance: the “birth certificate” for artifacts

Provenance is structured metadata that describes how an artifact was produced. It commonly includes:

The identity of the build system that produced the artifact
The source repository and revision
The build steps or workflow identity
The inputs and dependencies (as captured by the builder)
Timestamps and other contextual details

The important nuance is who generates and signs this provenance. In a stronger model, provenance is produced by the build system in a way that developers cannot forge, then attached to (or stored alongside) the artifact.

Provenance does not magically make software secure. It makes it auditable and verifiable, which is crucial for preventing silent tampering.

Build integrity: ensuring the pipeline produces what you expect

Build integrity is the confidence that the artifact truly corresponds to the intended source and process. That involves controls such as:

Builds initiated by controlled triggers (not random manual commands)
Protected branches and reviews for production changes
Controlled build definitions (workflows as code)
Isolation between builds so one compromised job cannot poison another

When build integrity is weak, attackers can inject changes without touching source code, by altering build scripts, build agents, or dependency resolution at build time.

Tamper resistance: reducing who can change artifacts and evidence

Tamper resistance shows up in two places:

The build environment (harder to alter the build as it runs)
The resulting evidence (harder to forge the record of what happened)

Practical controls include ephemeral build runners, minimal permissions, hardened credentials, and cryptographic signing. The goal is to ensure that if something does go wrong, the attacker cannot easily erase their tracks.

FAQs

Do we need to rebuild our entire CI/CD stack to adopt SLSA?

Usually, no. Many teams can incrementally improve their current setup by tightening permissions, switching to ephemeral runners, and adding provenance/signing steps. The biggest changes are often governance-related: deciding which identities can publish artifacts and what verification rules must pass before deployment.

If your current CI environment is deeply shared, long-lived, and hard to isolate, you may need a bigger upgrade. Even then, you can prioritize the most critical repositories first.

How does SLSA relate to SBOMs and dependency management?

SBOMs describe what’s inside an artifact; SLSA helps prove how it was produced and whether it was tampered with. They work best together.

A common pattern is: require provenance and signing for deploy, and attach SBOMs as additional metadata for vulnerability management. This gives you both integrity guarantees and visibility into component risk.

What level should we aim for, and does every project need the same level?

Aim for the level that matches the risk of the artifact. Public-facing libraries, widely reused base images, and production services often deserve stronger controls than internal prototypes.

A practical approach is to define tiers:

Tier 1 (critical): strict provenance + signing + verified deploy
Tier 2 (important): CI-only builds + basic provenance
Tier 3 (low risk): CI-only builds and minimal controls

This avoids boiling the ocean while still raising the baseline.

Will SLSA slow down developers?

If implemented poorly, it can. If implemented well, it often reduces friction by standardizing builds and eliminating manual release steps.

The key is to make the secure path the easy path: reusable pipeline templates, self-service onboarding, clear failure messages, and fast verification. Treat it like a product for internal teams, not a checklist.