SBOM und Sigstore: Herkunftsnachweis für Software-Artefakte
Wie CycloneDX, SPDX, cosign, Fulcio und Rekor zusammen belegen, wer eine Binary gebaut hat und woraus. Einordnung von SLSA, in-toto und dem Cyber Resilience Act.
Problem
Lieferkettenangriffe haben in den letzten Jahren den Charakter geaendert. Bei SolarWinds (2020) war der Angriffspfad noch das Build-System eines einzelnen Herstellers. Beim Vorfall um xz-utils im Maerz 2024 war es ein langjaehriger, vermeintlich vertrauenswuerdiger Open-Source-Maintainer, der über Jahre Vertrauen aufbaute und dann eine Hintertuer in Release-Tarballs platzierte. Quellcode im Repository und Release-Artefakt unterschieden sich. Damit wird die Frage "Wer hat dieses Binary aus welchen Quellen gebaut?" zur Pflichtangabe, nicht mehr zur Kuer.
Kurze Antwort
Eine tragfaehige Antwort auf Lieferkettenangriffe besteht aus drei Bausteinen: einer maschinenlesbaren Stückliste (SBOM), einer kryptographisch überpruefbaren Signatur auf dem Artefakt und einem Nachweis, unter welchen Bedingungen es gebaut wurde. Die heute etablierten Umsetzungen dafuer heissen CycloneDX bzw. SPDX, sigstore und das SLSA-Framework mit in-toto-Attestierungen.
Tiefgang
SBOM-Formate: CycloneDX versus SPDX
Ein Software Bill of Materials ist eine strukturierte Liste der Komponenten eines Artefakts inklusive Versionen, Lizenzen und Hashes. Zwei Formate dominieren.
CycloneDX wurde 2017 bei OWASP gestartet und zielt auf Anwendungs-Sicherheit. Schwerpunkt sind Vulnerability-Bezug, Abhaengigkeitsgraphen und Attestierungen. Das Format ist als JSON, XML und Protobuf definiert und kennt explizite Typen für Services, Machine-Learning-Modelle und Hardware-Komponenten.
SPDX entstand 2010 in der Linux Foundation und ist seit 2021 als ISO/IEC 5962:2021 standardisiert. Der Fokus lag lange auf Lizenz-Compliance; mit SPDX 3.0 kamen Security- und Build-Profile hinzu. SPDX ist das Format, das der NTIA-Mindestbestand ausdruecklich als kompatibel anerkennt.
In der Praxis erzeugen Werkzeuge wie syft beide Formate aus demselben Scan. Die Wahl haengt weniger am technischen Gehalt als am Empfaenger: Regulatoren tendieren zu SPDX, AppSec-Teams haeufig zu CycloneDX.
Sigstore: Fulcio, Rekor, cosign
Klassisches Code-Signing scheitert im Open-Source-Umfeld an der Schlüsselverwaltung. Langlebige Signierschluessel müssen geschuetzt, rotiert und widerrufen werden, und jeder verlorene Schlüssel bedeutet Chaos.
Sigstore dreht das Modell um. Statt langlebiger Schlüssel werden kurzlebige Zertifikate auf Basis einer OIDC-Identitaet ausgestellt.
Fulcio ist die Certificate Authority. Ein Entwickler oder ein CI-System weist sich per OIDC-Token aus (GitHub Actions, Google, GitLab), Fulcio bindet die Identitaet aus dem Token in ein X.509-Zertifikat mit typischerweise zehn Minuten Gültigkeit ein. Signiert wird mit einem lokal erzeugten Schlüsselpaar, der Schlüssel kann danach verworfen werden.
Rekor ist ein append-only Transparency-Log nach dem Muster von Certificate Transparency. Jede Signatur wird dort als Eintrag hinterlegt, inklusive Zertifikat und Artefakt-Hash. Wer ein Artefakt verifiziert, prüft nicht nur die Signatur gegen das Fulcio-Zertifikat, sondern auch, dass der Eintrag im Log liegt und das Log konsistent fortgeschrieben wurde.
cosign ist das Kommandozeilenwerkzeug, das diese Bausteine für Container-Images, OCI-Artefakte und beliebige Blobs orchestriert. cosign sign erzeugt eine Signatur im OIDC-Flow, cosign verify prüft sie gegen eine Policy aus Identitaet und Issuer.
SLSA-Level
SLSA ("Supply-chain Levels for Software Artifacts") beschreibt, wie belastbar die Aussage über die Herkunft eines Artefakts ist. Version 1.0 hat vier Stufen.
Level 0 bedeutet, es gibt keine Anforderungen; Level 0 ist lediglich ein Einstiegspunkt. Level 1 verlangt, dass der Build-Prozess ein maschinenlesbares Provenance-Dokument erzeugt, das Quellcode-Revision, Build-Umgebung und Eingabe-Parameter benennt. Level 2 setzt zusaetzlich voraus, dass die Provenance von einem gehosteten Build-Dienst signiert wird und nicht vom Entwickler lokal erzeugt werden kann. Level 3 fordert, dass der Build-Dienst selbst gehaertet ist: isolierte Builds, Schutz gegen Manipulation der Provenance während des Laufs, keine persistenten Secrets zwischen Builds. Level 4 wurde in v1.0 zurückgestellt; die urspruenglichen Anforderungen (hermetische, reproduzierbare Builds, Zwei-Personen-Review) leben in einem Entwurf weiter.
Zu beachten: SLSA-Level sind nicht kumulativ transitiv. Ein Artefakt auf Level 3 sagt nichts über die Stufe seiner Abhaengigkeiten. Eine SBOM, die die Level der Transit-Abhaengigkeiten auflistet, ergänzt SLSA daher zwingend.
xz-utils als Testfall
Der Vorfall um CVE-2024-3094 ist instruktiv, weil er genau an der Stelle zuschlug, wo viele SBOM-Pipelines blind sind. Andres Freund meldete die Hintertuer am 29. Maerz 2024 auf der oss-security-Liste; Russ Cox hat die Zeitleiste rekonstruiert. Der schadhafte Code lag nicht im Git-Repository, sondern in den M4-Dateien des Release-Tarballs und wurde nur beim Build aus dem Tarball aktiv.
Eine SBOM haette xz-utils 5.6.0 oder 5.6.1 als Komponente sichtbar gemacht. Das nutzt bei einer perfekt getarnten Hintertuer in einer legitim veroeffentlichten Version zunaechst nichts. Was geholfen haette, sind SLSA-Level-3-Builds mit hermetischer Build-Umgebung aus dem Git-Baum statt aus dem Tarball. Beides zusammen, SBOM für Inventur und reproduzierbare Builds für Integritaet, ergibt die Schutzwirkung. Keins der beiden allein.
Europaeischer Rahmen: Cyber Resilience Act
Der Cyber Resilience Act (Verordnung 2024/2847) ist am 10. Dezember 2024 in Kraft getreten und gilt ab dem 11. Dezember 2027 vollumfaenglich. Hersteller von "Produkten mit digitalen Elementen", die in der EU in Verkehr gebracht werden, müssen dann eine SBOM über die Hauptkomponenten mitliefern können und Schwachstellen über den Support-Zeitraum behandeln. Die Meldepflicht für aktiv ausgenutzte Schwachstellen greift bereits früher, ab dem 11. September 2026.
Abgelehnte Alternativen
Proprietaere, langlebige GPG-Schluessel der Maintainer wurden verworfen, weil Schlüsselverlust bzw. Schlüsselkompromittierung im OSS-Umfeld regelmäßig vorkommt und eine globale Revozierung nicht praktikabel ist. Reine Hash-Listen ohne Transparency-Log scheiden aus, weil sie keinen Nachweis liefern, dass ein Hash nicht nachtraeglich durch den Herausgeber gegen einen anderen ausgetauscht wurde. Signaturen ohne Build-Provenance wurden ebenfalls verworfen, weil sie nur bezeugen, dass jemand mit Zugriff auf den Schlüssel signiert hat, nicht aber, unter welchen Quellen und in welcher Umgebung der Build lief.
Wie Dernium hier hilft
Dernium Scan analysiert hochgeladene Dateien statisch und liefert Strukturbefunde. Eine SBOM konsumiert Scan aktuell nicht; das ist auf der Roadmap, aber noch nicht implementiert. Wer heute eine SBOM zu einer Datei ablegen will, muss sie extern erzeugen.
Offene Punkte
Rekor v2 und die Frage, ob wir eine private Rekor-Instanz für Kundenartefakte betreiben oder die öffentliche Sigstore-Infrastruktur nutzen, ist nicht entschieden. Ebenso offen ist, ob Scan kuenftig eine SBOM selbst erzeugt (via syft) oder eine mitgelieferte SBOM nur verifiziert.