Dies ist der fünfte Beitrag unserer Reihe EU CRA Tales From the Trenches, in der wir praktische Erkenntnisse aus der Unterstützung von Herstellern, Softwareanbietern und Unternehmen mit vernetzten Produkten bei der Vorbereitung auf den Cyber Resilience Act (CRA) der Europäischen Union teilen. Ein Thema wird dabei immer deutlicher: Nachhaltige CRA-Compliance erfordert weit mehr als sichere Produkte. Sie verlangt Transparenz, Governance, Verantwortlichkeit und Lifecycle Management über das gesamte Produktportfolio hinweg.
 

Die 24-Stunden-Uhr läuft, bevor die meisten Unternehmen bereit sind

Eine der meistdiskutierten CRA-Anforderungen ist die Pflicht, aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden nach Kenntnis zu melden. Oberflächlich klingt das einfach: Schwachstelle wird bekannt, Security bewertet sie, gegebenenfalls wird gemeldet.

In der Praxis muss die Organisation vorher viel schwierigere Fragen beantworten: Betrifft die Schwachstelle eines unserer Produkte? Welche Versionen? Welche Softwarekomponenten oder Hardwaremodule? Welche Kunden? Welche Lieferanten? Ist die Schwachstelle in unserer Implementierung tatsächlich ausnutzbar? Welche Mitigations existieren bereits? Welche Nachweise stützen unsere Schlussfolgerung?

Erst danach lässt sich entscheiden, ob eine Meldung erforderlich ist und welche Maßnahmen nötig sind. Die 24-Stunden-Regel testet daher nicht primär, wie schnell Sie einen Bericht schreiben. Sie testet, wie gut Sie Ihre Produkte verstehen.

Die eigentliche Herausforderung ist Product Intelligence

Klassisches Schwachstellenmanagement konzentriert sich auf Erkennung, Schweregrad, Priorisierung und Patching. Der CRA erweitert das Problem: Eine neue Schwachstelle muss schnell auf ein gesamtes Portfolio aus Hardware, Embedded Software, mobilen Apps, Cloud-Diensten, APIs, Legacy-Produkten und übernommenen Technologien abgebildet werden.

Das erfordert mehr als Scanning – es erfordert Product Intelligence. Wenn eine neue CVE oder ein Lieferanten-Advisory erscheint, brauchen Organisationen sofort Antworten statt tagelanger manueller Recherche in Engineering-Repositories, PLM-Systemen, SBOM-Tools, Lieferantenportalen, Tabellen und E-Mails. Nicht die Meldung ist das Problem, sondern fehlende Produktintelligenz.

Warum Transparenz zur regulatorischen Anforderung geworden ist

Die meisten Hersteller haben nie eine zentrale Sicht auf alle vernetzten Produkte aufgebaut. Kritische Informationen liegen verteilt: Engineering verwaltet Designs, Entwicklung Quellcode, Security Schwachstellen, Compliance regulatorische Nachweise, Produktmanagement Releases, Einkauf Lieferanten und Support eingesetzte Versionen.

Jedes System kennt einen Teil, keines das Ganze. Wird eine Schwachstelle veröffentlicht, vergeht wertvolle Zeit allein damit, ein vollständiges Bild zusammenzusetzen – während die 24-Stunden-Uhr weiterläuft.

Warum dieses Problem weiter wächst

Software-Lieferketten werden immer größer

Moderne vernetzte Produkte enthalten oft Hunderte Softwarekomponenten aus interner Entwicklung, Open-Source-Projekten, kommerziellen Anbietern, externen Entwicklern, Halbleiterlieferanten und Drittbibliotheken. Gleichzeitig werden mehrere Hardware-Revisionen, Software-Releases, Firmware-Versionen und LTS-Zweige unterstützt. Die Zuordnung einer Schwachstelle wird damit zu einem komplexen Datenproblem.

Produktportfolios sind größer denn je

Hersteller verwalten vernetzte Hardware, Embedded Software, mobile Apps, Cloud-Plattformen, APIs und digitale Services. Jedes Produkt hat eigene Architekturen, Lieferanten, regulatorische Pflichten, Kundeneinsätze und Support-Lebenszyklen.

Produktinformationen sind fragmentiert

Selbst reife Organisationen kämpfen mit einfachen Fragen, weil Wissen über getrennte Systeme und Teams verteilt ist. Ohne gemeinsames System of Record erfordert ein vollständiges Bild erhebliche manuelle Koordination.

Schwachstellen hören nie auf

Threat Intelligence verändert sich kontinuierlich. Neue CVEs, Lieferantenhinweise, Open-Source-Schwachstellen, Exploits und Updates erscheinen täglich. Diese Informationen müssen kontinuierlich mit Produkten, Komponenten, Lieferanten und Versionen korreliert werden.

Herausforderungen aus der Praxis

Ein Lieferant meldet eine kritische Schwachstelle in einer Komponente. Die erste Frage lautet nicht, wie schnell ein Bericht erstellt werden kann, sondern: „Wo setzen wir diese Komponente ein?“ Können Sie sofort alle betroffenen Produkte, Versionen, Kundeneinsätze, SBOMs, Lieferantenbeziehungen und bestehenden Mitigations bestimmen?

Viele Organisationen können das nicht. Engineers durchsuchen Repositories, historische Dokumentation und Versionen manuell. Stunden oder Tage vergehen, bevor überhaupt klar ist, ob das Unternehmen betroffen ist. Nicht die Meldepflicht bremst – die fehlende Product Intelligence tut es.

Best Practices zur Einhaltung der 24-Stunden-Anforderung

Umfassende Produktprofile pflegen

Jedes vernetzte Produkt sollte einen aktuellen digitalen Datensatz mit Architektur, Softwareversionen, Komponenten, Lieferanten, Ownern, Dokumentation und Lifecycle-Status besitzen.

Genaue SBOMs pflegen

SBOMs sollten für jede unterstützte Produktversion existieren und über den Lebenszyklus aktuell gehalten werden.

Schwachstellen kontinuierlich korrelieren

Threat Intelligence sollte fortlaufend gegen Produktinventare, Softwarekomponenten, Lieferanteninformationen und SBOMs abgeglichen werden.

Klare Governance etablieren

Verantwortlichkeit für Schwachstellenanalyse, Engineering-Reaktion, regulatorische Meldung, Kundenkommunikation und Executive-Entscheidungen muss vor einem Incident feststehen.

Üben, bevor es ernst wird

Tabletop-Übungen decken Transparenzlücken auf. Jede Organisation sollte schnell beantworten können: Sind wir betroffen? Welche Produkte? Welche Nachweise stützen die Einschätzung? Welche Maßnahmen sind nötig?

Häufige Fallstricke

Organisationen scheitern häufig, weil sie den Bericht selbst für das schwierige Problem halten, unvollständige oder veraltete SBOMs pflegen, Produktinformationen über getrennte Systeme verteilen, Lieferantenabhängigkeiten nicht sehen oder den Meldeprozess nie üben. Fast immer fehlt Product Intelligence – nicht Incident-Response-Fähigkeit.

Maßnahmen für Hersteller und Softwareanbieter

Prioritäten sind: vollständige Produktinventare pflegen, Product Owner und Eskalationskontakte bestimmen, SBOM-Prozesse verbessern, Software-Supply-Chain-Transparenz stärken, Vulnerability Intelligence mit Produktinformationen verbinden, regulatorische Reporting-Workflows definieren und die Readiness regelmäßig in Tabletop-Szenarien testen.

Wer in Product Intelligence investiert, kann nicht nur CRA-Fristen besser erfüllen, sondern insgesamt schneller und fundierter auf Cyberrisiken reagieren.

Wie OmniTrust Certify helfen kann

OmniTrust Certify schafft ein lebendes Produktprofil, das Produktarchitektur, Komponenten, SBOMs, Schwachstellen, Lieferanten, Cyberrisiken, regulatorische Anforderungen und Nachweise verbindet. Dadurch können Teams neue Vulnerability Intelligence schnell gegen ihre Produktlandschaft korrelieren, Betroffenheit nachvollziehbar bewerten und Entscheidungen mit Evidence belegen.

Anstatt bei jeder neuen Schwachstelle Informationen aus vielen getrennten Quellen zusammenzutragen, erhalten Teams einen zentralen, kontinuierlich gepflegten Kontext für Produkt-Cyberrisiko und regulatorische Konformität.

Zusammenfassung

Die 24-Stunden-Meldepflicht des CRA ist im Kern ein Sichtbarkeitsproblem. Wer seine Produkte, Komponenten, Versionen und Abhängigkeiten nicht schnell versteht, kann auch keine verlässliche regulatorische Entscheidung treffen.

Unternehmen, die Produktinformationen, SBOMs, Vulnerability Intelligence und Governance kontinuierlich verbinden, werden wesentlich besser auf die 24-Stunden-Uhr vorbereitet sein.

Abonnieren Sie den Blog auf unserer Blog-Startseite, um über weitere Beiträge informiert zu werden.