Eine SBOM ist ein maschinenlesbares Dokument und entspricht einer elektronischen Stückliste: Es inventarisiert eine Codebasis und enthält somit Informationen über alle verwendeten Komponenten einer Software. Inzwischen gewinnt die SBOM durch den CRA erhebliche juristische Relevanz und gehört zwingend zur Compliance bei Einsatz oder Entwicklung von Software, speziell mit Blick auf die Supply-Chain.
Die SBOM-Informationen können in unterschiedlicher Breite und Tiefe dargestellt werden und von einer groben Struktur bis zu einer detaillierten Aufschlüsselung von Produkten und Softwarekomponenten reichen. Entsprechende Vorgaben sind in der Technischen Richtlinie TR-03183 des BSI enthalten.
Bedeutung der SBOM
Eine SBOM sollte bei jedem Softwarehersteller und -anbieter vorhanden sein, um die Komplexität von Software transparent darstellen zu können und um zu wissen, welche Komponenten (z.B. Bibliotheken) verwendet werden, da fast immer eine Vielzahl unterschiedlicher Quellen und Komponenten genutzt wird. Dieses Wissen ist für Softwaremanagementprozesse, insbesondere für einen durchgängigen IT-Sicherheitsprozess und das Software-Lifecycle-Management unabdingbar und gilt daher als „Best Practice“ einer sicheren Software-Lieferkette. Gleichzeitig ist es für die Open Source Compliance nützlich.
Mit Hilfe von SBOM-Informationen kann überprüft werden, ob ein Produkt potenziell von einer Schwachstelle betroffen ist, indem die Komponentenliste des Produkts mit den in den Schwachstelleninformationen aufgeführten Softwarekomponenten verglichen wird. Durch diese standardisierte Abklärung dürfte es sich aus Sicht des Managements um eine Standardmaßnahme zur Vermeidung eigener Haftung handeln.
Eine SBOM enthält jedoch keine Aussage über Schwachstellen oder deren Ausnutzbarkeit. Ob und inwieweit von einer Schwachstelle einer verwendeten Softwarekomponente ein Risiko für das in der SBOM beschriebene Produkt ausgeht, geht aus der SBOM ebenfalls nicht hervor. Hierzu sind weitere Informationen über die konkrete Schwachstelle erforderlich, z.B. über Security Advisories oder VEX1 (Vulnerability Exploitability Exchange).
Auswirkungen des CRA: SBOM-Pflicht
Die Erstellung einer SBOM ist im Cyber Resilience Act (CRA) verpflichtend vorgesehen. Der CRA verankert die SBOM als zentrales Compliance-Instrument, um Transparenz und Sicherheit in der Lieferkette digitaler Produkte zu stärken. Die SBOM fungiert dabei als detailliertes „Inhaltsverzeichnis“ aller Softwarekomponenten – von proprietären Modulen bis zu Open-Source-Bibliotheken –, das Versionsangaben und Abhängigkeiten enthält.
Hersteller sind durch diese Pflichtdokumentation dazu verpflichtet, nicht nur ihre eigenen Entwicklungen, sondern auch Drittkomponenten lückenlos zu erfassen und über den gesamten Produktlebenszyklus hinweg aktuell zu halten. Dadurch ist es möglich, Sicherheitslücken schneller zu identifizieren und gezielt zu schließen, beispielsweise wenn eine bekannte Schwachstelle in einer eingebetteten Bibliothek auftritt. Zwar ist die SBOM primär für Behörden und interne Prozesse bestimmt, doch auch Kunden profitieren indirekt davon: Sie erhalten Klarheit über die Unterstützungsdauer von Updates und können Risiken in ihrer IT-Infrastruktur besser einschätzen.
Für Unternehmen bedeutet die SBOM-Pflicht einen Paradigmenwechsel im Risikomanagement. Bisher führten undokumentierte Abhängigkeiten oft zu verzögerten Reaktionen auf Exploits, wie im Fall von Log4Shell. Der CRA zwingt Hersteller nun, ihre Software-Lieferketten systematisch zu überwachen und proaktiv zu warten. Gleichzeitig dient die SBOM als Nachweisinstrument für Compliance, etwa gegenüber Marktaufsichtsbehörden oder im Haftungsfall. Denn wer nachweisen kann, dass alle Komponenten gemäß den CRA-Standards gepflegt wurden, minimiert rechtliche Risiken. Die SBOM wird somit zum Bindeglied zwischen technischer Sicherheit und regulatorischer Absicherung und ist ein Werkzeug, das nicht nur Bürokratie schafft, sondern auch die Resilienz digitaler Produkte nachhaltig erhöht. Ihre Einführung unterstreicht, wie der CRA Cybersicherheit als dynamischen Prozess begreift – von der Entwicklung („Security by Design“) bis zur Außerbetriebnahme.
Übrigens: Im US-amerikanischen Raum wird die SBOM durch die US Executive Order 14028 vom Mai 2021 bereits für Anwendungen im Behördenumfeld gefordert. Seit März 2023 muss zudem bei der Zulassung von Medizinprodukten zwingend eine SBOM seitens der FDA (Food and Drug Administration) vorgelegt werden.
- Veränderungssperren bei Software-Besichtigungen - Oktober 6, 2025
- Cybersecurity in der Software-Lieferkette - September 24, 2025
- Software Bill of Materials (SBOM) - September 14, 2025
