Was ist eine SBOM?

SBOM einfach erklärt

SBOM steht für Software Bill of Materials. Kaum eine Software wird heute komplett selbst geschrieben. Entwicklungsteams greifen auf fertige Bausteine zurück: Open-Source-Bibliotheken, also frei verfügbare Programmbausteine, Komponenten von Drittanbietern und fertige Programmgerüste, sogenannte Frameworks. Diese Bausteine nutzen ihrerseits weitere Bausteine. So entsteht ein dichtes Geflecht von Abhängigkeiten, das niemand mehr aus dem Kopf überblickt.

Eine SBOM macht dieses Geflecht sichtbar. Der Begriff stammt aus der Industrie: Eine „Bill of Materials“ ist die Stückliste, die jedes Bauteil eines Produkts aufführt. Noch anschaulicher ist die Zutatenliste auf einer Lebensmittelverpackung. Wer gegen Nüsse allergisch ist, erkennt sofort, ob ein Produkt Nüsse enthält. Eine SBOM zeigt entsprechend, ob eine Software einen Baustein enthält, der gerade als unsicher gemeldet wurde.

„Maschinenlesbar“ bedeutet: Die Liste liegt nicht als PDF vor, sondern in einem standardisierten Datenformat, das Programme automatisch auswerten können.

So funktioniert eine SBOM

Eine SBOM enthält für jeden Baustein typischerweise:

1. Name und Version, damit klar ist, welche Ausgabe genau verbaut ist.
2. Herkunft, also das Projekt oder den Hersteller, von dem der Baustein stammt.
3. Eindeutige Kennungen, über die sich der Baustein in Schwachstellendatenbanken wiederfinden lässt.
4. Abhängigkeiten, also welcher Baustein welchen anderen nutzt – auch über mehrere Ebenen hinweg.
5. Lizenzen, die regeln, unter welchen Bedingungen der Baustein genutzt werden darf.

Erstellt wird eine SBOM meist automatisch beim Zusammenbauen der Software, dem sogenannten Build. Verbreitete Formate sind SPDX und CycloneDX. Welche Angaben eine SBOM enthalten sollte, beschreibt das BSI in seiner Technischen Richtlinie TR-03183-2. Gleicht ein Werkzeug die SBOM regelmäßig mit Schwachstellendatenbanken ab, etwa mit den CVE-Einträgen, meldet es betroffene Produkte automatisch.

Ein Beispiel aus der Praxis

Ein Hersteller von Zeiterfassungsterminals erfährt, dass in einer weitverbreiteten Open-Source-Bibliothek eine kritische Schwachstelle entdeckt wurde. Dank seiner SBOMs sieht das Team innerhalb weniger Minuten: Zwei von fünf Gerätegenerationen enthalten die betroffene Version. Eingebunden wurde sie nicht direkt, sondern über eine andere Bibliothek – davon wusste im Team niemand.

Der Hersteller stellt für die betroffenen Geräte gezielt ein Update bereit und informiert seine Kunden. Ohne SBOM hätte er jede Firmware einzeln untersuchen müssen, während Angreifer womöglich schon nach verwundbaren Geräten suchten.

Warum ist das für Unternehmen wichtig?

Wie wichtig dieser Überblick ist, zeigte Ende 2021 die Schwachstelle Log4Shell in der Java-Bibliothek Log4j: Viele Unternehmen wussten zunächst nicht, in welchen ihrer Anwendungen und Geräte die Bibliothek überhaupt steckte. Wer eine aktuelle SBOM hatte, konnte diese Frage deutlich schneller beantworten – und gezielt handeln.

Zudem wird die SBOM zur Pflicht. Der Cyber Resilience Act verlangt von Herstellern von Produkten mit digitalen Elementen, die enthaltenen Komponenten zu dokumentieren. Dazu gehört eine SBOM in einem gängigen, maschinenlesbaren Format. Sie muss zumindest die Abhängigkeiten der obersten Ebene erfassen, also die Bausteine, die direkt in das Produkt eingebunden sind. Die SBOM ist Teil der technischen Dokumentation: Auf begründetes Verlangen müssen Hersteller sie den Marktüberwachungsbehörden vorlegen. Veröffentlichen müssen sie die Stückliste nicht. Diese Anforderungen gelten ab dem 11. Dezember 2027. Schon seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden.

Auch wer Software nur einkauft, profitiert: Mit den SBOMs seiner Lieferanten lässt sich schneller einschätzen, ob eine neue Schwachstelle oder ein Supply-Chain-Angriff das eigene Unternehmen betrifft.

Was Unternehmen jetzt tun sollten

• Betroffenheit klären: Prüfen Sie, ob Sie Produkte mit digitalen Elementen in der EU in Verkehr bringen und damit unter den Cyber Resilience Act fallen.
• SBOM automatisch erzeugen: Lassen Sie die Stückliste bei jedem Build automatisch erstellen, statt sie von Hand zu pflegen.
• Ein Format wählen: Setzen Sie auf ein verbreitetes Format wie SPDX oder CycloneDX und orientieren Sie sich an der BSI TR-03183-2.
• Laufend abgleichen: Gleichen Sie Ihre SBOMs regelmäßig mit Schwachstellendatenbanken ab und legen Sie fest, wer bei einem Treffer handelt.
• Lieferanten einbeziehen: Fordern Sie SBOMs für zugekaufte Software und Komponenten an.
• Vollständigkeit prüfen: Kontrollieren Sie stichprobenartig, ob auch indirekt eingebundene Bausteine erfasst sind.

Wie Rootsektor unterstützt

Im Rahmen unserer Leistung Code Review & Reverse Engineering erstellen und prüfen wir SBOMs, analysieren Abhängigkeiten auf bekannte Schwachstellen und bewerten die Integrität Ihrer Build-Kette, also des Prozesses, in dem Ihre Software entsteht. Liegt kein Quellcode vor, etwa bei zugekaufter Firmware, hilft Reverse Engineering, die enthaltenen Bausteine zu identifizieren. Nach dem Scoping erhalten Sie ein Festpreisangebot – anfragen können Sie es über unser Pentest-Angebot.