Alles SBOM oder was?

Es spricht sich «essbomm» und hört sich seltsam an. Korrekt geschrieben lautet die Abkürzung SBOM. Sie steht für «Software Bill of Materials». Was ist das? Wer nicht in einem Umfeld arbeitet, in dem produziert wird, erkennt schwerlich, worum es geht. Geheimnis gelüftet: Es handelt sich bei einer SBOM um eine spezielle Form der Stückliste, nämlich um eine Softwarestückliste. Und wofür benötigt man diese? Stücklisten dokumentieren, aus welchen Einzelbauteilen ein Produkt besteht. Die nachfolgenden Ausführungen sollen erläutern, warum sie hinsichtlich Cybersecurity und im Zusammenhang mit dem Cyber Resilience Act (CRA) von erheblicher Bedeutung sind. Zu diesem Zweck schauen wir ein wenig genauer auf die Zusammenhänge zwischen Softwareentwicklung und Produktgenese. Wir erläutern, warum es sich mit SBOM um einen zentralen Begriff im CRA-Regelkanon handelt und welche Arbeit auf ein Unternehmen zukommt, das Produkte mit digitalen Elementen produziert. Denn eines ist gewiss: Wer CRA-relevante Soft-, Hard- oder Hard- und Software-Produkte herstellt, wird in Zukunft nicht ohne eine SBOM fürs Produkt auskommen. Denn das Gesetz verpflichtet in der Regel dazu, diese zu führen.

Komplexe Materialflüsse

Jedes Unternehmen, das ein Produkt erstellt, führt Stücklisten. Diese definieren die Zusammensetzung eines Produkts aus Einzelbauteilen und machen nicht nur transparent, woraus sich ein Gegenstand herstellen lässt, sondern sie zeigen zugleich an, an welcher Stelle welche Unternehmen in der Lieferkette stehen bzw. wie diese überhaupt zu verorten sind. Produktion heute erledigt sich nicht mehr «zu Fuß» mit Listen auf Papier. Warenflüsse müssen gesteuert und kontrolliert werden, sonst schafft es kein Gerät bis in den Handel. Ein Premium-Smartphone etwa besteht aus 2700 Einzelbauteilen, die aus einer Vielzahl von Ländern stammen und aus circa 60 Rohstoffen, laut Financial Times und der Handyaktion-NRW.[1] Wenn man sich dann noch vergegenwärtigt, dass Auftragsfertigung normal ist, kann man sich das komplexe Rauschen von Material in Bewegung gut vorstellen. Wenn dann Software dabei hilft, diese Prozesse abstrahiert und standardisiert zu unterstützen, schafft es das Design in den Handel. Und das gilt nicht nur für die Hardware.

Abb. 1: Zwecke einer Software-Stückliste im Kontext des Cyber Resilient Acts.

Botnetz lähmt Bahn

Kurz zur Erinnerung: Der Cyber Resilience Act (CRA) ist eine direkt wirkende EU-Verordnung, die das Sicherheitsniveau von «Produkten mit digitalen Elementen» im europäischen Binnenmarkt signifikant erhöhen soll. Dabei spielt es keine Rolle, ob das Produkt aus Europa oder irgendeiner anderen Region des Planeten stammt. Wer in den Binnenmarkt der Europäischen Union möchte, muss konform sein mit den Richtlinien, die im CRA vorgegeben sind. Das geschieht durch Anmeldung. Je nach Kritikalität des Produkts kommen unterschiedliche Regeln zur Geltung. In diesem Text gehen wir von einem Standardprodukt aus. Das kann beispielsweise ein Texteditor mit vernetzender Update- und Upgrade-Funktion sein. Verfolgt man die Argumentation der EU, wird deutlich, dass sie damit einen Mangel im Markt beheben möchte. Beinahe jeder ist davon betroffen: Man kauft sich ein «smartes» Gerät, und nach einer Weile stellt man fest, dass es keine Sicherheitsupdates gibt. Das wäre in der besten, ehrlichen aller Welten auch kein Problem. Aber da gerade Devices im Internet of Things (IoT) anfällig sind, weil sie nicht secure by default und design sind, weil sie eben nicht gepatched oder upgedatet werden, stellen sie die Mehrzahl gekaperter Systeme in so genannten Botnetzen. Was die auslösen können, hat man beim Vorfall der Deutschen Bahn im Februar 2026 erleben dürfen. Da war’s nämlich Aus mit Fahrkartenbuchung. Ein Botnetz hat den Befehl erledigt, die Systeme der Bahn mit zahllosen unsinnigen Anfragen zu stören und lahmzulegen. Das nennt man einen Distributed Denial of Service (DDoS), also das Verhindern von Funktionalität durch verteiltes Anfragen.[2]

Cybersecurity einpreisen

Hinter derartigen Angriffen stecken keine Menschen mehr. Und selbst wenn solch ein virtuelles Überlastungsszenario eher symbolische Wirkung hat und den Ruf des größten deutschen Transportunternehmens gegebenenfalls schädigt, lässt die Attacke erkennen, was das Spielfeld der Kriminellen ist. Automatisiert werden unsichere Systeme gekapert und ohne Wissen der Eigentümer für kriminelle Handlungen missbraucht. Das können DDoS-Attacken oder Phishing-Streifzüge sein. Und wie verhindert man solch‘ eine unfreiwillige Indienstnahme zu dunklen Zwecken? Man sorgt für die Einhaltung von Sicherheitsstandards. Aber diese Anforderungen nur auf der Nutzerebene durchsetzen zu wollen, reicht nicht aus. Cybersicherheit ist immer Teamwork. Das bedeutet: Unsere Geräte müssen sauber designt sein. Cybersicherheit muss von Beginn an eingepreist sein. Dazu sollten Herstellende wissen, was von wem verbaut oder einprogrammiert ist. Dann erst kann man Probleme nachverfolgen und Schwachstellen, sofern sie bekannt werden, adressieren und beseitigen oder beseitigen lassen. Übrigens ist es nicht nur die EU, die sich um die Cybersicherheit sorgt und entsprechende Gesetze erlässt. In den USA gibt es längst Regelungen, etwa Exekutivanordnung 14028, aber auch die Regelung von so genannten Minimum Elements, die von der National Telecommunications and Information Administration herausgegeben wurden.[3] Was hinsichtlich der gegenwärtigen Administration in Washington allerdings davon bleibt, steht in den Sternen. Joe Biden hat die EO14028 im Jahr 2021 unterzeichnet. Derzeit ist davon zu lesen, dass die USA das wieder fallen lassen oder aufweichen wollen.[4]

Stücklisten juristisch

Und Europa? Der CRA ist ein überschaubares Gesetz. Das zu regelnde Objekt, Produkte mit digitalen Elementen, ist schnell erfasst. Maßnahmen und Kritikalitätsklassen sind ihrer Anzahl nach verhältnismäßig. Der Text selbst besteht aus derzeit 71 Artikeln sowie 130 Erwägungsgründen. Mit Softwarestücklisten beschäftigen sich hauptsächlich zwei Artikel (3, 13). Artikel 3 ist einer der zentralen Abschnitte des CRA. Dieser ist eine Ansammlung von 51 Definitionen der wichtigsten Begriffe, die in den Artikeln verwendet werden. Es ist also ein zentrales Element zum Verständnis des Gesetzes. Als SBOM definiert Art. 3,39: Eine „‘Software-Stückliste‘ [ist] eine formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts mit digitalen Elementen enthalten sind.“ Das klingt hübsch einfach, ist aber erst einmal recht abstrakt. Näheres regeln dann die Anhänge. Etwa, dass das Format der SBOM maschinenlesbar sein soll. Im derzeit wichtigsten deutschsprachigen Kommentar zum Gesetz heißt es: „Eine SBOM ist ein wichtiger Baustein für die Sicherheit von Software und dem Risikomanagement in der Lieferkette.“ Die Autor:innen weisen darauf hin, dass es sich um den „ersten regulatorischen Vorstoß zur Verpflichtenden Erstellung solcher Stücklisten“ handelt. In den Erwäggründen (77) zum Gesetz wird der Zweck näher erläutert: „Über eine Software-Stückliste können denjenigen, die Software herstellen, kaufen und betreiben, Informationen bereitgestellt werden, die ihnen helfen, die Lieferkette besser zu verstehen, was zahlreiche Vorteile mit sich bringt und insbesondere Herstellern und Nutzern hilft, bekannte neu aufgetretene Schwachstellen und Cybersicherheitsrisiken zu verfolgen.“[5] Damit wird der Nutzen der SBOM unmittelbar plausibel. Wie das Melden, Erstellen und Verwalten der Stücklisten im Besonderen funktionieren soll, regelt das Gesetz nicht im Detail. Es verweist deshalb spezielle Gremien, die so genannte Durchführungsverordnungen auf den Weg bringen bringen. Genauer beschreiben und legitimieren dies Art. 13,70 sowie Anhang I, Teil II, (1): „Die Hersteller von Produkten mit digitalen Elementen müssen (1) Schwachstellen und Komponenten der Produkte mit digitalen Elementen ermitteln und dokumentieren, u. a. durch Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen.“ Damit wird der Kommission nicht nur das Recht zugesprochen, Formate und Elemente der SBOM zu bestimmen, sondern auch jedem Hersteller von Produkten mit digitalen Elementen das Bereitstellen und Pflegen von SBOM auferlegt – ohne Ausnahme. Diese Durchführungsverordnungen schafft Abhilfe dabei, die allgemein und abstrakt geschriebenen Gesetze mit konkreten Handlungsnormen auszustatten. In diesem Fall ist SBOM ein Muss und muss maschinenlesbar in einem Standard gespeichert werden.

Maschinenlesbar und frei

Laut Kommentar ist das dann „eine formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen jener Komponenten […], die in den Software-Elementen enthalten sind“. Heckmann/Paschke/Bearbeiter erläutern, dass ohne diese Ermächtigung den Unternehmen „die konkrete Gestaltung“ des Datenformats, in dem eine SBOM abgespeichert werden muss, obliegen würde. Was das bedeutet, kann man sich vorstellen: ein Chaos der verschiedenen Formate, der letztlich unprüfbar macht, was eigentlich prüfbar werden sollte.[6] Aber es gibt sie schon, die Standards, und Tools, um mit ihnen zu arbeiten, sind in der Regel freie Software: SBOM machen am meisten Sinn, wenn sie in einem maschinenlesbaren Format erstellt und verwendet werden. Dazu gibt es Tools, die dazu in der Lage sind, Daten in einem standardisierten Datenformat abzulegen. Die wichtigsten sind hier CycloneDX (CDX) und Software Package Data Exchange (SPDX). Beide ermöglichen das Abspeichern der Daten in JSON beziehungsweise XML. Beide ermöglichen das Abbilden von Strukturen von Daten. Man kann in beiden zudem Strukturen ineinander verschachteln. Vereinfacht gesagt, ermöglichen Daten, die auf diese Weise erfasst und mit Auszeichnungen versehen sind, Programmen das strukturierte Verarbeiten von Information. Das klingt sehr abstrakt. Also hier ein weniger komplexer Ansatz: Stellen Sie sich vor, Sie programmieren eine Software. Diese besteht in der Regel nicht aus einer einzigen Datei, sondern aus zahlreichen, funktional zerteilten und zusammengefassten Einzeldateien. Diese befinden sich in einem Dateibaum. Und wenn man eine ausführbare Datei daraus erstellen möchte, erstellt man eine Datei mit Anweisungen, wie dies zu erledigen ist. Dann wird alles gemäß dieser Datei zu einem Programm zusammengebaut oder kompiliert. Nun kann sich ein anderes Programm diesen Dateibaum anschauen und nach Bestandteilen suchen und diese mithilfe von CDX oder SPDX dokumentieren. Dabei findet diese Software auch fremde Bestandteile, und das wiederum soll ja eine SBOM bezwecken: herausfinden, woraus eine Software besteht.

Abb. 2: Nutzen von SBOM, Software-Tools und Umfang von SBOM.

Babylonische Bibliotheken

Warum sind die Bestandteile oft ein Problem? Im Software Engineering spricht man davon, dass auf 1000 Zeilen Code ein Bug, also ein Fehler kommt. Heutige Programme sind so komplex, dass sie oft aus mehreren Millionen Zeilen Code bestehen. Selbst große Webprojekte bestehen aus Unmengen von Code. Fehler sind zwar nicht immer erheblich sicherheitsrelevant, aber wenn, dann lassen sie sich ausnutzen. Das will der CRA vermeiden helfen, indem von Anfang an Sicherheit Vorgaben beim Design und Programmieren setzt. Als Standard. Und das bedeutet natürlich auch, dass fremde Bestandteile Gegenstand übergeordneter Kontrolle ist. Um etwas kontrollieren zu können, muss ich es dokumentieren, womit wir wieder zur SBOM zurückkehren. Um nicht dauernd das Rad neu erfinden zu müssen, schreiben Programmierer Bibliotheken oder Frameworks, als spezielle Programmbibliotheken. Ihre Funktionen sind sozusagen spiegelbildlich: Der geschriebene Code bindet Bibliotheken ein und ruft deren Funktionen auf. Beim Framework ist es umgekehrt. Es liefert den Rahmen, in dem man ein Projekt verwirklichen kann. Es ist so etwas wie eine Struktur, die bestehen bleibt und in der man dann seine Anwendung entwickelt. Dann hat man eine grundsätzliche Struktur, in der man die Anwendung realisiert. Die Bibliothek oder Library stellt dagegen vorfabrizierte Einzelfunktionen zur Verfügung. Es sind Unterprogramme, auf die Programmierer in einem Projekt in der Regel keinen Einfluss nehmen. Sie werden in das Projekt gelinkt, wenn es sich um dynamische Bibliotheken handelt. Diese liegen dann im System, und auch andere Programme können auf die Funktionen zurückgreifen. Oder sie werden einkompiliert. Diese Erscheinungsformen müssen von einer Software, die eine SBOM automatisiert erstellt, erkannt werden.

Fehlerwahrscheinlichkeiten

Was ist daran interessant? Zum einen ist es wichtig zu wissen, welchen Versionsstand meine Software hat, was aber auch die benutzten Bibliotheken umfasst. Wenn eine der benutzten Libraries etwa eine dokumentierte Schwachstelle besitzt, muss auf die neueste Version gepatcht werden. Das zieht natürlich Arbeit nach sich. Ist die Bibliothek noch kompatibel? Aber genau aus dem Grund ist eine SBOM von essenzieller Bedeutung. Wenn ich wissen will, ob mein Produkt sicher ist, muss ich wissen, ob die Bestandteile sicher sind. Das wohl berühmteste Beispiel jüngeren Datums ist Log4J.[7] Diese Bibliothek stellt in Java Funktionen zur Verfügung, um Protokolldaten in einer Anwendung leistungsfähig zu sammeln. Die Schwachstelle wurde als «Log4Shell» bekannt. Sie ermöglichte die Ausführung von Schadcode. Man musste der Software dann nur eine präparierte Zeichenkette übergeben, und schon konnte Schadsoftware geladen werden, oder es konnten Daten aus einem eigentlich geschlossenen Kontext herausgezogen werden.[8] Zum Zeitpunkt nach der Entdeckung berichtete das Bundesamt für Sicherheit in der Informationstechnik, dass gut 140 Hersteller von dem Problem betroffen waren. Wenn man das weiß, kann man natürlich sehr schnell darauf reagieren und die Software verbessern und patchen. Aber mit unentdeckten, so genannten Zero Day Exploits sieht es anders aus. Da die Fehlerwahrscheinlichkeit nicht aus der Welt zu bringen ist, muss man ihr Rechnung tragen.

Log4J machte deutlich, dass eine weitverbreitete Software, die nur von einem Menschen gewartet wird, ein Problem darstellen kann. Code-Analysen und weitere flankierende Maßnahmen, so wie sie hier auf der Seite der Nutzenden beschrieben sind, müssen daher zu zwingend genutzten Begleitinstrumenten im Konzert der Softwareentwicklung werden. Denn um das eigene Projekt sauber zu halten, dokumentiert man es mithilfe von SBOM. Diese wiederum lassen sich mithilfe von Tools regelmäßig überprüfen und mit Datenbanken abgleichen, die bekannt gewordene Schwachstellen publizieren. In Europa ist das etwa die EUVD[9], die bei der europäischen Cybersicherheitsbehörde ENISA gepflegt wird. Diese Prozesse sind wechselwirkend. Das aufmerksame Registrieren von Fehlern und das Zurückspielen der Informationen in die Developer-Community erzeugen Transparenz und damit mehr Sicherheit.

Stücklistenmanagement

Jetzt wäre es noch interessant zu wissen, wie man das SBOM-Management für ein Projekt realisiert. Natürlich, und so schreibt es indirekt auch der CRA vor, gelten die Maßnahmen für die Entwicklung vorzugsweise für den gesamten Lebenszyklus eines Programms. Mit jedem neuen Release sollte automatisch eine neue SBOM mitgeneriert werden. Diese kann mit Generatoren wie Syft[10], cdxgen[11] oder SPDX SBOM Generator (wird nicht mehr gepflegt) erstellt werden. Diese erzeugen SBOMs in den oben bereits erwähnten offenen Formaten bzw. Standards. Erfasst werden müssen dabei alle direkten und indirekten Abhängigkeiten. Natürlich gilt es, die Versionen sicher, umfassend und gesichert zu erfassen und zu speichern, um die unterschiedlichen Versionsstände dokumentieren zu können.

Fazit

Die Software Bill of Materials (SBOM) sind eine hervorragende Möglichkeit, um Produkte sicherer zu machen. Daher ist es kein Wunder, dass der Cyber Resilience Act (CRA) verbindlich vorschreibt, diese in maschinenlesbarem Format zu erstellen, wenn es sich um Produkte mit digitalen Elementen handelt. SBOMs helfen dabei, alle Komponenten des Produkts im Blick zu behalten. Damit werden alle Zulieferer transparent und können kontaktiert werden. Damit ergibt sich ein Netz aus Produzierenden, die sich im besten Fall mittels SBOM, die Partner untereinander wahrnehmen, aktuell und sicher halten. Damit werden gleichermaßen Meldeketten präfiguriert. Das Melden ist allerdings anderen Artikeln vorbehalten. SBOMs müssen maschinenlesbar sein. Und sie müssen in etablierten Standardformaten abgelegt werden. Für die Erstellung von SBOMs gibt es nicht nur offene Standards, sondern auch Open-Source-Software. Daher fallen keine Lizenzgebühren an. Es klingt wie die finale Lösung des Rätsels um perfekte Produkttransparenz. Allerdings kann man sich natürlich auch überlegen, ob man nicht auch SBOMs fälschen kann, um Schrottprodukten mit unlauteren Mitteln Zugang zum europäischen Binnenmarkt zu erschleichen. Daher ist dies nur eine Anforderung aus dem CRA. Wenn auch eine sehr zentrale.

In der fünften Folge beschäftigen wir uns mit Dokumentation und Meldepflichten. Wer ist zuständig? Wie hoch ist der Aufwand? Weiter geht’s im Juni 2026.

Links zu Standards und Tools

Software Package Data Exchange (SPDX), https://spdx.dev/use/spdx-tools/

https://cyclonedx.org/OWASP CycloneDX, https://cyclonedx.org/

Software Identification (SWID); ISO/IEC 19770-2, https://www.iso.org/obp/ui/#iso:std:iso-iec:19770:-5:ed-1:v1:en

Umfangreiche Toolsammlung: https://cyclonedx.org/tool-center/

Kommerzielle Tools

Onekey: https://www.onekey.com Düsseldorf

Aikido: https://www.aikido.dev Ghent, Belgien

[1] https://ig.ft.com/us-iphone/ sowie https://handyaktion-nrw.de/themen/rohstoffe.

[2] https://www.zeit.de/mobilitaet/2026-02/deutsche-bahn-cyberangriff-stoerung-buchung-fahrplan-gxe.

[3] https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity, https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity sowie https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom.

[4] https://www.darkreading.com/application-security/trump-administration-rescinds-biden-era-sbom-guidance#:~:text=Federal%20agencies%20will%20no%20longer%20be%20required,compliance%20with%20Secure%20Software%20Development%20Framework%20(SSDF.