Software Supply Chain Security: Wie SBOMs die Transparenz schaffen, die gefehlt hat

1 Min. Lesezeit

SolarWinds, Log4Shell, MOVEit – jeder große Supply-Chain-Angriff der letzten Jahre hätte mit einer Software Bill of Materials (SBOM) schneller eingedämmt werden können. SBOMs listen jede Komponente einer Software auf und ermöglichen in Minuten, was ohne sie Wochen dauert: feststellen, ob man betroffen ist.

Das Wichtigste in Kürze

US Executive Order 14028 macht SBOMs zur Pflicht für Bundesbehörden-Zulieferer
EU Cyber Resilience Act fordert SBOM ab 2027 für alle digitalen Produkte
Formate: SPDX (Linux Foundation) und CycloneDX (OWASP)
NTIA definiert Mindestanforderungen: Supplier, Component, Version, Dependency

Was eine SBOM konkret ist

Eine SBOM ist eine maschinenlesbare Liste aller Softwarekomponenten: Bibliotheken, Frameworks, Abhängigkeiten – mit Name, Version, Lizenz und Herkunft. Vergleichbar mit einer Zutatenliste bei Lebensmitteln: Man weiß, was drin ist.

In der Praxis: Wenn eine neue Schwachstelle wie Log4Shell bekannt wird, kann ein Unternehmen mit SBOMs in Minuten feststellen, welche Produkte die betroffene Komponente enthalten. Ohne SBOM beginnt eine wochenlange manuelle Suche.

Regulatorischer Druck wächst

Die USA haben vorgelegt: Executive Order 14028 verpflichtet Software-Lieferanten der Bundesregierung, SBOMs bereitzustellen. Die EU folgt mit dem Cyber Resilience Act (CRA), der SBOMs ab 2027 für alle digitalen Produkte vorschreibt, die in der EU verkauft werden.

Für deutsche Softwareunternehmen und Hersteller digitaler Produkte ist das ein Countdown: Wer 2027 keine SBOM liefern kann, verliert den Marktzugang – in den USA und der EU.

Integration in den Entwicklungsprozess

SBOMs sollten nicht nachträglich erstellt werden, sondern automatisch im Build-Prozess generiert werden. Tools wie Syft, Trivy, CycloneDX CLI oder SPDX-Tools integrieren sich in CI/CD-Pipelines und erzeugen SBOMs bei jedem Release.

Der Workflow: Build generiert SBOM, SBOM wird gegen Schwachstellendatenbanken (NVD, OSV) geprüft, bei kritischen Findings wird der Release blockiert. Das ist DevSecOps in der Praxis – Transparenz als automatisierter Qualitätsstandard.

SBOM-Management: Mehr als nur Erstellen

Eine SBOM zu generieren ist der erste Schritt. Der eigentliche Wert entsteht durch kontinuierliches SBOM-Management: Neue CVEs werden automatisch gegen bestehende SBOMs geprüft, Kunden erhalten proaktive Benachrichtigungen bei betroffenen Komponenten, und die SBOM wird bei jedem Update aktualisiert.

Plattformen wie Dependency-Track (OWASP, Open Source) oder kommerzielle Lösungen wie Anchore und Sonatype automatisieren diesen Lebenszyklus. Der Aufwand ist gering – der Nutzen im Ernstfall enorm.

Key Facts

Transparenz: SBOM reduziert die Reaktionszeit bei neuen CVEs von Wochen auf Minuten

Regulierung: US EO 14028 + EU CRA machen SBOM zur Pflicht bis 2027

Adoption: SBOM-Erstellung stieg nach Log4Shell um 300 Prozent (Sonatype)

Häufige Fragen

Welches Format soll ich nutzen?

CycloneDX (OWASP) für Security-fokussierte SBOMs, SPDX (Linux Foundation) für Lizenz-Compliance. Beide sind maschinenlesbar und konvertierbar. CycloneDX hat bessere VEX-Integration (Vulnerability Exploitability eXchange).

Muss ich SBOMs für Open-Source-Abhängigkeiten erstellen?

Ja – gerade dort liegt der Hauptnutzen. Die meisten modernen Anwendungen bestehen zu 70-90 Prozent aus Open-Source-Komponenten. Ohne SBOM dieser Abhängigkeiten ist das Schwachstellenmanagement blind.

Wie teile ich SBOMs mit Kunden?

Drei Modelle: Direkte Bereitstellung mit jedem Release, Zugang zu einem SBOM-Portal, oder auf Anfrage. Der CRA wird wahrscheinlich die proaktive Bereitstellung vorschreiben. Etablieren Sie jetzt einen Prozess, bevor die Pflicht greift.