Software Supply Chain · OpenSSF Standard

SLSA — die Lieferkette, die Hacker nicht mehr knacken.

Supply-chain Levels for Software Artifacts. Das Framework, das aus Build-Pipelines forensische Beweisstücke macht — und der einzige Standard, der CRA, NIS2 und EU AI Act mit kryptografischen Nachweisen befriedigt.

L0 → L3 · Build Track

CRA · NIS2 · DORA · AI Act

OpenSSF · Open Standard

Erstberatung anfragen Mehr erfahren

Eine kurze Erinnerung

Vier Angriffe — eine gemeinsame Klasse.

Manipulation zwischen Quellcode und Endnutzer. Klassische Code-Security greift hier nicht. Genau dieses Loch schließt SLSA.

2020

SolarWinds Orion

18.000 Organisationen kompromittiert. Build-System manipuliert, signierte Updates wurden zur Waffe.

2021

Codecov bash-uploader

Zwei Monate unbemerkt. Credentials zahlreicher CI/CD-Pipelines abgegriffen.

2023

3CX Desktop App

Mehrstufiger Supply-Chain-Angriff. Vendor selbst Opfer eines anderen Supply-Chain-Angriffs.

2024

XZ Utils Backdoor

Zwei Jahre Social Engineering. CVSS 10.0. Nur durch Zufall einer Person entdeckt.

Die Lage

Die Frage ist nicht ob, sondern wann.

Vier Zahlen, die jeder CISO heute kennen sollte — und die erklären, warum SLSA in keiner Pipeline-Strategie mehr fehlen darf.

742 %

durchschnittlicher jährlicher Anstieg von Supply-Chain-Angriffen seit 2019

Sonatype · State of the Software Supply Chain

95 %

aller Codebases enthalten Open-Source-Komponenten

84 %

der Codebases haben mindestens eine bekannte Schwachstelle

1 / 8

Open-Source-Downloads enthält bereits eine bekannte Lücke

Ein kompromittiertes Artefakt landet in deinem Build — nicht ob, sondern wann.

Einführung

Was SLSA ist — und was nicht.

Bevor die Diskussion um Levels und Pipelines startet, lohnt sich die Klärung: SLSA löst ein konkretes Problem — und genau nur dieses.

SLSA

Supply-chain Levels for Software Artifacts

Sicherheits-Framework der OpenSSF (Linux Foundation), 2021 gestartet von Google. Spricht „sal-sa“ aus. Stuft Build-Pipelines in messbare Vertrauensstufen ein — von L0 (keine Garantie) bis L3 (gehärtet, isoliert, signiert).

Was SLSA nicht ist

Keine Wunderwaffe, kein Tool zum Kaufen.

Kein Pen-Test, kein Code-Scanner.SLSA prüft nicht den Inhalt der Artefakte, sondern die Integrität der Herkunft.
Kein Ersatz für SBOM.SLSA ergänzt SBOM um nachweisbare Provenance — beides ist komplementär.
Kein Produkt, kein Werkzeug-Kauf.Ein Framework mit Anforderungen und Levels, kein Lizenzmodell.
Keine Compliance-Checkliste.Ein Threat-Model mit konkreten Gegenmaßnahmen — keine Pflicht-Häkchen.

Threat Model

Die acht Bedrohungen entlang der Lieferkette.

Vier Phasen, acht konkrete Angriffsvektoren. SLSA adressiert primär die Build- und Distributionsphase — Source-Schutz und Consumer-Verifikation entstehen als eigene Tracks.

Source

Quellcode-Repo

Submit unauthorized change — bösartiger Commit landet im Repo.

Compromise source repo — Repo-Server selbst übernommen.

Build

CI/CD-Pipeline

Build from modified source — Build greift auf manipulierte Quelle zu.

Compromise build process — Build-Schritte werden manipuliert.

Package

Registry

Use compromised dependency — bösartiges npm/pip-Paket eingespielt.

Upload modified package — Artefakt nach Build ausgetauscht.

Consume

Endnutzer

Compromise package registry — Registry-Server selbst übernommen.

Use compromised package — Nutzer akzeptiert kompromittiertes Artefakt.

SLSA adressiert primär C, D, F, G — die Build- und Distributionsphase. Für A, B, E, H braucht es ergänzende Source-Governance und Consumer-seitige Verifikation.

Grundidee

Drei Begriffe — der Rest ist Detail.

Wenn du diese drei Begriffe verstehst, hast du SLSA verstanden. Alles andere sind Implementierungs-Varianten.

Provenance

Die Geburtsurkunde

Maschinenlesbares Dokument: Was wurde gebaut, aus welcher Quelle, von welchem Builder, mit welchen Parametern. Format: in-toto Attestation.

Build Platform

Der vertrauenswürdige Ort

Die CI/CD-Plattform, die das Artefakt baut. Sie erzeugt die Provenance und signiert sie. Beispiele: GitHub Actions, GitLab CI, Tekton Chains.

Verifier

Der Pförtner

Komponente, die vor dem Deployment prüft: stimmt die Provenance, ist die Signatur valide, erfüllt das Artefakt die Policy.

Build Track

Vier Stufen — von Wildwest bis Festung.

Jede Stufe baut auf der vorherigen auf. Mehr Sicherheit, weniger Vertrauen-auf-Wort.

Keine Garantien

Kein Build-Standard, keine Provenance. Default-Zustand vieler interner Projekte.

Provenance existiert

Build-Prozess dokumentiert. Provenance wird generiert — maschinenlesbar.

Signierte Provenance

Build auf gehosteter Plattform. Provenance kryptografisch signiert.

Gehärtete Build-Plattform

Isolation, keine User-defined Steps, non-falsifizierbare Provenance.

Anforderungen

Was muss man konkret tun? Build-Track-Matrix.

Drei „—“ werden zu drei „✓“. Genau das ist der Weg von „Vertrau mir“ zu „Beweis es“.

Anforderung	L1	L2	L3
Build-Prozess folgt einem konsistenten Verfahren	✓	✓	✓
Provenance wird automatisch generiert	✓	✓	✓
Provenance ist vollständig (alle Build-Eingaben enthalten)	✓	✓	✓
Provenance ist authentisch (signiert vom Builder)	—	✓	✓
Build läuft auf gehosteter Build-Plattform	—	✓	✓
Build-Plattform isoliert Builds gegeneinander	—	—	✓
Provenance ist non-falsifizierbar (User kann sie nicht fälschen)	—	—	✓

Anatomie

Wie sieht eine Provenance konkret aus?

Maschinenlesbar, signiert, vollständig auditierbar. Was sich hinter dem Format in-toto Statement v1 verbirgt.

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" }
    }
  }
}

Was die Provenance verrät

subject
Welches Artefakt — Name + SHA-256-Hash. Eindeutig identifizierbar.
externalParameters
Welche Quelle — Git-URL, Commit-Tag, vom Nutzer steuerbar.
builder.id
Welcher Builder hat es gebaut — kryptografisch signierte Identität.
metadata
Wann, wie lange, mit welcher Invocation-ID — vollständig auditierbar.

Hands-on

SLSA L3 in GitHub Actions — in 15 Zeilen.

Keine Theorie, kein neues Tool-Silo. Reusable Workflow von slsa-framework, Sigstore-Signatur via OIDC, Verifier-CLI auf Consumer-Seite. Open Source, produktionsreif.

.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

Was automatisch passiert

1Build läuft in isolierter GitHub-Runner-VM.
2Provenance wird automatisch generiert.
3Signiert mit Sigstore (keyless, OIDC).
4Provenance als Release-Asset attached.
5Public verifizierbar via slsa-verifier.

Verifikation auf Consumer-Seite — eine Zeile.

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

✓ Signatur valide✓ Builder ist trusted✓ Source-URI passt✓ Build aus erwartetem Tag

Diese Prüfung gehört in jeden Admission-Controller, jede CD-Pipeline, jeden Package-Manager-Wrapper. Default: nicht verifiziert = nicht deployed.

Werkzeuge

Das Ökosystem — Open Source, produktionsreif.

Du baust nichts von Grund auf — du komponierst aus reifen Open-Source-Bausteinen. Keine kommerzielle Lizenz nötig.

Builder

GitHub Actions

Native SLSA-L3-Provenance via slsa-github-generator. Sigstore-Signatur out of the box.

Builder

GitLab CI

Eingebaute Provenance-Generierung, in-toto-konform, ab GitLab 16+.

Builder

Tekton Chains

Kubernetes-native Build-Plattform mit nativem SLSA-Support für Cloud-Native-Stacks.

Signatur

Sigstore (Cosign)

Keyless Signing via OIDC + Transparency Log. De-facto-Standard für Container und Artefakte.

Format

in-toto Attestation

Das Standardformat für Provenance-Statements. JSON-basiert, strukturiert, signierbar.

Verifier

SLSA Verifier

Open-Source-CLI von OpenSSF. Prüft Provenance gegen Policy — eine Zeile, ein Exit-Code.

Sechs Komponenten, kein Vendor-Lock-in. Der gesamte SLSA-Stack ist Open Source und herstellerneutral.

Für wen

Für wen SLSA besonders relevant ist.

Wenn du an einer dieser Stellen entscheidest oder umsetzt, gehört SLSA in dein technisches Zielbild — bevor die CRA-Frist zum Notfall wird.

CISOs & Heads of AppSec

Software-Lieferkette regulatorisch absichern — ohne ein neues Tool-Silo aufzubauen.

DevSecOps Leads

CI/CD-Pipelines härten mit konkreten Implementierungs-Pattern — nicht nur Theorie.

Compliance & Auditoren

Technische Nachweise für CRA Art. 13, NIS2 Art. 21(2)(d), EU AI Act Art. 15.

Plattform-Teams

Hostende Build-Plattformen aufbauen oder evaluieren — SLSA-konform von Tag eins.

Regulatorischer Kontext

Warum SLSA spätestens 2027 nicht mehr optional ist.

Vier EU-Verordnungen, eine gemeinsame Anforderung: nachweisbare Supply-Chain-Sicherheit. SLSA liefert den technischen Beweis.

EU CRA

Verordnung (EU) 2024/2847

Artikel 13 — „Cybersecurity by Design“. Identifizierung von Komponenten und Schwachstellenmanagement entlang der Lieferkette. Anwendung ab 11.12.2027.

NIS2

Richtlinie (EU) 2022/2555

Artikel 21(2)(d) — Sicherheit der Lieferkette als verpflichtende Risikomanagement-Maßnahme. In DE umgesetzt durch NIS2UmsuCG.

EU AI Act

Verordnung (EU) 2024/1689

Artikel 15 — Genauigkeit, Robustheit, Cybersicherheit. Für High-Risk-AI sind nachvollziehbare Build- und Training-Provenance Pflicht.

DORA

Verordnung (EU) 2022/2554

Drittparteien-Risikomanagement für Finanzdienstleister. Software-Lieferanten müssen nachweisbar gehärtete Prozesse vorweisen.

Case Study

XZ Utils — und warum SLSA es nicht verhindert hätte.

Ein ehrlicher Blick auf die Grenzen des Frameworks. Wann reicht die Pipeline, wann braucht es mehr.

2021

„Jia Tan“ taucht auf. Langsamer Social-Engineering-Aufbau.

2023

Übernahme von Maintainer-Rechten vom Original-Autor.

Feb 2024

Backdoor-Code in Build-Skript versteckt eingeschleust.

März 2024

Versionen 5.6.0 + 5.6.1 mit SSH-Backdoor veröffentlicht.

29.03.2024

Andres Freund entdeckt 0,5s-Verzögerung. Die Welt rettet sich.

Fallstricke

Was Teams beim ersten Anlauf falsch machen.

Sechs Fehler, die wir in Audits regelmäßig sehen. Wer sie kennt, spart sich den teuren zweiten Anlauf.

Provenance erzeugen, aber nicht verifizieren

Ein Nachweis ohne Prüfung ist Theater. Die Verifikation gehört in den Admission-Controller, nicht ins Backlog.

Alle Repos auf einmal migrieren

Beginne mit dem kritischsten produktiven Artefakt. Lerne. Skaliere. Big-Bang scheitert immer.

Custom Build Steps in L3-Workflows

Nutzerdefinierte Skripte machen Provenance fälschbar. Reusable Workflows ohne User-Code sind Pflicht.

Keine Policy, nur Signatur

Eine valide Signatur sagt nichts über die Identität des Builders. Policy erzwingt: Wer darf für uns bauen?

SBOM und SLSA als Konkurrenten behandeln

Sie ergänzen sich. SBOM = was. SLSA = wie. Beides liefern, beides verifizieren.

Sigstore-Root als Black Box

Sigstore basiert auf öffentlichem Trust-Root. Verstehe, was du implizit vertraust. Für sehr hohe Anforderungen: privater Trust-Root.

Roadmap

Vom Status quo zu L3 — der realistische Pfad.

Sechs Monate von „works on my machine“ zu non-falsifizierbarer Provenance für die kritischen Artefakte. Kein Big-Bang, sondern vier Phasen.

Woche 1–2

Inventur

Welche Build-Pipelines existieren? Wer baut produktive Artefakte? Welche Builds laufen lokal („works on my machine“)?

Woche 3–6

L1 erreichen

Builds standardisieren. Build-Definition als Code (YAML). Provenance generieren, auch wenn noch nicht signiert.

Monat 2–3

L2 erreichen

Builds nur noch auf gehosteten Plattformen. Provenance mit Sigstore signieren. Konsumenten verifizieren.

Monat 4–6

L3 für kritische Artefakte

Hosted Builders mit Isolation. Reusable Workflows ohne nutzerdefinierte Build-Schritte. Non-falsifizierbare Provenance.

Status quoProduktives SLSA L3

Takeaways

Fünf Sätze — mehr brauchst du nicht.

Wenn du nach dieser Seite nur eines mitnehmen sollst, dann diese fünf Aussagen — in genau dieser Reihenfolge.

SLSA ist ein Anforderungs-Framework an Build-Pipelines — kein Tool, kein Produkt.

Provenance + Verifier verwandeln „Vertrau mir“ in „Beweis es“.

L1 ist in Wochen erreichbar, L3 in Monaten. Beides skaliert nicht durch Big-Bang.

SBOM beantwortet was, SLSA beantwortet wie. Du brauchst beides.

CRA, NIS2, DORA, AI Act — alle verlangen nachweisbare Supply-Chain-Sicherheit. SLSA liefert sie.

Experte & Autor

Valeri Milke

CEO & Principal Consultant · VamiSec GmbH

„Sicherheit ist kein Produkt — es ist ein Prozess. Und ein Prozess, der nicht nachweisbar ist, ist im Audit nicht existent.“

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

Im Webinar referenziert

Standards, die du danach im Schlaf kennst.

SLSA v1.0

Framework

in-toto

Attestation

Sigstore

Keyless Signing

SBOM

CycloneDX · SPDX

OpenSSF

Working Group

ENISA

EU Threat Landscape

Häufige Fragen

FAQ.

Wie lange dauert die Einführung von SLSA L3 typischerweise?

Für eine moderne GitHub-Actions- oder GitLab-CI-Pipeline ohne historischen Ballast: 4–8 Wochen bis zu produktiv signierten Provenance-Attestations. Für gewachsene Build-Landschaften mit Self-hosted Runnern und Custom-Tools: 3–6 Monate. Entscheidender Faktor ist nicht der Code, sondern die Build-Plattform.

Welche Tools brauche ich konkret für SLSA L3?

Im OpenSSF-Standardstack: slsa-github-generator oder slsa-verifier für Provenance, cosign/sigstore für Signaturen, optional in-toto für mehrstufige Attestations. Keine kommerzielle Lizenz nötig — der gesamte Stack ist Open Source und kompatibel mit GitHub, GitLab und Buildkite.

Wie unterscheidet sich SLSA von SBOM?

SBOM beantwortet was in einem Artefakt steckt (Komponenten, Versionen, Lizenzen). SLSA beantwortet wie es gebaut wurde (Build-Integrität, Provenance, Signaturen). Beides sind komplementäre Bausteine eines modernen Supply-Chain-Programms — nicht Konkurrenten.

Brauche ich SLSA, wenn ich noch nicht CRA-pflichtig bin?

Strikt rechtlich heute oft nicht. Praktisch: Wenn du heute beginnst, sind deine kritischen Pipelines bis 2027 produktiv auf L2/L3. Wer 2027 startet, baut unter Audit-Druck — und das wird teuer.

Wie unterstützt VamiSec konkret bei der Einführung?

Drei Schritte: Pipeline-Assessment (Reifegrad heute, Lücken zu L2/L3, Aufwandsschätzung), Roadmap mit konkreten Sprint-Paketen für deine Build-Plattform, Hands-on-Implementierung oder Coaching deines DevSecOps-Teams. Optional als 1-Tag-Workshop für interne Teams. Sprich uns über das Booking-Formular an.

Nächster Schritt

Audit-fest.Nachweisbar.Produktiv.

Bevor du loslegst, sprich mit einem Experten. 30 Minuten Erstberatung mit konkretem Plan für deine Pipeline — unverbindlich und kostenfrei.

Erstberatung anfragen

Im Erstgespräch

Reifegrad-Check deiner aktuellen Build-Pipeline
Roadmap L0 → L3 mit Aufwandsschätzung
Konkrete Code-Pattern für GitHub Actions / Verifier
Mapping deiner Pflichten: CRA · NIS2 · DORA · AI Act
Schriftliche Zusammenfassung & Empfehlungen

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