Eine SBOM listet auf, welche Komponenten in einer Software stecken. Der Cyber Resilience Act verlangt sie ab Dezember 2027, doch Hersteller brauchen diesen \u00dcberblick schon heute.<\/p>\n
Wie schnell er fehlen kann, zeigte sich im Dezember 2021. Als die Log4j-Sicherheitsl\u00fccke<\/a> bekannt wurde, mussten zahlreiche Hersteller erst m\u00fchsam herausfinden, wo die Protokollbibliothek \u00fcberall verbaut war. Mit einer aktuellen Software-St\u00fcckliste, der Software Bill of Materials, l\u00e4sst sich eine solche Frage durch eine einfache Suche kl\u00e4ren.<\/p>\n Inzwischen dr\u00e4ngt bei dieser Frage die Zeit, denn f\u00fcr aktiv ausgenutzte Schwachstellen gilt seit September 2026 eine Meldefrist von 24 Stunden. Wer nicht wei\u00df, was in seinen Produkten verbaut ist, kann sie kaum einhalten. Drei Punkte verdienen deshalb einen genaueren Blick: was in eine solche St\u00fcckliste geh\u00f6rt, was die Verordnung tats\u00e4chlich vorschreibt und wie der Nachweis der Bestandteile mit der Signatur einer Software zusammenh\u00e4ngt.<\/p>\n SBOM steht f\u00fcr Software Bill of Materials, auf Deutsch Software-St\u00fcckliste. Eine SBOM ist ein maschinenlesbares Verzeichnis aller Komponenten, aus denen eine Software besteht. Sie nennt zu jedem Bestandteil mindestens Name, Version und Herkunft und zeigt, welche Komponenten voneinander abh\u00e4ngen. So wird nachvollziehbar, was in einem Produkt tats\u00e4chlich enthalten ist.<\/p>\n Das Prinzip kennen Sie von Lebensmitteln: Die Zutatenliste auf der Verpackung verr\u00e4t nicht, wie ein Produkt hergestellt wird, aber sie sagt, was darin steckt. Bei Software ist diese Auskunft wichtiger, als es zun\u00e4chst scheint. Kaum eine Anwendung besteht nur aus eigenem Code. Bibliotheken, Frameworks und Open-Source-Bausteine machen oft den gr\u00f6\u00dferen Teil aus, und jede dieser Komponenten bringt wiederum eigene Abh\u00e4ngigkeiten mit.<\/p>\n Der Begriff stammt aus der Fertigung, wo die St\u00fcckliste alle Teile auff\u00fchrt, aus denen ein Produkt zusammengesetzt wird. Die SBOM \u00fcbertr\u00e4gt dieses Prinzip auf Software. Der Cyber Resilience Act definiert sie als \u201eeine formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts mit digitalen Elementen enthalten sind\u201c (Art. 3 Nr. 39).<\/p>\n Welche Angaben eine St\u00fcckliste enth\u00e4lt, h\u00e4ngt vom Format und vom Anspruch ab. Die Technische Richtlinie des BSI nennt f\u00fcr jede Komponente unter anderem diese Angaben:<\/p>\n Hinzu kommen Angaben zur St\u00fcckliste selbst, n\u00e4mlich wer sie erstellt hat und wann.<\/p>\n Entscheidend ist die Tiefe. Eine St\u00fcckliste kann nur die direkten Abh\u00e4ngigkeiten eines Produkts erfassen, die sogenannten Top-Level-Abh\u00e4ngigkeiten, oder auch deren Abh\u00e4ngigkeiten bis in die unterste Ebene. Ein Beispiel: Eine Webanwendung bindet ein Framework ein, das Framework nutzt eine Bibliothek zur Bildverarbeitung, und diese greift wiederum auf eine Komprimierungsbibliothek zur\u00fcck. In einer St\u00fcckliste, die nur die oberste Ebene erfasst, taucht allein das Framework auf. Log4j war in vielen F\u00e4llen gerade nicht direkt eingebunden, sondern steckte in einer Bibliothek, die ihrerseits von einer anderen Bibliothek genutzt wurde. Je vollst\u00e4ndiger die St\u00fcckliste ist, desto verl\u00e4sslicher ist die Auskunft.<\/p>\n Schwachstellen geh\u00f6ren dagegen nicht hinein. Eine SBOM beschreibt eine bestimmte Version einer Software und \u00e4ndert sich nicht mehr, sobald diese Version ausgeliefert ist. Die Schwachstellenlage \u00e4ndert sich dagegen laufend. Informationen dazu stehen deshalb in eigenen Dokumenten, etwa in Sicherheitshinweisen im Format CSAF oder in VEX-Dokumenten, die angeben, ob ein Produkt von einer bekannten Schwachstelle tats\u00e4chlich betroffen ist.<\/p>\n Damit Werkzeuge eine St\u00fcckliste automatisch erzeugen, austauschen und auswerten k\u00f6nnen, braucht sie ein einheitliches Format. Zwei Standards haben sich durchgesetzt:<\/p>\n Das BSI l\u00e4sst in seiner Technischen Richtlinie beide zu: Neu erzeugte St\u00fccklisten sollen CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1 entsprechen. In einer Erhebung der EU-Cybersicherheitsagentur ENISA gaben 44 Prozent der befragten Organisationen an, CycloneDX zu nutzen, 29 Prozent nannten SPDX.<\/p>\n Welches SBOM-Format das richtige ist, entscheidet sich in der Praxis an den eingesetzten Werkzeugen und an den Anforderungen der Kunden. Wichtiger als die Wahl ist, dass die St\u00fcckliste automatisch entsteht und zu jeder ausgelieferten Version passt.<\/p>\n Die SBOM wird am 11. Dezember 2027 zur Pflicht. An diesem Tag gilt der Cyber Resilience Act<\/a> (CRA) vollst\u00e4ndig, und Hersteller m\u00fcssen f\u00fcr jedes Produkt mit digitalen Elementen, das sie von da an in der EU in Verkehr bringen, eine Software-St\u00fcckliste f\u00fchren.<\/p>\n Die Vorgabe steht in Anhang I der Verordnung (EU) 2024\/2847<\/a>. Hersteller m\u00fcssen die Komponenten ihrer Produkte ermitteln und dokumentieren, unter anderem durch eine Software-St\u00fcckliste in einem g\u00e4ngigen, maschinenlesbaren Format, die mindestens die Abh\u00e4ngigkeiten der obersten Ebene erfasst. Vier Punkte zur SBOM im CRA werden h\u00e4ufig missverstanden:<\/p>\n Die technische Dokumentation, zu der die St\u00fcckliste geh\u00f6rt, m\u00fcssen Hersteller mindestens zehn Jahre lang aufbewahren oder f\u00fcr die Dauer des Unterst\u00fctzungszeitraums, wenn dieser l\u00e4nger ist.<\/p>\n Die SBOM-Richtlinie des BSI ist die Technische Richtlinie TR-03183 \u201eCyber-Resilienz-Anforderungen\u201c<\/a>. Ihr zweiter Teil beschreibt, wie eine Software-St\u00fcckliste aufgebaut sein soll: welche Datenfelder sie enth\u00e4lt, in welchen Formaten sie vorliegt und wie tief die Abh\u00e4ngigkeiten aufgel\u00f6st werden. Aktuell ist die Version 2.1.0 vom August 2025.<\/p>\n Nach Angaben des BSI ist die Richtlinie eine Hilfestellung ohne verbindlichen Charakter, die Hersteller auf die Anforderungen des Cyber Resilience Act vorbereiten soll. An mehreren Stellen geht sie \u00fcber die Mindestanforderung der Verordnung hinaus. Sie verlangt unter anderem eine Pr\u00fcfsumme f\u00fcr jede ausgelieferte Komponente, Lizenzangaben und eine neue St\u00fcckliste f\u00fcr jede neue Softwareversion. Solange die EU-Kommission keine eigenen Vorgaben macht, ist sie f\u00fcr Hersteller in Deutschland die genaueste Orientierung.<\/p>\n Das die Pflicht erst Ende 2027 greift, bedeutet nicht, dass bis dahin Zeit bleibt. Seit dem 11. September 2026 gilt bereits die Meldepflicht des Cyber Resilience Act<\/a>: Wird eine Schwachstelle in einem Produkt aktiv ausgenutzt, muss der Hersteller innerhalb von 24 Stunden eine Fr\u00fchwarnung abgeben. Diese Pflicht erfasst auch Produkte, die l\u00e4ngst auf dem Markt sind.<\/p>\n Die Frist l\u00e4sst sich nur halten, wenn ein Hersteller sofort beurteilen kann, ob eine neu bekannt gewordene Schwachstelle seine Produkte betrifft. Ohne ein Verzeichnis der verbauten Komponenten beginnt in diesem Moment die Suche. Mit einer St\u00fcckliste gen\u00fcgt eine Abfrage. Beide Vorgaben geh\u00f6ren deshalb zusammen: Die Meldepflicht verlangt eine schnelle Antwort, und die St\u00fcckliste macht sie m\u00f6glich.<\/p>\n Auch unabh\u00e4ngig von Fristen ist der \u00dcberblick n\u00f6tig, denn Angriffe auf die Software-Lieferkette<\/a> setzen genau dort an, wo Hersteller ihre zugekauften und quelloffenen Bausteine nicht im Blick haben. Wer Software an Unternehmen liefert, die selbst unter den CRA fallen, muss au\u00dferdem damit rechnen, von seinen Kunden nach einer St\u00fcckliste gefragt zu werden. Sie ben\u00f6tigen diese Angaben f\u00fcr ihre eigene Dokumentation.<\/p>\n Viele Unternehmen haben bereits begonnen. In der ENISA-Erhebung \u201eSBOM Adoption State of Play \u2013 2026\u201c<\/a> mit 334 Antworten gaben 78 Prozent der Organisationen an, mit der Einf\u00fchrung begonnen zu haben. 79 Prozent erwarten, die n\u00f6tige Reife zu erreichen, bis der CRA vollst\u00e4ndig gilt. Als h\u00e4ufigste technische H\u00fcrde nannten die Befragten die Vollst\u00e4ndigkeit der St\u00fccklisten.<\/p>\n Eine St\u00fcckliste sagt, was in einer Software steckt. Sie sagt nicht, ob die Datei, die beim Kunden ankommt, tats\u00e4chlich diejenige ist, die der Hersteller gebaut hat. Diese zweite Frage beantwortet die digitale Signatur. Code-Signing-Zertifikate<\/a> binden eine Software an die gepr\u00fcfte Identit\u00e4t ihres Herstellers, und jede nachtr\u00e4gliche Ver\u00e4nderung macht die Signatur ung\u00fcltig.<\/p>\n Beide Nachweise greifen ineinander:<\/p>\n Der Cyber Resilience Act schreibt weder Code Signing noch eine signierte St\u00fcckliste ausdr\u00fccklich vor. Er verlangt aber, dass Programme und Daten vor unbefugter Manipulation gesch\u00fctzt sind und dass Sicherheitsupdates \u00fcber sichere Mechanismen verteilt werden (Anhang I). Die Signatur ist das etablierte Mittel, um diese Integrit\u00e4t nachpr\u00fcfbar zu machen.<\/p>\n In der Praxis geh\u00f6ren beide Schritte in denselben automatisierten Ablauf: Die Software wird gebaut, die SBOM wird erzeugt, das Ergebnis wird signiert, und beides wird zur jeweiligen Version abgelegt. Wer Code Signing in der Softwareentwicklung<\/a> bereits fest verankert hat, muss daf\u00fcr keinen neuen Prozess erfinden, sondern den bestehenden um einen Schritt erweitern. Je h\u00e4ufiger neue Versionen erscheinen, desto mehr lohnt es sich, auch das Code Signing zu automatisieren<\/a> und die Schl\u00fcssel dabei gesch\u00fctzt zu verwahren.<\/p>\n Bis Dezember 2027 bleibt etwas mehr als ein Jahr. Das Erzeugen einer St\u00fcckliste \u00fcbernehmen Werkzeuge, der eigentliche Aufwand liegt in der Vollst\u00e4ndigkeit und in den Abl\u00e4ufen dahinter. Am Anfang steht eine Bestandsaufnahme: Welche Produkte und Versionen sind im Markt, und welche werden nach dem Stichtag neu in Verkehr gebracht?<\/p>\n Darauf folgt die Entscheidung f\u00fcr ein Format und die Einbindung in den Build-Prozess, damit zu jeder Version automatisch eine passende St\u00fcckliste entsteht. Die Richtlinie des BSI bietet daf\u00fcr eine konkrete Vorlage. Ebenso wichtig ist die Frage, wer neue Schwachstellenmeldungen mit den St\u00fccklisten abgleicht, wer \u00fcber eine Meldung entscheidet und wer daf\u00fcr sorgt, dass Sicherheitsl\u00fccken geschlossen<\/a> werden.<\/p>\n F\u00fcr zugekaufte Komponenten lohnt es sich, die St\u00fccklisten fr\u00fchzeitig bei den Zulieferern anzufordern, denn die Sicherheit der Lieferkette<\/a> l\u00e4sst sich nur beurteilen, wenn auch deren Bestandteile bekannt sind. Schlie\u00dflich sollte gekl\u00e4rt sein, wie Software und St\u00fcckliste signiert werden und wo beides zusammen mit der technischen Dokumentation aufbewahrt wird.<\/p>\n Ab Dezember 2027 geh\u00f6rt die Software-St\u00fcckliste zu den Pflichten jedes Herstellers, der Produkte mit digitalen Elementen in der EU anbietet. Wer bis dahin wei\u00df, was in seiner Software steckt, und belegen kann, dass sie unver\u00e4ndert beim Kunden ankommt, hat beide Nachweise beisammen: den Inhalt \u00fcber die SBOM und die Herkunft \u00fcber die Signatur. Bei der Auswahl des passenden Code-Signing-Zertifikats<\/a> unterst\u00fctzt Sie unser Team gern.<\/p>\nWas ist eine SBOM?<\/h2>\n
Was in einer Software-St\u00fcckliste steht<\/h2>\n
\n
SBOM-Formate: CycloneDX und SPDX<\/h2>\n
\n
Ab wann die Software-St\u00fcckliste zur Pflicht wird<\/h2>\n
\n
Was die SBOM-Richtlinie des BSI regelt<\/h3>\n
Warum Hersteller die St\u00fcckliste schon vor 2027 brauchen<\/h2>\n
SBOM und Code Signing: Inhalt nachweisen, Herkunft belegen<\/h2>\n
\n
Was Softwarehersteller jetzt vorbereiten<\/h2>\n