Ausgangslage: Smart Devices und CRA
Mit dem Cyber Resilience Act (CRA) steigen die Anforderungen an Hersteller und Inverkehrbringer von Smart Devices erheblich. Die Sicherheit eines Produkts mit digitalen Elementen ist nicht mehr nur punktuell zum Zeitpunkt des Inverkehrbringens zu betrachten. Schwachstellen müssen vielmehr über den Unterstützungszeitraum erkannt, bewertet, dokumentiert und - soweit die gesetzlichen Voraussetzungen erfüllt sind - innerhalb kurzer Fristen an die zuständigen Stellen gemeldet werden. Gerade bei Smart Devices ist dies anspruchsvoll, weil Firmware und begleitende Software häufig aus zahlreichen eigenen, zugekauften und Open-Source-Komponenten bestehen.
Wir haben diese regulatorische Entwicklung in unserer Dependency-Analyse bereits methodisch vorweggenommen. Ausgangspunkt unserer Lösung ist die Software Bill of Materials (SBOM) eines konkreten Smart Devices. Die SBOM wird nicht lediglich als regulatorisches Dokument verstanden, sondern als technische Ausgangsbasis eines kontinuierlichen Vulnerability-Managements. Sie verknüpft einen konkreten Produkt- und Firmwarestand mit den darin enthaltenen Komponenten und Versionen und schafft damit die Voraussetzung, neue Schwachstelleninformationen gegen einen bekannten Softwarebestand zu prüfen.
SBOM als Ausgangsbasis - nicht als Endprodukt
Der CRA greift die Bedeutung der SBOM ausdrücklich auf. Anhang I Teil II Nr. 1 nennt eine maschinenlesbare SBOM und setzt mit den obersten Abhängigkeiten ein regulatorisches Mindestniveau. Dieses Mindestniveau ist jedoch nicht mit dem vollständigen technischen Informationsbedarf für ein wirksames Schwachstellenmanagement gleichzusetzen. Insbesondere bei komplexen Smart Devices können relevante Schwachstellen in transitiv eingebundenen Komponenten liegen. Eine rein formale SBOM-Prüfung kann daher zu kurz greifen.
Unsere Lösung leitet aus den verfügbaren SBOM-Informationen einen Dependency Tree ab und betrachtet soweit möglich direkte und transitive Abhängigkeiten. Komponentenbezeichnungen, Versionen und Identifikatoren werden normalisiert, damit externe Informationen möglichst eindeutig zugeordnet werden können. Die SBOM bildet zugleich die Basis für weitere Prüfungen, beispielsweise auf Lizenzprobleme, End-of-Life (EOL) und erforderliche Updates.
Kernidee: Die SBOM beantwortet die Frage, welche Software in welchem Produktstand enthalten ist. Erst die nachgelagerte Dependency- und Vulnerability-Analyse beantwortet, welche Bedeutung dieser Bestand zum aktuellen Prüfzeitpunkt hat.
Vulnerability-Ecosystem und Datenquellen
Eine SBOM allein erlaubt noch keine belastbare Aussage darüber, ob ein Smart Device aktuell verwundbar oder sogar regulatorisch relevant betroffen ist. Dafür muss der Softwarebestand mit dem verfügbaren Schwachstellenwissen verknüpft werden. Unsere Lösung führt deshalb mehrere Informationsquellen zusammen, darunter EUVD, OSV, NVD/CVE-basierte Informationen, den CISA Known Exploited Vulnerabilities Catalog (KEV) sowie EPSS.
Die Quellen erfüllen unterschiedliche Funktionen. CVE-basierte Informationen beschreiben bekannte Schwachstellen und deren Zuordnung; paketorientierte Quellen können betroffene Versionen präzisieren. KEV liefert Hinweise auf nachweislich aktiv ausgenutzte Schwachstellen, während EPSS ein zusätzliches Priorisierungssignal für die Wahrscheinlichkeit einer Ausnutzung bereitstellt. Keine dieser Quellen beantwortet für sich allein die entscheidende Frage, ob das konkret untersuchte Smart Device in seinem aktuellen Produktstand betroffen ist.
Genau hier ist der von Mandl und Mandl beschriebene Blick auf das verteilte Open-Source-Vulnerability-Ecosystem wichtig. Schwachstelleninformationen entstehen nicht in einer einzigen vollständigen und jederzeit konsistenten Datenbasis. Sie werden über unterschiedliche Quellen veröffentlicht, angereichert, priorisiert und teilweise unterschiedlich interpretiert. Komponentenidentitäten, Versionsmodelle, Aktualisierungszeitpunkte und Werkzeuglogiken können daher zu abweichenden Ergebnissen führen. Unsere Lösung berücksichtigt diese Unsicherheit, indem sie Quellen nicht isoliert, sondern im Produktkontext auswertet und den jeweils zugrunde liegenden Informationsstand nachvollziehbar macht.
Vom Dependency Tree zur Produktbetroffenheit
Die Analyse führt drei Ebenen zusammen: erstens den konkreten Produkt- und Firmwarestand, zweitens den darin enthaltenen Dependency Tree mit direkten und soweit ermittelbar transitiven Abhängigkeiten und drittens das externe Schwachstellen- und Exploitwissen. Darauf aufbauend werden mehrere Prüffragen beantwortet: Ist eine verwundbare Version enthalten? Sind die ermittelten Lizenzen unproblematisch? Hat eine Komponente ihr EOL erreicht? Ist ein Update erforderlich? Und ist eine identifizierte Vulnerability zum aktuellen Prüfzeitpunkt als akut einzustufen?
Damit geht unsere Analyse bewusst über eine reine CVE-Liste hinaus. Eine hohe technische Schwere oder die bloße Existenz einer CVE reicht nicht aus, um die tatsächliche Produktbetroffenheit zu beurteilen. Entscheidend ist die Verbindung mit dem konkreten Produktstand und der tatsächlich eingesetzten Version. Die Bewertung wird damit vom abstrakten Vulnerability-Fund zur produktspezifischen Entscheidung.
Analyseergebnis zum aktuellen Prüfzeitpunkt
Das zentrale Ergebnis unserer Verarbeitung ist ein strukturiertes Analyseergebnis. Es enthält die zum Prüfzeitpunkt verfügbaren und für die Bewertung relevanten Informationen: Produkt- und Firmwarestand, zugrunde liegende SBOM, direkte und transitive Abhängigkeiten, normalisierte Komponenteninformationen, Lizenzinformationen, bekannte Schwachstellen, EOL-Status, Updatebedarf, Priorisierungssignale sowie die Bewertung der aktuellen Relevanz.
Die zeitpunktbezogene Speicherung ist wesentlich, weil das Vulnerability-Ecosystem dynamisch ist. Betroffene Versionsbereiche können nachträglich präzisiert, Bewertungen verändert, Exploitinformationen ergänzt oder Datensätze korrigiert werden. Eine belastbare Nachweisführung muss daher erkennen lassen, auf welcher Informationsbasis eine Entscheidung zu einem bestimmten Zeitpunkt getroffen wurde. Versionierung, Evidenz und Audit-Trail sind deshalb integraler Bestandteil unserer Lösung.
Anschluss an die CRA-Melde- und Nachweispflichten
Mit den CRA-Meldepflichten gewinnt diese zeitnahe Produktzuordnung zusätzliche Bedeutung. Bei einer tatsächlich in einem Produkt enthaltenen und aktiv ausgenutzten Schwachstelle müssen Hersteller innerhalb der im CRA vorgesehenen Fristen reagieren und die erforderlichen Informationen für die zuständigen Stellen bereitstellen. Die kurzen Fristen lassen sich praktisch nur einhalten, wenn Produktstände, Komponenten und Abhängigkeiten nicht erst im Ereignisfall rekonstruiert werden müssen.
Unsere Lösung trennt deshalb die technische Analyse von der regulatorischen Ausgabe. Zunächst wird ein nachvollziehbares und versioniertes Analyseergebnis erzeugt. Daraus kann ein Prüfbericht mit Evidenz, Versionierung und Audit-Trail abgeleitet werden. Liegen die gesetzlichen Voraussetzungen für eine CRA-Meldung vor, können die bereits strukturiert vorhandenen Informationen zugleich als Datenbasis für die Meldung an ENISA beziehungsweise das zuständige CSIRT dienen.
Damit haben wir zentrale Elemente der aktuellen CRA-Umsetzung bereits in unserer technischen Lösung berücksichtigt: die eindeutige Zuordnung eines Produkts zu seinem Softwarebestand, die Betrachtung von Abhängigkeiten, die kontinuierliche Anreicherung durch externe Vulnerability-Informationen, die Bewertung der tatsächlichen Produktbetroffenheit und die nachvollziehbare Dokumentation des Prüfzeitpunkts. Die regulatorische Meldung wird so nicht zu einem isolierten manuellen Vorgang, sondern kann auf einem bereits vorhandenen technischen Evidenzbestand aufsetzen.
Bedeutung für Smart Devices
Für Smart Devices ist dieser Ansatz besonders relevant. OEM-Firmware, Open-Source-Komponenten, zugekaufte Bibliotheken, unterschiedliche Hardware-Revisionen und lange Produktlebenszyklen führen zu einer komplexen Software-Lieferkette. Gleichzeitig kann ein Hersteller für die Schwachstellenbehandlung nicht allein darauf vertrauen, dass ein Lieferant rechtzeitig und vollständig informiert. Die strukturierte SBOM und die darauf aufbauende Analyse schaffen deshalb Transparenz über den tatsächlichen Softwarebestand und dessen aktuelle Risikolage.
Die SBOM ist dabei die notwendige Ausgangsbasis, aber nicht das Endprodukt. Ihre eigentliche Bedeutung entfaltet sie erst durch die Verbindung mit Dependency-Analyse, Vulnerability-Ecosystem und Produktkontext. Genau diese Verbindung erlaubt es, eine abstrakte Schwachstelleninformation in eine konkrete Aussage für ein bestimmtes Smart Device zu überführen.
Fazit
Wir verstehen die SBOM als Ausgangspunkt eines kontinuierlichen, nachvollziehbaren und regulatorisch nutzbaren Prozesses. Aus der SBOM eines Smart Devices wird ein Dependency Tree abgeleitet; dieser wird mit mehreren Quellen des Vulnerability-Ecosystems angereichert und auf Produktbetroffenheit geprüft. Zusätzlich fließen Lizenzstatus, EOL und Updatebedarf ein. Das Ergebnis ist ein versionierter Informationsstand zum aktuellen Prüfzeitpunkt, aus dem sowohl ein Prüfbericht als auch - bei entsprechender Relevanz - eine CRA-Meldung abgeleitet werden können.
Damit operationalisiert unsere Lösung wesentliche CRA-Anforderungen und trägt zugleich der von Mandl und Mandl beschriebenen verteilten und dynamischen Struktur des Vulnerability-Ecosystems Rechnung. Die SBOM liefert die Informationsbasis; die Dependency- und Vulnerability-Analyse macht daraus einen belastbaren technischen und regulatorischen Nachweis.
Literaturhinweis
Mandl, P.; Mandl, P. (2026): The Distributed Open-Source Vulnerability Ecosystem. Preprint, arXiv:2607.14900 [cs.CR], Juli 2026. DOI 10.48550/arXiv.2607.14900.