Bild: Generiert mit Gemini Flash

SBOM und Sigstore: Herkunftsnachweis für Software-Artefakte

7 Min Lesezeit Serie: CRA-Reihe #sbom#sigstore#supply-chain#slsa#cra#security

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.

Inhalt dieses Beitrags
  1. Problem
  2. Kurze Antwort
  3. Tiefgang
  4. SBOM-Formate: CycloneDX versus SPDX
  5. Sigstore: Fulcio, Rekor, cosign
  6. SLSA-Level
  7. xz-utils als Testfall
  8. Europäischer Rahmen: Cyber Resilience Act
  9. Abgelehnte Alternativen
  10. Was Sie jetzt tun sollten
  11. Wie Dernium hier hilft
  12. Offene Punkte
  13. Häufige Fragen
  14. Brauche ich sowohl eine SBOM als auch eine Signatur, oder reicht eines?
  15. Warum sind kurzlebige Schlüssel besser als ein dauerhafter Signaturschlüssel?
  16. Hätte eine SBOM den xz-utils-Angriff verhindert?
  17. Muss ich als kleiner Softwarehersteller wegen des CRA jetzt SBOMs erstellen?
  18. Welches SBOM-Format soll ich wählen, CycloneDX oder SPDX?
  19. Mehr aus unserer CRA-Reihe

Problem

Lieferkettenangriffe haben ihren Charakter geändert. Bei SolarWinds (2020) lief der Angriff über das Build-System (die Software-Fabrik, die aus Quellcode das fertige Programm baut) eines Herstellers. Beim Vorfall um xz-utils im März 2024 baute ein scheinbar vertrauenswürdiger Open-Source-Entwickler über Jahre Vertrauen auf und schmuggelte dann eine Hintertür ins ausgelieferte Paket; Quellcode im Archiv und Paket unterschieden sich. So wird "Wer hat das aus welchen Quellen gebaut?" zur Pflicht statt Kür.

Für wen ist das? Für Entwicklungsteams und Sicherheitsverantwortliche, die ihre Software-Lieferkette absichern.

Kurze Antwort

Ein belastbarer Herkunftsnachweis für Software steht auf drei Säulen, die einzeln nur Teilauskunft geben und erst zusammen tragen:

  • Stückliste (SBOM): ein maschinenlesbares Inventar aller enthaltenen Komponenten - etabliert sind die Formate CycloneDX und SPDX.
  • Signatur: ein fälschungssicheres Echtheitssiegel - etabliert ist sigstore mit kurzlebigen Schlüsseln.
  • Herkunftsnachweis: ein Beleg der Build-Bedingungen (Quellen, Umgebung) - etabliert ist SLSA mit in-toto-Nachweisen.

Tiefgang

SBOM, Signatur und Herkunftsnachweis belegen erst zusammen, was ein Software-Artefakt ist und woher es stammt.
SBOM, Signatur und Herkunftsnachweis belegen erst zusammen, was ein Software-Artefakt ist und woher es stammt.

SBOM-Formate: CycloneDX versus SPDX

Eine SBOM (Software Bill of Materials, Software-Stückliste) listet alle Komponenten samt Versionen, Lizenzen und Prüfsummen (kurze Zahlenwerte, die eine Datei eindeutig kennzeichnen). Zwei Formate dominieren:

CycloneDX, 2017 bei OWASP gestartet, zielt auf Anwendungs-Sicherheit: Bezug zu bekannten Schwachstellen, Abhängigkeitsgraphen (welche Komponente von welcher abhängt) und Herkunftsnachweise, mit eigenen Typen für Dienste, KI-Modelle und Hardware. 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 3.0 kamen Sicherheits- und Build-Profile dazu. Der NTIA-Mindestbestand (von der US-Telekommunikationsbehörde definierte Pflichtangaben einer SBOM) erkennt es ausdrücklich als kompatibel an. Werkzeuge wie syft erzeugen beide aus demselben Scan; die Wahl hängt vom Empfänger ab: Regulatoren zu SPDX, Sicherheitsteams zu CycloneDX.

Sigstore: Fulcio, Rekor, cosign

Keyless Signing: Statt eines dauerhaften Schlüssels weist eine OIDC-Identität ein kurzlebiges Fulcio-Zertifikat zu; die Signatur landet öffentlich im Rekor-Transparenzlog.
Keyless Signing: Statt eines dauerhaften Schlüssels weist eine OIDC-Identität ein kurzlebiges Fulcio-Zertifikat zu; die Signatur landet öffentlich im Rekor-Transparenzlog.

Klassisches Signieren von Code scheitert im Open-Source-Umfeld an der Schlüsselverwaltung: Langlebige Signierschlüssel müssen geschützt, ausgetauscht und im Notfall widerrufen werden, jeder verlorene sorgt für Chaos.

Sigstore dreht das um: statt langlebiger Schlüssel kurzlebige Zertifikate auf Basis einer bestehenden Anmelde-Identität (etwa GitHub- oder Google-Login). Drei Bausteine greifen ineinander:

  • Fulcio stellt Zertifikate aus: Ein Entwickler oder Build-System weist sich per Anmelde-Token (kurzlebiger Berechtigungsnachweis nach dem Login) aus (GitHub Actions, Google, GitLab), Fulcio bindet die Identität in ein Zertifikat mit typischerweise zehn Minuten Gültigkeit. Signiert wird mit einem lokal erzeugten, danach verworfenen Schlüssel.
  • Rekor ist ein nur erweiterbares, nicht änderbares Transparenz-Register (öffentliches Logbuch, in das nur angehängt, nie etwas gelöscht werden kann). Jede Signatur landet dort als Eintrag samt Zertifikat und Prüfsumme. Wer prüft, kontrolliert auch, dass der Eintrag vorliegt und das Register nachvollziehbar fortgeschrieben wurde.
  • cosign führt diese Bausteine als Kommandozeilenwerkzeug für Container-Images und Dateien zusammen: cosign sign signiert, cosign verify prüft gegen erwartete Identität und Aussteller.

SLSA-Level

SLSA ("Supply-chain Levels for Software Artifacts", Stufen für die Lieferketten-Sicherheit von Software-Artefakten) beschreibt, wie belastbar die Herkunftsaussage über ein Programm ist. Version 1.0 kennt vier Stufen.

Level 0 stellt keine Anforderungen, nur ein Einstiegspunkt. Level 1 verlangt einen maschinenlesbaren Herkunftsnachweis aus dem Build, der Quellcode-Stand, Build-Umgebung und Eingabe-Parameter nennt. Level 2 fordert zusätzlich, dass ein gehosteter Build-Dienst diesen Nachweis signiert, nicht der Entwickler. Level 3 verlangt einen gehärteten Build-Dienst: abgeschottete Builds, Schutz des Nachweises gegen Manipulation zur Laufzeit, keine dauerhaften Geheimnisse zwischen Builds. Level 4 wurde in v1.0 zurückgestellt; die ursprünglichen Anforderungen (reproduzierbare Builds, Vier-Augen-Prüfung) leben in einem Entwurf weiter.

Zu beachten: SLSA-Level vererben sich nicht. Ein Programm auf Level 3 sagt nichts über die Stufe seiner Bausteine; eine SBOM, die die Level der Abhängigkeiten auflistet, ergänzt SLSA zwingend.

xz-utils als Testfall

Der Vorfall um CVE-2024-3094 (CVE ist die weltweite Kennnummer einer öffentlich bekannten Schwachstelle) ist lehrreich, weil er dort zuschlug, wo SBOMs blind sind. Andres Freund meldete die Hintertür am 29. März 2024 (Russ Cox hat die Zeitleiste rekonstruiert). Der schadhafte Code lag nicht im Quellcode-Archiv, sondern in Zusatzdateien des Pakets und wurde nur beim Bauen daraus aktiv.

Eine SBOM hätte xz-utils 5.6.0 oder 5.6.1 als Komponente sichtbar gemacht, was bei einer perfekt getarnten Hintertür in einer regulären Version zunächst nichts hilft. Geholfen hätten SLSA-Level-3-Builds, die abgeschottet aus dem Quellcode-Archiv statt dem Paket bauen. Erst beides zusammen, SBOM für die Inventur, reproduzierbare Builds für die Integrität, ergibt Schutz; keins allein.

Europäischer Rahmen: Cyber Resilience Act

Der Cyber Resilience Act (CRA, EU-Verordnung zur Cyber-Widerstandsfähigkeit von Produkten, Verordnung 2024/2847) ist am 10. Dezember 2024 in Kraft getreten und gilt ab 11. Dezember 2027 vollumfänglich. Hersteller von "Produkten mit digitalen Elementen", die in der EU in Verkehr gebracht werden, müssen dann eine SBOM über die Hauptkomponenten bereitstellen können und Schwachstellen über den Support-Zeitraum behandeln. Die Meldepflicht für aktiv ausgenutzte Schwachstellen greift schon ab 11. September 2026.

Abgelehnte Alternativen

Langlebige GPG-Schlüssel (klassische, dauerhaft genutzte Signaturschlüssel) der Maintainer wurden verworfen, weil Schlüsselverlust und -kompromittierung im Open-Source-Umfeld regelmäßig vorkommen und ein nachträgliches Ungültigmachen nicht praktikabel ist. Reine Prüfsummen-Listen ohne Transparenz-Register scheiden aus, weil sie nicht belegen, dass der Herausgeber einen Wert nicht nachträglich ausgetauscht hat. Signaturen ohne Herkunftsnachweis wurden verworfen, weil sie nur bezeugen, dass jemand mit Schlüsselzugriff signiert hat, nicht aus welchen Quellen und welcher Umgebung.

Was Sie jetzt tun sollten

  1. Erzeugen Sie für Ihre eigenen Programme automatisiert eine SBOM im Build (etwa mit syft) und legen Sie sie zusammen mit dem Artefakt ab - so haben Sie jederzeit ein Inventar Ihrer Komponenten.
  2. Signieren Sie Ihre Container-Images und Releases mit sigstore/cosign aus Ihrem Build-System heraus, nicht von Hand am Entwicklerrechner.
  3. Prüfen Sie eingehende Artefakte: Verlangen Sie SBOMs von Zulieferern und verifizieren Sie deren Signaturen mit cosign verify gegen erwartete Identität und Aussteller.
  4. Spielen Sie Ihren Build-Dienst Schritt für Schritt in Richtung SLSA Level 2 bis 3 (signierter, abgeschotteter Build) - das schützt gegen die xz-Klasse von Angriffen, die eine SBOM allein nicht sieht.
  5. Notieren Sie für den CRA die zwei Stichtage (Meldepflicht ab 11. September 2026, volle Geltung ab 11. Dezember 2027) und ordnen Sie die SBOM-Pflicht Ihren Produkten zu.

Wie Dernium hier hilft

Dernium Scan analysiert hochgeladene Dateien statisch und liefert Strukturbefunde. Eine SBOM verarbeitet Scan aktuell nicht; das steht auf der Roadmap, ist aber noch nicht umgesetzt. Wer heute eine SBOM zu einer Datei ablegen will, erzeugt sie extern.

Offene Punkte

Nicht entschieden ist, ob wir ein eigenes Transparenz-Register (Rekor v2) für Kundenartefakte betreiben oder die öffentliche Sigstore-Infrastruktur nutzen. Ebenso offen, ob Scan künftig eine SBOM selbst erzeugt (via syft) oder eine mitgelieferte nur prüft.

Häufige Fragen

Brauche ich sowohl eine SBOM als auch eine Signatur, oder reicht eines?

Sie brauchen beides, weil sie verschiedene Fragen beantworten. Die SBOM sagt, was in einem Programm steckt (welche Komponenten in welcher Version). Die Signatur sagt, dass das Programm echt ist und nicht unterwegs verändert wurde. Eine SBOM ohne Signatur kann manipuliert sein, eine Signatur ohne SBOM verrät nichts über den Inhalt. Der Herkunftsnachweis (SLSA) ergänzt beide um die Frage, unter welchen Bedingungen gebaut wurde.

Warum sind kurzlebige Schlüssel besser als ein dauerhafter Signaturschlüssel?

Ein dauerhafter Schlüssel muss über Jahre sicher aufbewahrt werden; geht er verloren oder wird gestohlen, lässt sich das im Open-Source-Umfeld kaum sauber rückgängig machen. Sigstore vergibt stattdessen Zertifikate mit nur etwa zehn Minuten Gültigkeit, gebunden an eine geprüfte Anmelde-Identität. Der eigentliche Schlüssel wird sofort nach dem Signieren verworfen, es gibt also nichts mehr zu stehlen.

Hätte eine SBOM den xz-utils-Angriff verhindert?

Nein, nicht allein. Die Hintertür steckte in einer regulär aussehenden Version, die eine SBOM nur als gewöhnliche Komponente aufgeführt hätte. Geholfen hätten abgeschottete, reproduzierbare Builds (SLSA Level 3), die direkt aus dem geprüften Quellcode-Archiv bauen statt aus dem manipulierten Paket. Der Fall zeigt, dass Inventar und Herkunftsnachweis sich ergänzen müssen.

Muss ich als kleiner Softwarehersteller wegen des CRA jetzt SBOMs erstellen?

Wenn Sie Produkte mit digitalen Elementen in der EU in den Verkehr bringen, ja - der Cyber Resilience Act verlangt eine SBOM über die Hauptkomponenten. Die volle Pflicht greift ab dem 11. Dezember 2027, die Meldepflicht für aktiv ausgenutzte Schwachstellen schon ab dem 11. September 2026. Es lohnt sich, die SBOM-Erzeugung früh in den Build einzubauen, statt kurz vor dem Stichtag nachzurüsten.

Welches SBOM-Format soll ich wählen, CycloneDX oder SPDX?

Beide sind anerkannt, und gängige Werkzeuge erzeugen sie aus demselben Scan. Richten Sie sich nach dem Empfänger: Sicherheitsteams arbeiten meist mit CycloneDX (Schwachstellen- und Abhängigkeitsbezug), Regulatoren und Lizenz-Prozesse eher mit SPDX (ISO-standardisiert). Im Zweifel können Sie beide Formate parallel erzeugen.

Mehr aus unserer CRA-Reihe