Moderne Software besteht zu einem großen Teil aus fremdem Code: Open-Source-Bibliotheken, Frameworks und Module von Zulieferern. Wird in einer dieser Komponenten eine Lücke bekannt, wie im März 2024 bei der Hintertür in der Kompressionsbibliothek xz utils, beginnt für viele Betriebe die Suche: Wo steckt das überhaupt drin? Die SBOM, auf Deutsch Software-Stückliste, beantwortet diese Frage, ähnlich wie eine Zutatenliste auf einer Lebensmittelverpackung.
Was steht in einer SBOM?
Die US-Behörde NTIA hat 2021 Mindestelemente festgelegt. Zu jeder Komponente gehören:
- Lieferant und Name der Komponente,
- Version und weitere eindeutige Kennungen,
- die Abhängigkeitsbeziehung, also welche Komponente in welcher enthalten ist,
- Ersteller der SBOM-Daten und Zeitstempel.
Dazu kommen Anforderungen an Automatisierung und Abläufe, etwa dass nach jedem neuen Build oder Release eine neue SBOM entsteht. Im Juli 2026 haben CISA, NSA und FBI mit internationalen Partnern aktualisierte Mindestelemente veröffentlicht, die die Fassung von 2021 ersetzen. Neu sind laut CISA unter anderem die Prüfsumme der Komponente, die Lizenz sowie Angaben zum Werkzeug und Kontext der Erstellung.
Formate: SPDX und CycloneDX
Durchgesetzt haben sich zwei offene Formate. SPDX der Linux Foundation ist als ISO/IEC 5962:2021 genormt. CycloneDX, getragen von OWASP, ist seit 2024 als ECMA-424 standardisiert und beschreibt neben Software auch Hardware, Dienste und KI-Modelle. Beide lassen sich von gängigen Build-Werkzeugen automatisch erzeugen. Das deutsche BSI beschreibt Anforderungen an SBOMs in der Technischen Richtlinie TR-03183-2, ausdrücklich als Vorbereitung auf den CRA.
SBOM und Cyber Resilience Act
Der Cyber Resilience Act verpflichtet Hersteller von Produkten mit digitalen Elementen, Schwachstellen und Komponenten zu ermitteln und zu dokumentieren, unter anderem durch eine Software-Stückliste in einem gängigen maschinenlesbaren Format, die zumindest die obersten Abhängigkeiten enthält. Veröffentlichen müssen Hersteller die SBOM nicht; Marktüberwachungsbehörden können sie aber anfordern.
Praxis für KMU und Gemeinden
- Beim Einkauf: Fragen Sie Hersteller von Fachverfahren, Firewalls, Steuerungen oder Apps, ob sie eine SBOM bereitstellen und wie schnell sie bei Lücken in Komponenten informieren.
- Bei Eigenentwicklung: Erzeugen Sie die SBOM automatisch im Build und legen Sie sie zu jeder Version ab.
- Im Betrieb: Gleichen Sie SBOMs mit Schwachstellendatenbanken ab. Ein VEX-Dokument nach CSAF sagt ergänzend, ob eine gefundene CVE im konkreten Produkt überhaupt ausnutzbar ist.
- Im Inventar: Verknüpfen Sie SBOMs mit dem IT-Asset-Management, damit klar ist, auf welchen Systemen ein Produkt läuft.
Grenzen
Eine SBOM macht Software nicht sicherer, sie macht Risiken sichtbar. Sie veraltet mit jedem Update, ist nur so vollständig wie das Werkzeug, das sie erzeugt, und kann vertrauliche Details über die Architektur verraten. Wichtig ist deshalb, wer sie erhält und wie sie aktuell gehalten wird.
Bezug zu TOMORIS
EXPERTS Cyber Security hilft, Schwachstellen nach Wirkung und Dringlichkeit zu bearbeiten, auch wenn sie in Komponenten von Zulieferern stecken. Hintergrund zu Angriffen über Zulieferer bietet der Eintrag Supply-Chain-Angriff.