Kurze Antwort: ja. Der Cyber Resilience Act, Verordnung (EU) 2024/2847, verlangt von jedem Hersteller eines Produkts mit digitalen Elementen im Anwendungsbereich, eine Software-Stückliste zu erstellen. Sie ist eine der acht Anforderungen an die Schwachstellenbehandlung in Anhang I Teil II, die für jedes Produkt im Anwendungsbereich gelten, ohne „soweit anwendbar“ und ohne Größenschwelle, ab dem 11. Dezember 2027.

Die längere Antwort sind drei Sätze in der Verordnung, und jeder klärt eine Frage, die immer wieder gestellt wird.

Die Anforderung: Anhang I Teil II Nummer 1

Hersteller müssen „Schwachstellen und Komponenten, die in Produkten mit digitalen Elementen enthalten sind, ermitteln und dokumentieren, auch durch Erstellung einer Software-Stückliste in einem gebräuchlichen und maschinenlesbaren Format, die zumindest die obersten Abhängigkeiten der Produkte abdeckt“.

Vier Dinge legt dieser Satz fest.

Sie ist verpflichtend. Die SBOM ist das benannte Mittel, um Komponenten zu ermitteln und zu dokumentieren. Ohne sie gibt es keinen Weg zu Nummer 1.

Das Format ist „gebräuchlich und maschinenlesbar“. Die Verordnung nennt weder CycloneDX noch SPDX, und das muss sie nicht: Beide sind gebräuchlich und maschinenlesbar, und jedes von beiden genügt dem Text. Eine Tabellenkalkulation ist im schwachen Sinne maschinenlesbar und für den Zweck nicht gebräuchlich; verlassen Sie sich nicht darauf.

Die Tiefe ist „zumindest die obersten Abhängigkeiten“. Das ist die Untergrenze, nicht die Empfehlung. Oberste Abhängigkeiten sind die Pakete, die Ihr Produkt direkt deklariert. Transitive Abhängigkeiten sind der Ort, an dem die meisten bekannten Schwachstellen tatsächlich sitzen, also erfüllt eine SBOM nur mit obersten Abhängigkeiten den Wortlaut und lässt die Hälfte der Nummer 1, die Ermittlung von Schwachstellen, schwach. Die meisten Werkzeuge erzeugen ohnehin den vollständigen Graphen.

Sie deckt „die Produkte“ ab, im Plural, pro Produkt. Eine SBOM pro Produkt mit digitalen Elementen, pro Version, die die Konformität beeinflusst (Anhang VII Nummer 1 Buchstabe b fragt nach den Versionen). Eine einzige organisationsweite SBOM genügt nicht.

Wohin sie gehört: Anhang VII Nummer 2 Buchstabe b und Nummer 8

Die SBOM ist Teil der technischen Dokumentation. Anhang VII Nummer 2 Buchstabe b führt „die Software-Stückliste“ unter den Angaben zur Schwachstellenbehandlung auf, die die Dokumentation enthalten muss. Sie ist ein Dokument, das Sie datiert bei der Dokumentation aufbewahren, zehn Jahre oder den Unterstützungszeitraum, je nachdem, was länger ist.

Nummer 8 desselben Anhangs beantwortet die Frage, die alle als Nächstes stellen: Müssen wir sie veröffentlichen? Nein. Die SBOM wird „auf begründetes Verlangen einer Marktüberwachungsbehörde“ vorgelegt, „sofern dies erforderlich ist, damit diese Behörde die Einhaltung der in Anhang I festgelegten grundlegenden Cybersicherheitsanforderungen prüfen kann“. Sie wird einer Behörde offengelegt, auf Verlangen, mit Begründung. Nichts in der Verordnung verlangt, sie Kunden oder der Öffentlichkeit zugänglich zu machen, aber nichts verbietet es: Anhang II Nummer 9 sagt, dass die Nutzerinformationen angeben müssen, wo die SBOM abrufbar ist, wenn der Hersteller sich entscheidet, sie Nutzern zugänglich zu machen. Der Sicherheitsfragebogen eines Kunden kann sie ohnehin verlangen.

Was das nicht klärt

Formatdetails. Die Kommission kann Format und Elemente der SBOM durch Durchführungsrechtsakt festlegen (Artikel 13 Absatz 24). Bis dahin ist „gebräuchlich und maschinenlesbar“ der Maßstab, und die beiden offenen Formate erfüllen ihn.

Tiefe jenseits der obersten Ebene. Die Verordnung setzt eine Untergrenze. Ob eine Behörde, eine notifizierte Stelle oder ein Kunde nur oberste Abhängigkeiten akzeptiert, ist eine praktische Frage mit vorhersehbarer Antwort: Je tiefer die SBOM, desto weniger Fragen.

Hardwarekomponenten. Nummer 1 sagt „Schwachstellen und Komponenten“, und die SBOM ist eine Software-Stückliste. Für ein Hardwareprodukt muss die Dokumentation trotzdem Komponenten ermitteln (Anhang VII Nummer 1 Buchstabe c will den inneren Aufbau), aber die Anforderung der Maschinenlesbarkeit ist für Software formuliert.

Was zu tun ist

Erzeugen Sie die SBOM aus dem Build, nicht von Hand, in CycloneDX oder SPDX, für jedes Produkt und jede konformitätsrelevante Version, und legen Sie sie bei der technischen Dokumentation ab. Halten Sie die Erzeugung in der Release-Pipeline, damit die SBOM in der Dokumentation die des ausgelieferten Produkts ist und nicht die vom letzten Quartal. Schreiben Sie ein einseitiges SBOM-Verfahren, das sagt, welches Werkzeug, welches Format, welche Tiefe, wo sie abgelegt ist und wer ein begründetes Verlangen beantwortet; dieses Verfahren ist eines der vier Betriebsdokumente, die Teil II voraussetzt, und es ist das, wonach ein Prüfer vor der SBOM selbst fragt.

Und behalten Sie die Schwachstellenseite im Blick: Nummer 1 lautet „Schwachstellen und Komponenten ermitteln und dokumentieren“. Die SBOM ist die Komponentenhälfte. Die Schwachstellenhälfte ist das Scannen, das sie liest, und in dem Moment, in dem das Scannen eine ausgenutzte Schwachstelle zeigt, ist die 24-Stunden-Uhr des Artikels 14 das Nächste, woran zu denken ist.

Was die Verordnung dann für jede Komponente auf dieser Liste von Ihnen verlangt, Sorgfaltspflicht nach Artikel 13(5), Meldung nach oben nach Artikel 13(6) und der Test der „bekannten ausnutzbaren Schwachstellen“ beim Release, ist der Begleitartikel, aus den Leitlinien der Kommission.

Quellen

  • Verordnung (EU) 2024/2847, Anhang I Teil II Nummer 1 (zitiert); Anhang II Nummer 9; Anhang VII Nummern 1 Buchstabe b, 1 Buchstabe c, 2 Buchstabe b und 8; Artikel 13 Absatz 24 zum Durchführungsrechtsakt für das SBOM-Format; Artikel 71 Absatz 2 für die Daten. Gelesen im Amtsblatt-Text auf EUR-Lex am 11. September 2026.

Das ist keine Rechtsberatung. Die drei Sätze oben sind kurz genug, um sie in der Verordnung selbst zu lesen, und dort sollte eine Entscheidung über Ihr Produkt ruhen.