Software Supply Chain · OpenSSF Standard

SLSA — the supply chain hackers can no longer crack.

Supply-chain Levels for Software Artifacts. The framework that turns build pipelines into forensic evidence — and the only standard that satisfies CRA, NIS2 and EU AI Act with cryptographic proof.

L0 → L3 · Build Track

CRA · NIS2 · DORA · AI Act

OpenSSF · Open Standard

Request a consultation Learn more

A brief reminder

Four attacks — one shared class.

Tampering between source code and end user. Classic code security does not reach this point. SLSA closes exactly this gap.

2020

SolarWinds Orion

18,000 organizations compromised. Build system tampered with, signed updates weaponized.

2021

Codecov bash-uploader

Unnoticed for two months. Credentials from numerous CI/CD pipelines siphoned off.

2023

3CX Desktop App

Multi-stage supply chain attack. The vendor itself was the victim of another supply chain attack.

2024

XZ Utils Backdoor

Two years of social engineering. CVSS 10.0. Discovered only by one person’s chance observation.

The situation

The question is not if, but when.

Four numbers every CISO should know today — and that explain why no pipeline strategy can afford to skip SLSA any longer.

742 %

average annual increase in supply chain attacks since 2019

Sonatype · State of the Software Supply Chain

95 %

of all codebases contain open-source components

84 %

of codebases have at least one known vulnerability

1 / 8

open-source downloads already contains a known flaw

A compromised artifact will land in your build — not if, but when.

Introduction

What SLSA is — and what it is not.

Before the debate about levels and pipelines begins, it is worth getting clear: SLSA solves one specific problem — and exactly that one.

SLSA

Supply-chain Levels for Software Artifacts

Security framework from OpenSSF (Linux Foundation), launched in 2021 by Google. Pronounced “sal-sa”. It grades build pipelines into measurable trust levels — from L0 (no guarantee) to L3 (hardened, isolated, signed).

What SLSA is not

No silver bullet, no tool to buy.

Not a pen test, not a code scanner.SLSA does not inspect the content of artifacts, but the integrity of their origin.
Not a replacement for SBOM.SLSA complements SBOM with provable provenance — the two are complementary.
Not a product, not a tool purchase.A framework with requirements and levels, not a licensing model.
Not a compliance checklist.A threat model with concrete countermeasures — not mandatory checkboxes.

Threat Model

The eight threats along the supply chain.

Four phases, eight concrete attack vectors. SLSA primarily addresses the build and distribution phase — source protection and consumer verification emerge as separate tracks.

Source

Source code repo

Submit unauthorized change — a malicious commit lands in the repo.

Compromise source repo — the repo server itself is taken over.

Build

CI/CD pipeline

Build from modified source — the build draws on a tampered source.

Compromise build process — build steps are manipulated.

Package

Registry

Use compromised dependency — a malicious npm/pip package is pulled in.

Upload modified package — the artifact is swapped after the build.

Consume

End user

Compromise package registry — the registry server itself is taken over.

Use compromised package — the user accepts a compromised artifact.

SLSA primarily addresses C, D, F, G — the build and distribution phase. A, B, E and H require complementary source governance and consumer-side verification.

Core idea

Three terms — the rest is detail.

Once you understand these three terms, you have understood SLSA. Everything else is implementation variants.

Provenance

The birth certificate

A machine-readable document: what was built, from which source, by which builder, with which parameters. Format: in-toto Attestation.

Build Platform

The trusted place

The CI/CD platform that builds the artifact. It generates the provenance and signs it. Examples: GitHub Actions, GitLab CI, Tekton Chains.

Verifier

The gatekeeper

The component that checks before deployment: is the provenance correct, is the signature valid, does the artifact meet the policy.

Build Track

Four levels — from Wild West to fortress.

Each level builds on the previous one. More security, less taking-it-on-trust.

No guarantees

No build standard, no provenance. The default state of many internal projects.

Provenance exists

Build process documented. Provenance is generated — machine-readable.

Signed provenance

Build on a hosted platform. Provenance cryptographically signed.

Hardened build platform

Isolation, no user-defined steps, non-forgeable provenance.

Requirements

What exactly do you have to do? The Build Track matrix.

Three “—” become three “✓”. That is precisely the path from “trust me” to “prove it”.

Requirement	L1	L2	L3
Build process follows a consistent procedure	✓	✓	✓
Provenance is generated automatically	✓	✓	✓
Provenance is complete (all build inputs included)	✓	✓	✓
Provenance is authentic (signed by the builder)	—	✓	✓
Build runs on a hosted build platform	—	✓	✓
Build platform isolates builds from one another	—	—	✓
Provenance is non-forgeable (users cannot fake it)	—	—	✓

Anatomy

What does a provenance actually look like?

Machine-readable, signed, fully auditable. What lies behind the in-toto Statement v1 format.

Provenance v1 · in-toto StatementJSON

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "vamisec-app:v1.2.3",
    "digest": { "sha256": "a3f5…e91b" }
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://slsa-framework.github.io/…",
      "externalParameters": {
        "source": "git+https://github.com/vamisec/app",
        "ref":    "refs/tags/v1.2.3"
      },
      "internalParameters": { "runner": "ubuntu-22.04" }
    },
    "runDetails": {
      "builder":  { "id": "https://github.com/actions/runner" },
      "metadata": { "invocationId": "…", "startedOn": "2026-05-20T08:14:02Z" }
    }
  }
}

What the provenance reveals

subject
Which artifact — name + SHA-256 hash. Uniquely identifiable.
externalParameters
Which source — Git URL, commit tag, controllable by the user.
builder.id
Which builder produced it — cryptographically signed identity.
metadata
When, how long, with which invocation ID — fully auditable.

Hands-on

SLSA L3 in GitHub Actions — in 15 lines.

No theory, no new tool silo. Reusable workflow from slsa-framework, Sigstore signature via OIDC, Verifier CLI on the consumer side. Open Source, production-ready.

.github/workflows/release.ymlYAML

name: release
on:
  push:
    tags: ['v*']

jobs:
  build:
    permissions:
      id-token: write    # Sigstore OIDC
      contents: read
      actions:  read
    uses: slsa-framework/slsa-github-generator/.github/workflows/builder_go_slsa3.yml@v2.0.0
    with:
      go-version:  '1.22'
      config-file: .slsa-goreleaser.yml

What happens automatically

1Build runs in an isolated GitHub runner VM.
2Provenance is generated automatically.
3Signed with Sigstore (keyless, OIDC).
4Provenance attached as a release asset.
5Publicly verifiable via slsa-verifier.

Verification on the consumer side — a single line.

Consumer-Side VerificationBash

$ slsa-verifier verify-artifact app-binary \
    --provenance-path app-binary.intoto.jsonl \
    --source-uri      github.com/vamisec/app \
    --source-tag      v1.2.3

PASSED: Verified SLSA provenance

✓ Signature valid✓ Builder is trusted✓ Source URI matches✓ Build from the expected tag

This check belongs in every admission controller, every CD pipeline, every package manager wrapper. Default: not verified = not deployed.

Tools

The ecosystem — Open Source, production-ready.

You build nothing from scratch — you compose from mature open-source building blocks. No commercial license required.

Builder

GitHub Actions

Native SLSA L3 provenance via slsa-github-generator. Sigstore signature out of the box.

Builder

GitLab CI

Built-in provenance generation, in-toto compliant, from GitLab 16+.

Builder

Tekton Chains

Kubernetes-native build platform with native SLSA support for cloud-native stacks.

Signature

Sigstore (Cosign)

Keyless signing via OIDC + transparency log. The de-facto standard for containers and artifacts.

Format

in-toto Attestation

The standard format for provenance statements. JSON-based, structured, signable.

Verifier

SLSA Verifier

Open-source CLI from OpenSSF. Checks provenance against policy — one line, one exit code.

Six components, no vendor lock-in. The entire SLSA stack is Open Source and vendor-neutral.

Who it is for

Who SLSA is especially relevant for.

If you decide or implement at any of these points, SLSA belongs in your technical target picture — before the CRA deadline turns into an emergency.

CISOs & Heads of AppSec

Secure the software supply chain in regulatory terms — without building a new tool silo.

DevSecOps Leads

Harden CI/CD pipelines with concrete implementation patterns — not just theory.

Compliance & Auditors

Technical evidence for CRA Article 13, NIS2 Article 21(2)(d), EU AI Act Article 15.

Platform Teams

Build or evaluate hosting build platforms — SLSA-compliant from day one.

Regulatory context

Why SLSA stops being optional by 2027 at the latest.

Four EU regulations, one shared requirement: provable supply chain security. SLSA delivers the technical proof.

EU CRA

Regulation (EU) 2024/2847

Article 13 — “Cybersecurity by design”. Identification of components and vulnerability management along the supply chain. Applicable from 11 Dec 2027.

NIS2

Directive (EU) 2022/2555

Article 21(2)(d) — supply chain security as a mandatory risk management measure. Transposed in Germany via the NIS2UmsuCG.

EU AI Act

Regulation (EU) 2024/1689

Article 15 — accuracy, robustness, cybersecurity. For high-risk AI, traceable build and training provenance is mandatory.

DORA

Regulation (EU) 2022/2554

Third-party risk management for financial institutions. Software suppliers must demonstrate provably hardened processes.

Case Study

XZ Utils — and why SLSA would not have prevented it.

An honest look at the limits of the framework. When the pipeline is enough, and when you need more.

2021

“Jia Tan” appears. A slow social-engineering build-up.

2023

Takeover of maintainer rights from the original author.

Feb 2024

Backdoor code covertly slipped into the build script.

Mar 2024

Versions 5.6.0 + 5.6.1 released with an SSH backdoor.

29 Mar 2024

Andres Freund spots a 0.5s delay. The world is saved.

Pitfalls

What teams get wrong on the first attempt.

Six mistakes we see regularly in audits. Knowing them saves you the expensive second attempt.

Generating provenance but not verifying it

Evidence without checking is theater. Verification belongs in the admission controller, not the backlog.

Migrating all repos at once

Start with the most critical production artifact. Learn. Scale. Big bang always fails.

Custom build steps in L3 workflows

User-defined scripts make provenance forgeable. Reusable workflows without user code are mandatory.

No policy, just a signature

A valid signature says nothing about the builder’s identity. Policy enforces: who is allowed to build for us?

Treating SBOM and SLSA as competitors

They complement each other. SBOM = what. SLSA = how. Deliver both, verify both.

Treating the Sigstore root as a black box

Sigstore relies on a public trust root. Understand what you implicitly trust. For very high requirements: a private trust root.

Roadmap

From the status quo to L3 — the realistic path.

Six months from “works on my machine” to non-forgeable provenance for the critical artifacts. No big bang, but four phases.

Week 1–2

Inventory

Which build pipelines exist? Who builds production artifacts? Which builds run locally (“works on my machine”)?

Week 3–6

Reach L1

Standardize builds. Build definition as code (YAML). Generate provenance, even if not yet signed.

Month 2–3

Reach L2

Builds only on hosted platforms. Sign provenance with Sigstore. Consumers verify.

Month 4–6

L3 for critical artifacts

Hosted builders with isolation. Reusable workflows without user-defined build steps. Non-forgeable provenance.

Status quoProduction SLSA L3

Takeaways

Five sentences — you need no more.

If you take only one thing from this page, let it be these five statements — in exactly this order.

SLSA is a requirements framework for build pipelines — not a tool, not a product.

Provenance + Verifier turn “trust me” into “prove it”.

L1 is reachable in weeks, L3 in months. Neither scales through a big bang.

SBOM answers what, SLSA answers how. You need both.

CRA, NIS2, DORA, AI Act — all of them demand provable supply chain security. SLSA delivers it.

Expert & Author

Valeri Milke

CEO & Principal Consultant · VamiSec GmbH

“Security is not a product — it is a process. And a process that cannot be proven does not exist in an audit.”

ISO 27001 Lead AuditorISO 42001 Lead AuditorAI Officer (EU AI Act)NIS2 & DORA ExpertCRA ExpertBSI IT-GrundschutzWiz Partner

Referenced in the webinar

Standards you will know in your sleep afterwards.

SLSA v1.0

Framework

in-toto

Attestation

Sigstore

Keyless Signing

SBOM

CycloneDX · SPDX

OpenSSF

Working Group

ENISA

EU Threat Landscape

Frequently asked

FAQ.

How long does introducing SLSA L3 typically take?

For a modern GitHub Actions or GitLab CI pipeline without historical baggage: 4–8 weeks to productively signed provenance attestations. For grown build landscapes with self-hosted runners and custom tools: 3–6 months. The decisive factor is not the code, but the build platform.

Which tools do I actually need for SLSA L3?

In the OpenSSF standard stack: slsa-github-generator or slsa-verifier for provenance, cosign/sigstore for signatures, optionally in-toto for multi-stage attestations. No commercial license required — the entire stack is Open Source and compatible with GitHub, GitLab and Buildkite.

How does SLSA differ from SBOM?

SBOM answers what is inside an artifact (components, versions, licenses). SLSA answers how it was built (build integrity, provenance, signatures). Both are complementary building blocks of a modern supply chain program — not competitors.

Do I need SLSA if I am not yet subject to the CRA?

Strictly legally, often not yet. In practice: if you start today, your critical pipelines will be productively at L2/L3 by 2027. Whoever starts in 2027 builds under audit pressure — and that gets expensive.

How exactly does VamiSec support the rollout?

Three steps: pipeline assessment (maturity today, gaps to L2/L3, effort estimate), roadmap with concrete sprint packages for your build platform, hands-on implementation or coaching of your DevSecOps team. Optionally as a one-day workshop for internal teams. Reach out to us via the booking form.

Next step

Audit-proof.Provable.Productive.

Before you start, talk to an expert. 30 minutes of consultation with a concrete plan for your pipeline — non-binding and free of charge.

Request a consultation

In the first call

Maturity check of your current build pipeline
Roadmap L0 → L3 with effort estimate
Concrete code patterns for GitHub Actions / Verifier
Mapping your obligations: CRA · NIS2 · DORA · AI Act
Written summary & recommendations

VamiSec GmbH · AI-Driven IT-Security & GRC Experts · Bornheimer Str. 127 · 53119 Bonn ·Imprint ·Privacy