CRA und SBOMs: Was die Verordnung verlangt und was nicht

Die folgenden rechtlichen Aussagen wurden am 21. Oktober 2026 anhand des Amtsblatttexts der Verordnung (EU) 2024/2847 und ihrer Berichtigungen geprüft. In der deutschen Fassung berichtigt ABl. L 2025/90555 Art. 13 Abs. 8; dieser Leitfaden folgt der berichtigten Fassung. Die übrigen Berichtigungen ändern die hier zitierten Bestimmungen nicht. Diese Seite dient der Information und ist keine Rechtsberatung.

Eine SBOM-Datei ist ein Anfang. Was sagt sie tatsächlich aus?

Hersteller müssen „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“ (Anhang I Teil II Nr. 1). Nach Art. 13 Abs. 8 müssen Schwachstellen beim Inverkehrbringen des Produkts und während des Unterstützungszeitraums nach Anhang I Teil II behandelt werden.

Die Verordnung definiert eine Software-Stückliste als „eine formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts mit digitalen Elementen enthalten sind“ (Art. 3 Nr. 39). Eine SBOM ist daher mehr als eine Liste von Bibliotheksnamen. Die Definition umfasst die Lieferkettenbeziehungen zwischen den Komponenten.

Eine Datei voller Namen von Komponenten kann beruhigend wirken. Aber was muss der Hersteller erstellen, und wo gehört es in die technische Dokumentation? Wer braucht möglicherweise Zugriff? Das sind getrennte Fragen mit unterschiedlichen Rechtsgrundlagen.

Die diesem Leitfaden zugrunde liegende Lesart ist: Ein nützliches Inventar zeigt für sich genommen nicht, dass jede Cybersicherheitsanforderung in Anhang I erfüllt ist. Nach Art. 31 Abs. 1 muss die technische Dokumentation alle diese Anforderungen abdecken.

Eine Formatvorgabe ohne benanntes Format

Die Verordnung legt Eigenschaften des SBOM-Formats fest: Es muss gängig und maschinenlesbar sein (Anhang I Teil II Nr. 1). Daher wäre die Aussage, es gebe „keine Formatvorgabe“, unzutreffend.

Die Verordnung benennt keinen verbindlichen SBOM-Standard, kein Schema und keine Schemaversion. Sie sagt nicht, dass ein bestimmtes benanntes Format jede CRA-Anforderung erfüllt. Das Fehlen eines benannten Formats sollte auch nicht als Erlaubnis verstanden werden, ein von Maschinen nicht verarbeitbares Dokument zu verwenden.

Art. 13 Abs. 24 erlaubt der Kommission, das Format und die Elemente der SBOM durch Durchführungsrechtsakte festzulegen und dabei europäische oder internationale Normen und bewährte Verfahren zu berücksichtigen. Die rechtliche Prüfung für diesen Leitfaden hat am 21. Oktober 2026 keinen solchen Durchführungsrechtsakt im Amtsblatt gefunden. Prüfen Sie dies erneut, bevor Sie ein Format auswählen.

Wählen Sie für den Arbeitsprozess ein Format, das Ihre Engineering-Werkzeuge erzeugen und Ihr Sicherheitsteam prüfen kann. Exportieren Sie eine Datei und testen Sie sie in den Werkzeugen, die sie erhalten werden. Halten Sie fehlende Felder und nicht unterstützte Beziehungen fest. Ein erfolgreicher Export sagt nicht, was ausgelassen wurde.

Was „zumindest die obersten Abhängigkeiten“ bedeutet

Der Gesetzestext setzt ein Minimum: „zumindest die obersten Abhängigkeiten“ (Anhang I Teil II Nr. 1). Dieser Punkt sollte nicht zu einer ausdrücklichen Pflicht umformuliert werden, jede indirekte Abhängigkeit ohne Begrenzung der Tiefe aufzulisten.

Dieses Minimum befreit auch nicht von den übrigen Pflichten zur Behandlung von Schwachstellen. Anhang I Teil II Nummern 2 bis 8 betreffen Behebung, Tests, die Offenlegung behobener Schwachstellen, die koordinierte Offenlegung von Schwachstellen, den Informationsaustausch und die Verteilung von Aktualisierungen.

Nehmen Sie als praktischen Ausgangspunkt die vom Produkt direkt einbezogenen Komponenten. Suchen Sie dann nach Lücken. Ist eingebettete Software abgedeckt? Was ist mit gebündelten Komponenten, erzeugten Artefakten und Paketen Dritter? Halten Sie fest, warum jede Komponente einbezogen oder ausgeschlossen ist. Gehen Sie über das Minimum hinaus, wenn es dem Team hilft, die tatsächlichen Produktrisiken zu untersuchen.

Verwenden Sie in Ihren internen Aufzeichnungen eine konkrete Produkt- oder Build-Kennung. Bewahren Sie Eingabe, Erstellungsdatum und bekannte Abdeckungsgrenzen bei der Datei auf. Das sind Empfehlungen für den Arbeitsablauf, keine Aussage, dass die Verordnung genau diese Menge an SBOM-Feldern verlangt.

Die SBOM in der technischen Dokumentation

Vor dem Inverkehrbringen des Produkts müssen Hersteller die in Art. 31 genannte technische Dokumentation erstellen und das gewählte Konformitätsbewertungsverfahren durchführen (Art. 13 Abs. 12). Nach Art. 31 Abs. 1 muss diese Dokumentation alle einschlägigen Daten oder Einzelheiten der Mittel enthalten, die eingesetzt werden, um die Einhaltung von Anhang I durch das Produkt und die Prozesse des Herstellers sicherzustellen. Mindestens die in Anhang VII genannten Elemente müssen enthalten sein.

Anhang VII Nummer 2 Buchstabe b nennt die SBOM ausdrücklich. Die technische Dokumentation muss die erforderlichen „Informationen und Spezifikationen bezüglich der vom Hersteller festgelegten Verfahren zur Behandlung von Schwachstellen, einschließlich der Software-Stückliste“ enthalten, ferner das Konzept für die koordinierte Offenlegung von Schwachstellen, den Nachweis der Bereitstellung einer Kontaktadresse für die Meldung der Schwachstellen und eine Beschreibung der gewählten technischen Lösungen für die sichere Verbreitung von Aktualisierungen.

Anhang VII Nummer 8 erwähnt die SBOM gesondert „gegebenenfalls“ im Zusammenhang mit einem begründeten Verlangen der Marktüberwachungsbehörde (siehe unten). Anhang VII schreibt kein Dateilayout vor. Die technische Dokumentation muss den Marktüberwachungsbehörden mindestens zehn Jahre nach dem Inverkehrbringen des Produkts oder für den Unterstützungszeitraum zur Verfügung gehalten werden, je nachdem, welcher Zeitraum länger ist (Art. 13 Abs. 13).

Machen Sie das Inventar aus der Dokumentation nachvollziehbar. Beschreiben Sie, wie es erstellt und geprüft wird und wie das Team es bei der Behandlung von Schwachstellen verwendet. Das ist eine Empfehlung für den Arbeitsablauf. Eine Datei in einem Ordner ist schwer nutzbar, wenn niemand sagen kann, welches Produkt sie beschreibt.

Keine allgemeine Pflicht zur öffentlichen Veröffentlichung

Die rechtliche Prüfung für diesen Leitfaden hat keine Bestimmung gefunden, die eine Veröffentlichung der SBOM zum Download für alle verlangt. Anhang II Nummer 9 betrifft den Fall, „dass der Hersteller dem Nutzer die Software-Stückliste zur Verfügung stellt“: Die Nutzerinformationen müssen dann angeben, „wo auf die Software-Stückliste zugegriffen werden kann“.

Verwechseln Sie dies nicht mit einer gesonderten Pflicht. Sobald eine Sicherheitsaktualisierung verfügbar ist, müssen Hersteller Informationen über behobene Schwachstellen weitergeben und öffentlich bekannt machen, vorbehaltlich einer möglichen Verzögerung in hinreichend begründeten Fällen (Anhang I Teil II Nr. 4).

Öffentliche Verfügbarkeit und der Zugang einer Behörde sind unterschiedliche Dinge:

• Auf begründete Anfrage müssen Hersteller einer Marktüberwachungsbehörde alle Informationen und Unterlagen geben, die erforderlich sind, um die Einhaltung von Anhang I nachzuweisen (Art. 13 Abs. 22).
• Anhang VII Nummer 8 nennt „gegebenenfalls auf begründetes Verlangen der Marktüberwachungsbehörde die Software-Stückliste, sofern dies erforderlich ist, damit diese Behörde die Einhaltung der grundlegenden Cybersicherheitsanforderungen in Anhang I überprüfen kann“.
• Für eine von der ADCO beschlossene unionsweite Bewertung von Abhängigkeiten können Marktüberwachungsbehörden Hersteller bestimmter Produktkategorien auffordern, die einschlägigen SBOMs vorzulegen (Art. 13 Abs. 25).

Eine private SBOM beseitigt diese Pflichten gegenüber Behörden nicht. Ebenso ersetzt ihre Veröffentlichung weder die weitergehende technische Dokumentation noch die Anforderungen an die Behandlung von Schwachstellen.

Häufige Mythen

Nutzen Sie das Inventar, wenn eine Schwachstellenmeldung eingeht

Die nützliche Frage ist, was das Inventar dem Team zu untersuchen ermöglicht. Behandeln Sie die SBOM als Empfehlung für den Arbeitsablauf als Eingabe für diese Untersuchung. Wenn eine Schwachstellenmeldung eingeht, identifizieren Sie die betreffende Komponente. Vergleichen Sie sie mit dem Inventar des ausgelieferten Produkts. Prüfen Sie, ob die betroffene Komponente vorhanden ist und ob das gemeldete Problem ihre Verwendung in diesem Produkt betrifft. Halten Sie Nachweise und Entscheidung fest.

Ein Komponentenabgleich gibt dem Team etwas, das es prüfen kann. Für eine abschließende Schlussfolgerung ist es zu früh. Halten Sie fest, was bekannt ist und was unsicher bleibt. Weisen Sie der nächsten Maßnahme einen Verantwortlichen zu und verknüpfen Sie die Bewertung mit einer Korrektur, Risikominderung und Kommunikation an Nutzer. Das ist ein vorgeschlagener Arbeitsablauf; die rechtlichen Prüfungen müssen weiterhin angewendet werden.

Eine SBOM bestimmt nicht selbst, ob eine Meldung nach Art. 14 ausgelöst wird. Art. 14 betrifft aktiv ausgenutzte Schwachstellen (Art. 14 Abs. 1, Art. 3 Nr. 42) und schwerwiegende Sicherheitsvorfälle, die sich auf die Sicherheit des Produkts auswirken (Art. 14 Abs. 3 und 5), jeweils mit eigenen Fristen. Siehe den Leitfaden zur Meldung nach Art. 14 und den Glossareintrag zur Software-Stückliste.

Quellen

• Verordnung (EU) 2024/2847 (öffnet sich in einem neuen Tab), Amtsblatttext (Amt für Veröffentlichungen): Art. 3 Nr. 39 und 42; Art. 13 Abs. 8, 12, 13, 22, 24 und 25; Art. 14 Abs. 1, 3 und 5; Art. 31 Abs. 1; Anhang I Teil II Nummern 1 bis 8; Anhang II Nummer 9; Anhang VII Nummern 2 Buchstabe b und 8.
• Berichtigung ABl. L 2025/90555 (öffnet sich in einem neuen Tab) vom 2. Juli 2025: In der deutschen Fassung berichtigt sie Art. 13 Abs. 8 („während des Unterstützungszeitraums“ statt „während der erwarteten Produktlebensdauer und des Unterstützungszeitraums“) und Art. 64 Abs. 10; dieser Leitfaden folgt der berichtigten Fassung. Die übrigen Berichtigungen der deutschen Fassung (ABl. L 2025/90828, Art. 67; ABl. L 2026/90667, u. a. Art. 13 Abs. 15) ändern die oben zitierten Bestimmungen nicht.
• Europäische Kommission: Cyber Resilience Act, Meldepflichten (öffnet sich in einem neuen Tab) (abgerufen am 21. Oktober 2026): Hintergrund für die gesonderte Prüfung der Meldepflichten.

Für die gesonderte Frage der Fristen verwenden Sie den crAcken-Rechner für Meldefristen.