SBOM Pflicht CRA: Anforderungen und Umsetzung

Die SBOM Pflicht im CRA betrifft eine maschinenlesbare Software-Stückliste, die mindestens die obersten Abhängigkeiten des Produkts erfasst. Anhang I Teil II der Verordnung (EU) 2024/2847 verbindet dieses Inventar mit dem Umgang mit Schwachstellen. Das Erzeugen einer Datei allein belegt keine Konformität. Entscheidend ist, ob die Liste zum ausgelieferten Produkt passt und im weiteren Prozess verwendet werden kann.

Das Inventar an eine Version binden

Eine brauchbare SBOM beschreibt einen konkreten Build. Halten Sie Produktversion, Buildkennung, Komponentenidentitäten, Versionen und Beziehungen im gewählten Format fest. Wenn eine Identität unklar ist, dokumentieren Sie die verfügbare Information und die Grenze der Zuordnung. Ein falsch gewählter Paketname kann dazu führen, dass die spätere Suche nach Schwachstellen wichtige Hinweise verfehlt, obwohl die Datei formal gültig ist.

Unterscheiden Sie das gesetzliche Mindestniveau vom technischen Ziel. Die obersten Abhängigkeiten sind die genannte Mindestabdeckung. Für die tatsächliche Angriffsfläche können auch tiefer liegende Abhängigkeiten relevant sein. Prüfen Sie gebündelte Bibliotheken, Herstellerkomponenten, kopierten Quellcode und Betriebssystempakete. Bekannte Auslassungen müssen sichtbar sein. Eine hohe Zahl von Einträgen ist kein Ersatz für eine überprüfbare Produktzuordnung.

CycloneDX und SPDX im Arbeitsablauf

Der CRA schreibt nicht den bevorzugten Export eines einzelnen Scanners als einziges Format vor. Wählen Sie eine Version, die Ihr Buildsystem und der anschließende Bewertungsprozess unterstützen. Prüfen Sie zuerst die Struktur und anschließend den Inhalt gegen das tatsächlich erzeugte Image oder Paket. Bewahren Sie Werkzeugversion und Erzeugungsbefehl auf. Damit lässt sich nachvollziehen, wie das Inventar entstanden ist und wann es erneut erzeugt werden muss.

Aus dem eigenen Build erzeugen

Bei Embedded Linux sind Yocto- oder Buildroot-Artefakte und Paketmetadaten ein sinnvoller Ausgangspunkt. Je nach Produkt muss das erzeugte Dateisystem ergänzend geprüft werden. Bei Zephyr und ESP-IDF gehören Module, eingebundene Quellen und konfigurationsabhängige Bestandteile in die Betrachtung. Bei Android und installierbaren Anwendungen muss die Grenze zwischen Plattform und Anwendung geklärt werden. Ausgangspunkt ist immer das, was der Hersteller tatsächlich ausliefert.

Ein Container, der nur während der Entwicklung verwendet wird, beschreibt nicht automatisch das ausgelieferte Gerät. Umgekehrt kann notwendige Datenfernverarbeitung zur Produktgrenze gehören, obwohl sie nicht im Gerät enthalten ist. Klären Sie deshalb zuerst, ob Gerät, Begleit-App und erforderlicher Backend-Dienst gemeinsam betrachtet werden. Notieren Sie, welche Teile das Inventar abdeckt. Die Produktgrenze muss für Bestandsaufnahme, Risikobewertung und technische Dokumentation konsistent bleiben.

Erst validieren, dann überwachen

Verfolgen Sie ausgewählte Komponenten bis zu einem Nachweis im Build zurück. Prüfen Sie Versionszeichenfolgen, zurückportierte Korrekturen und architekturspezifische Pakete. Eine Herstellerkomponente kann eine ältere Versionsnummer führen und dennoch bestimmte Korrekturen enthalten. Die zugehörigen Patchnachweise helfen bei der späteren Bewertung. Daraus folgt aber keine pauschale Entwarnung für alle anderen Schwachstellen dieser Komponente.

Das validierte Inventar kann mit öffentlich bekannten Schwachstellen und Hinweisen auf aktive Ausnutzung abgeglichen werden, etwa aus CISA KEV und ENISA EUVD. Treffer sind zunächst Bewertungskandidaten. Ingenieure prüfen betroffene Funktionen, Erreichbarkeit und wirksame Schutzmaßnahmen. Das Ergebnis erhält eine technische Begründung und einen Versionsbezug. VEX kann diese Entscheidungen strukturiert festhalten. Ein unbegründetes Unterdrücken von Meldungen macht das Inventar nicht belastbarer.

Unterstützte Releases getrennt aufbewahren

Überschreiben Sie nicht die einzige SBOM, sobald eine neue Firmware erscheint. Kunden können noch eine ältere unterstützte Version verwenden. Diese kann eine Komponente enthalten, die im neuesten Build bereits entfernt wurde. Halten Sie deshalb Produkt, Release, Supportstatus und Inventar gemeinsam verfügbar. Ein neuer öffentlicher Hinweis muss den noch betroffenen Versionen zugeordnet werden können.

Legen Sie fest, wer bei einem Release die SBOM erzeugt, wer sie prüft und wie sie in die Überwachung gelangt. Eine Übergabe ohne Verantwortlichen wird im nächsten Entwicklungszyklus leicht übersehen. Prüfen Sie außerdem, wie das Ende eines Supportzeitraums die Überwachung und die Nutzerkommunikation verändert. Der Supportzeitraum ist von der Verfügbarkeit bereits bereitgestellter Sicherheitsupdates und der Aufbewahrung technischer Unterlagen zu unterscheiden.

Zugriff und Weitergabe bewusst regeln

Eine SBOM ist nicht automatisch ein öffentliches Dokument. Der Zusammenhang mit technischer Dokumentation und behördlichem Zugang muss von einer freiwilligen Weitergabe an Kunden unterschieden werden. Paketnamen, Dateipfade oder Produktbeziehungen können vertrauliche Informationen offenlegen. Vereinbaren Sie Empfänger, Umfang und Zugriffsrechte. Bewahren Sie dennoch die Nachweise auf, die für die Herstellerpflichten erforderlich sind.

Für einen ersten Review genügt ein konkretes unterstütztes Release mit dokumentierten Grenzen. Besprechen Sie mit Entwicklung und Produktverantwortlichen, welche Lücken sofort geprüft werden können und wo weitere Artefakte fehlen. Verknüpfen Sie die Ergebnisse mit dem CRA-Gesamtüberblick, der Produktklasse und dem Meldeprozess nach Artikel 14. Eine belastbare SBOM ist die Grundlage für weitere Entscheidungen, keine abschließende Konformitätsentscheidung.

Häufige Fragen

Quellen

• Verordnung (EU) 2024/2847 – deutsche Fassung auf EUR-Lex
• ENISA: Fragen zur Single Reporting Platform

Allgemeine technische Informationen, geprüft am oben genannten Datum. Produktbezogene Auslegung, aktuelle Normen und das anwendbare Verfahren sind vor einer Konformitätsentscheidung gesondert zu prüfen.