SLSA Supply Chain Levels: Wie Software-Lieferkettensicherheit CRA-Anforderungen adressiert
SLSA Supply Chain Levels: Wie Software-Lieferkettensicherheit CRA-Anforderungen adressiert
von Tobias Reinhardt
1. Einleitung: Warum Lieferkettensicherheit jetzt regulatorisch relevant wird
Der SolarWinds-Angriff 2020 zeigte, wie ein kompromittierter Build-Prozess Tausende von Organisationen weltweit infizieren kann. Der XZ-Utils-Vorfall 2024 demonstrierte, wie ein einzelner bösartiger Commit in einer weitverbreiteten Open-Source-Bibliothek beinahe kritische Infrastruktur untergraben hätte. Beide Vorfälle haben eines gemeinsam: Der eigentliche Angriffspunkt war nicht die Anwendung selbst, sondern der Weg von Source Code zum ausgelieferten Artefakt – die Software-Lieferkette.
Die Europäische Union hat darauf mit dem Cyber Resilience Act (CRA) reagiert, der voraussichtlich ab 2027 vollständig in Kraft tritt. Der CRA verpflichtet Hersteller von Produkten mit digitalen Elementen zur nachweisbaren Absicherung ihrer Software-Lieferkette – und stellt damit viele Organisationen vor die Frage: Wie setze ich das technisch um?
Das SLSA-Framework (Supply Chain Levels for Software Artifacts) bietet hier einen pragmatischen, stufenweisen Ansatz. Es liefert keine magische Lösung, aber ein strukturiertes technisches Fundament, das CRA-Anforderungen direkt adressiert.
2. CRA-Anforderungen an die Software-Lieferkette im Überblick
Der CRA enthält in Artikel 13 sowie Anhang I konkrete Pflichten für Hersteller. Besonders relevant für die Lieferkette sind:
- SBOM-Erstellung: Hersteller müssen eine maschinenlesbare Software Bill of Materials bereitstellen, die Drittkomponenten und Open-Source-Abhängigkeiten dokumentiert.
- Build-Integrität: Der Entwicklungsprozess muss so gestaltet sein, dass die Integrität von Artefakten nachgewiesen werden kann.
- Schwachstellenmanagement: Bekannte Schwachstellen in verwendeten Komponenten müssen identifiziert, bewertet und zeitnah adressiert werden.
- Sorgfaltspflicht bei Open Source: Wer OSS-Komponenten integriert, trägt Verantwortung für deren sicherheitsrelevante Eigenschaften im Kontext des eigenen Produkts.
Was in der Praxis unterschätzt wird: Der CRA fordert nicht nur Dokumentation, sondern Nachvollziehbarkeit der Zuordnung zwischen Dokumentation und tatsächlich ausgeliefertem Code. Genau hier entstehen in der Praxis gefährliche Irrtümer.
Eine typische War-Story: Ein Sicherheitsteam identifiziert eine kritische CVE in einer Abhängigkeit. Es beginnt ein aufwändiger Audit-Prozess: SBOM wird analysiert, Betroffenheit bewertet, Patches eingespielt, Berichte erstellt. Nach zwei Wochen Aufwand stellt sich heraus – die betroffene Version wurde bereits drei Sprints zuvor im Rahmen eines Routine-Updates auf eine nicht-betroffene Version angehoben. Die SBOM war schlicht nicht mit dem aktuellen Build verknüpft. Ohne eine attestierte, artefaktgebundene Provenance lässt sich solche Verschwendung kaum vermeiden.
3. SLSA Framework: Architektur, Level und Kernkonzepte
SLSA, ausgesprochen “Salsa”, ist ein von Google initiiertes und inzwischen unter dem Dach der OpenSSF weiterentwickeltes Framework. Es definiert vier Reifegrade:
| Level | Kern-Eigenschaft |
|---|---|
| L1 | Provenance wird generiert (unsigned) |
| L2 | Provenance ist durch den Build-Service signiert |
| L3 | Build-Prozess ist gehärtet, tamper-resistent und isoliert |
Die drei zentralen Bausteine sind:
- Provenance: Eine maschinenlesbare Aussage darüber, wie, wann und durch wen ein Artefakt gebaut wurde – inklusive Quell-Commit, verwendeter Build-Plattform und Eingabeparameter.
- Build Integrity: Die Garantie, dass der Build-Prozess nicht manipulierbar ist und die Provenance authentisch ist.
- Attestations: Kryptographisch signierte Aussagen über Artefakte, die von Consumers verifiziert werden können.
SLSA ist kein isoliertes Werkzeug, sondern Teil eines breiteren Ökosystems: Das in-toto-Framework liefert das Attestierungsformat, Sigstore (mit Rekor als Transparenz-Log und Cosign als Signaturwerkzeug) ermöglicht keyless Signing über OIDC-Identitäten.
Sigstore löst das Problem aus der War-Story direkt: Jedes Build-Artefakt erhält eine unveränderliche, öffentlich verankerte Signatur, die an den exakten Git-Commit und die Build-Umgebung gebunden ist. Die SBOM ist damit nicht mehr ein loses Dokument, sondern fest mit dem ausgelieferten Container-Image oder Binary verknüpft. Ein Schwachstellenscanner kann sofort prüfen, ob die betroffene Version tatsächlich im produktiven Artefakt steckt – oder ob das Bumping bereits in der Provenance dokumentiert ist.
4. Mapping: Wie SLSA-Level konkrete CRA-Anforderungen adressieren
| CRA-Anforderung | Relevantes SLSA-Level | Mechanismus |
|---|---|---|
| Nachvollziehbarkeit des Build-Prozesses | L2 | Signierte Provenance dokumentiert Build-Herkunft |
| Integrität des ausgelieferten Artefakts | L2–L3 | Artefakt-Hash + Signatur durch Build-Service |
| Verknüpfung SBOM ↔ Artefakt | L1+ mit SBOM-Attestation | Attestierung bindet SBOM an konkretes Artefakt |
| Sorgfaltspflicht Drittkomponenten | L1 als Basis | Provenance enthält Dependency-Informationen |
| Schutz vor Build-Time-Kompromittierung | L3 | Isolierter, gehärteter Build-Prozess |
Besonders relevant: CRA Anhang I, Part I, Punkt 2 fordert, dass Hersteller Schwachstellen in Drittkomponenten “systematisch” adressieren. SLSA L2-Provenance in Kombination mit einem SBOM-Tool wie Syft oder Trivy schafft genau diese Systematik: Der Scan läuft nicht gegen eine manuelle Dependency-Liste, sondern gegen das tatsächliche, attestierte Artefakt.
5. Stufenweise Implementierung: Von L1 zu L3 in der Praxis
SLSA L1 – Schneller Einstieg (1–2 Tage)
Der erste Schritt ist die automatische Generierung von Provenance ohne Signatur. Empfohlene Tools:
- GitHub Actions:
slsa-framework/slsa-github-generatorbietet fertige Workflows für Container-Images, Go-Binaries und Generic-Artifacts. - Tekton Chains: Für Kubernetes-native Pipelines automatisch Provenance-Generierung im OCI-Format.
Ein L1-Provenance-Dokument im SLSA-Format ist innerhalb eines Arbeitstages integrierbar und liefert sofortigen Mehrwert für Audit-Prozesse.
SLSA L2 – Der pragmatische CRA-Ziellevel (1–2 Wochen)
L2 fügt die Signierung der Provenance durch den Build-Service hinzu. Mit Sigstore/Cosign in GitHub Actions ist das keyless Signing über GitHub OIDC innerhalb weniger Stunden eingerichtet. Typische Stolpersteine:
- Ephemere Build-Umgebungen: Notwendig für L2, aber anfänglich ungewohnt in Legacy-Pipelines.
- Artefakt-Referenzierung: Container-Images über digest (SHA256) statt Tag referenzieren – Tags sind mutable.
- Verifikations-Integration: Der SLSA Verifier (
slsa-framework/slsa-verifier) muss in Deployment-Prozesse integriert werden, sonst bleibt Provenance wirkungslos.
SLSA L3 – Für hochkritische Systeme (mehrere Monate)
L3 erfordert einen tamper-resistenten Build-Service. Praktisch bedeutet das: Build-Prozesse dürfen nicht durch den Build-Triggerer manipulierbar sein. GitHub Actions erreicht L3 für bestimmte Workflow-Typen bereits nativ. On-Premises-Umgebungen benötigen dedizierte Isolation.
6. Grenzen von SLSA: Was das Framework nicht leistet
SLSA ist kein Allheilmittel. Folgende Lücken bleiben im CRA-Kontext offen:
- Keine Laufzeitsicherheit: SLSA attestiert den Build, nicht das Verhalten zur Laufzeit. Runtime-Monitoring bleibt separate Pflicht.
- Keine automatische Schwachstellenbehebung: SLSA identifiziert was gebaut wurde, ersetzt aber kein Patch-Management oder SLA für Fixes.
- Vertrauen in die Build-Plattform: L2 delegiert Vertrauen an den Build-Service. Ist GitHub Actions kompromittiert, ist auch die Provenance kompromittiert. Hierfür braucht es ergänzend Binary Transparency Logs und regelmäßige Audits der Build-Infrastruktur.
- VEX-Integration fehlt: Der CRA fordert nicht nur Identifikation von Schwachstellen, sondern auch Bewertung der tatsächlichen Ausnutzbarkeit. VEX (Vulnerability Exploitability eXchange)-Dokumente sind ein notwendiges Komplement zu SLSA-basierter SBOM.
- Scope: Source, nicht Design: SLSA adressiert die Build-Phase. Sichere Design-Prinzipien (CRA Anhang I, Part II) liegen außerhalb des Frameworks.
7. Ausblick und Wunschliste
- Automatisierte Maturity Prüfung: Wenn ich meine Organisation entwickeln will, dann brauche ich eine automatisierte Prüfung
- Verifikation der Artefakte: Existiert überhaupt eine Provenance-Attestation? Ist sie im korrekten Format (in-toto / SLSA-Predicate)? Ist sie kryptografisch signiert? Verifiziert die Signatur gegen eine bekannte Identität? Stimmt der Subject-Digest mit dem tatsächlich released Artefakt überein? Ist sie auffindbar/archiviert? Das sind binäre, maschinell verifizierbare Checks — deckt im Wesentlichen L1 und L2 ab.
- Prüfung der Konfigurations- & Metadaten: Läuft der Build gescriptet statt manuell? Auf einer gehosteten Plattform statt vom Entwickler-Laptop? Für den Source-Track: Branch Protection, Zwei-Augen-Review, gepinnte Dependencies, ephemere Runner. Alles abgreifbar über GitHub-/GitLab-/Jenkins-APIs und das Auslesen der Pipeline-Configs.
- DevOps-Plattform-Eigenschaften: SLSA L3 (“unforgeable provenance”, Build-Isolation, Schutz des Signaturmaterials) sind Eigenschaften der Build-Plattform selbst. Aufgabe des Checkers nicht testen, sondern die Vertrauenskette verifizieren und bekannte Plattformen auf ihre SLSA-Fähigkeit mappen
- Wunsch Eine Lösung, die Test-Ergebnisse und Attestationen sammelt, verifiziert, historisiert, zu einem Level verdichtet und Portfolio-weit vergleichbar macht.
8. Fazit und Handlungsempfehlungen
SLSA ist kein CRA-Compliance-Werkzeug out-of-the-box – aber es ist das derzeit ausgreifteste technische Framework, um die Kern-Anforderungen an Build-Integrität und Lieferkettennachvollziehbarkeit strukturiert zu erfüllen.
Drei konkrete Handlungsempfehlungen vor dem CRA-Stichtag:
- Jetzt mit L1 starten: Provenance-Generierung in bestehende CI/CD-Pipelines integrieren. Der Aufwand ist gering, der Compliance-Mehrwert sofort.
- L2 als Minimalziel setzen: Signierte Provenance mit artefaktgebundener SBOM ist der pragmatische Ziellevel für die meisten CRA-pflichtigen Hersteller.
- SLSA komplementär einbetten: SLSA allein reicht nicht. VEX-Dokumente, ein strukturiertes Schwachstellenmanagement und BSI-Orientierungshilfen (BSI TR-03183) vervollständigen den Compliance-Ansatz.
Weiterführende Ressourcen: slsa.dev, OpenSSF SSDF Mapping, BSI CRA-Orientierungshilfe.
Kernergebnisse auf einen Blick:
- SLSA L2 mit Sigstore-Integration adressiert die CRA-Kernanforderungen an Build-Integrität und Nachvollziehbarkeit direkt und mit überschaubarem Aufwand.
- Attestierte, artefaktgebundene Provenance verhindert die in der Praxis häufige Entkopplung von SBOM-Dokumentation und tatsächlichem Artefakt.
- SLSA schließt nicht alle CRA-Lücken – VEX, Runtime-Sicherheit und Patch-Management bleiben eigenständige Pflichten.
