Software-Stückliste im Cyber Resilience Act: Aufbau und Pflichtinhalte
Wer ein Produkt mit digitalen Elementen in der EU in Verkehr bringt, muss künftig genau wissen, welche Software- und Hardwarekomponenten darin stecken – und das nicht nur für die eigene Entwicklungsabteilung. Der Cyber Resilience Act verlangt dafür eine Software-Stückliste, im Englischen Software Bill of Materials (SBOM). Was darin stehen muss, in welchem Format und ab wann, ist an mehreren Stellen der Verordnung geregelt und wird derzeit durch technische Richtlinien konkretisiert. Wer sein Produkt grundsätzlich im Anwendungsbereich des CRA verorten möchte, findet die Grundlagen dazu im Beitrag CRA einfach erklärt: Wer ist betroffen und ab wann?
Was eine Software-Stückliste nach dem CRA ist
Der CRA definiert die Software-Stückliste in Artikel 3 Nummer 39 als formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts mit digitalen Elementen enthalten sind. Vereinfacht gesagt: eine maschinenlesbare Liste aller verwendeten Softwarebausteine, kommerziell wie quelloffen, samt ihrer Abhängigkeiten untereinander.
Der Zweck ist in Erwägungsgrund 77 formuliert: Die Stückliste soll Herstellern und Nutzern helfen, bekannt werdende Schwachstellen in Drittkomponenten schneller zu verfolgen und einzuordnen. Wird etwa eine kritische Lücke in einer weit verbreiteten Bibliothek bekannt, lässt sich anhand einer aktuellen SBOM zügig feststellen, welche eigenen Produkte betroffen sind.
Die gängigen Datenformate SPDX und CycloneDX unterstützen auch die Dokumentation von Hardware-Abhängigkeiten, wie CPUs, FPGAs, Mikrocontroller, Sicherheitschips, etc. Dies ermöglicht vor allem bei physischen Produkten mit digitalen Elementen die eindeutige Bestimmung der Meldepflicht bei Sicherheitslücken, auch wenn diese bereits in der Hardware der Produkte existieren.
Was Anhang I Teil II Nummer 1 konkret verlangt
Die eigentliche Pflicht steht in Anhang I Teil II Nummer 1 der Verordnung: Hersteller müssen Schwachstellen und Komponenten ihrer Produkte identifizieren und dokumentieren, unter anderem durch Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten des Produkts hervorgehen. Verlangt wird also mindestens die direkte, nicht zwingend die vollständige transitive Abhängigkeitstiefe.
Ein konkretes Dateiformat schreibt der CRA nicht vor. Nach Erwägungsgrund 24 kann die Kommission das Format und die Elemente der Software-Stückliste per Durchführungsrechtsakt noch festlegen; ein solcher Rechtsakt liegt bislang nicht vor. In der Praxis haben sich zwei Formate etabliert, die beide maschinenlesbar sind und regelmäßig als CRA-tauglich genannt werden: SPDX und CycloneDX.
Zwei Fristen, die nicht verwechselt werden sollten
Die Meldepflichten nach Artikel 14 gelten bereits ab dem 11. September 2026. Die grundlegenden Cybersicherheitsanforderungen aus Anhang I Teil II – und damit die Pflicht zur Software-Stückliste – werden erst mit der vollen Anwendbarkeit der Verordnung ab dem 11. Dezember 2027 verbindlich. Wer die SBOM-Pflicht fälschlich schon zum September-Termin einordnet, unterschätzt zwar nicht das Thema, verortet aber den Handlungsdruck am falschen Datum.
Wer die Software-Stückliste sehen darf
Der CRA verpflichtet Hersteller nicht dazu, die Software-Stückliste zu veröffentlichen (Erwägungsgrund 77). Sie ist Teil der technischen Dokumentation nach Anhang VII, muss der Marktüberwachungsbehörde aber nur auf begründetes Verlangen vorgelegt werden, soweit dies zur Prüfung der Konformität erforderlich ist (Anhang VII Nummer 8). Stellt der Hersteller die SBOM freiwillig dem Nutzer zur Verfügung, muss er lediglich angeben, wo sie zugänglich ist.
Eine zweite, unionsweite Verwendung ist in den Erwägungsgründen 22 und 25 angelegt: Die Gruppe für administrative Zusammenarbeit (ADCO) kann Marktüberwachungsbehörden auffordern, bei bestimmten Produktkategorien Software-Stücklisten zur Bewertung der Abhängigkeit von Softwarekomponenten – insbesondere quelloffenen – einzuholen. An die ADCO selbst gehen dabei nur anonymisierte und aggregierte Informationen, um die Vertraulichkeit der einzelnen Stücklisten zu wahren.
Was das für Ihr Unternehmen bedeutet
Auch wenn das endgültige Format noch aussteht, lohnt es sich, mit dem Aufbau einer SBOM-Erstellung schon jetzt zu beginnen: Sie lässt sich in aller Regel automatisiert aus der Build-Pipeline erzeugen, wächst aber mit der Zahl der Produktvarianten und Versionen schnell zu einem eigenen Pflegeaufwand. Als praktische Orientierung, bis ein Durchführungsrechtsakt vorliegt, dient die Technische Richtlinie TR-03183-2 des BSI mit konkreten Formatempfehlungen und Pflichtfeldern zu SPDX und CycloneDX. Sie ist rechtlich nicht bindend, begründet keine Konformitätsvermutung und wird durch künftige harmonisierte Normen abgelöst – für die Umsetzung im eigenen Haus ist sie derzeit aber die konkreteste verfügbare Vorlage.
Ob und wie sich die eigene Produktpalette in ein SBOM-taugliches Format überführen lässt, hängt stark von den bestehenden Entwicklungsprozessen ab. Normativo berät zu SBOM und CE-Kennzeichnung für CRA-relevante Produkte und kann auf Wunsch auch die technische Dokumentation komplett übernehmen. In einem unverbindlichen Erstgespräch klären wir gemeinsam, was für Ihre Produkte konkret benötigt wird.
CRA einfach erklärt: Wer ist betroffen und ab wann?
Cyber Resilience Act (CRA): Welche Produkte betroffen sind, ab wann Meldepflicht und Konformität gelten und welche Risiken bei Nichtbeachtung drohen.
Weiterlesen →CRA Meldefristen: 24h/72h-Fristen richtig umsetzen
CRA Meldefristen im Überblick: 24-Stunden-Frühwarnung, 72-Stunden-Meldung und Abschlussbericht an ENISA und CSIRT – Fristen, Auslöser und Praxisfolgen.
Weiterlesen →Technische Dokumentation nach CRA: Diese Inhalte sind Pflicht
Was die technische Dokumentation nach dem Cyber Resilience Act enthalten muss – Pflichtinhalte, Aufbewahrungsfristen und Bußgeldrisiken im Überblick.
Weiterlesen →