„Unternehmen brauchen durchgängiges Monitoring und klare Meldeprozesse, um Sicherheitsrisiken schnell in den Griff zu bekommen“, so Jochen Koehler, Vice President of EMEA Sales bei Cycode.

Am 11. Dezember 2024 trat der Cyber Resilience Act (CRA) der EU in Kraft. Exakt drei Jahre später müssen alle Unternehmen, die Produkte mit digitalen Elementen anbieten, vollständige Compliance gemäß der neuen Verordnung beweisen. Cycode, der Pionier im Bereich Agentic Development Lifecycle Security, erklärt, warum der 11. September 2026 jedoch das wichtigere Datum ist.

Bis zum letzten Augenblick zu warten, um eine CRA-Strategie umzusetzen, könnte fatal sein. Denn bereits am 11. September 2026 treten die Meldepflichten für Schwachstellen und Sicherheitsvorfälle im Rahmen des CRA in Kraft: Ab diesem Datum müssen Unternehmen

  • innerhalb von 24 Stunden nach Kenntnisnahme einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Sicherheitsvorfalls eine Frühwarnung an die ENISA (European Network and Information Security Agency) und das zuständige CSIRT (Computer Security Incident Response Team) – CERT-Bund (Computer Emergency Response Team) in Deutschland – übermitteln,
  • innerhalb von 72 Stunden eine vollständige Meldung an die Behörden einreichen und
  • innerhalb von 14 Tagen nach Bereitstellung einer Korrekturmaßnahme (beziehungsweise innerhalb eines Monats bei schwerwiegenden Vorfällen) einen Abschlussbericht vorlegen.

Wer diesen Fristen nicht gerecht wird, dem drohen horrende Kosten. Bei schwerwiegenden Verstößen sind Höchststrafen von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Umsatzes (je nachdem, welcher Betrag höher ist) vorgesehen.

Die vier häufigsten Lücken

Doch auf diese Anforderungen sind die wenigsten Unternehmen Stand heute vorbereitet. Sicherheits- und Produktverantwortliche, die sich auf die Frist im September vorbereiten, sehen sich in der Regel vier zentralen Lücken gegenüber, die sie schließen müssen.

Lücke 1 – Ungeklärte Verantwortlichkeiten und kein Eskalationspfad

In vielen Unternehmen ist nicht klar, wer die Meldung an die ENISA und das CSIRT tatsächlich einreicht. Auch eine Vertretung für den Krankheits- oder Urlaubsfall der verantwortlichen Person fehlt in der Regel. Ungeklärt ist zudem häufig, wer überhaupt befugt ist, darüber zu entscheiden, ob ein Hinweis eines AppSec-Systems zu einer Schwachstelle als „aktiv ausgenutzt“ einzustufen ist. Da in den meisten Unternehmen diese Überlegungen erst im akuten Notfall geklärt werden sollen, drohen Verstöße gegen den CRA durch verpasste Fristen und in zweiter Instanz horrende Bußgelder.

Lücke 2 – Verzerrtes Zeitgefühl

Die durchschnittliche Zeit bis zum Erkennen einer aktiv ausgenutzten Schwachstelle im eigenen Produkt ist nicht mit der MTTR (Mean Time To Repair) eines SIEM-Alarms gleichzusetzen. Sie hängt von Kundenmeldungen, der Einbindung von Threat Intelligence und davon ab, wie schnell ein Triage-Call einberufen werden kann. Die meisten Teams haben den vollständigen Ablauf nie gemessen. Viele Unternehmen stellen dann bei einem Testlauf fest, dass 24 Stunden mit ihrer aktuellen Strategie gar nicht realistisch einzuhalten sind.

Lücke 3 – Kein sauberes Inventar potenziell betroffener Produkte

Die Meldepflicht gilt für jedes Produkt, das auf dem EU-Markt bereitgestellt wird. Viele Unternehmen haben ein großes Produktportfolio, wissen aber gar nicht, auf welche davon die Vorschriften des CRA anzuwenden sind. Oft herrscht auch Unkenntnis darüber, welche Versionen noch unterstützt werden, welche Komponenten gemeinsam genutzt werden und welche Kunden in der EU ansässig sind. Ohne dieses Wissen können sie unter dem Zeitdruck bei einem tatsächlichen Notfall nicht einmal den nötigen Umfang einer Meldung an die ENISA und das CSIRT definieren.

Lücke 4 – Kein holistisches Monitoring des gesamten Software Development Lifecycle

Eine Schwachstelle, die eine Meldung auslöst, kann im eigenen Code vorkommen. Sie kann allerdings auch aus einer Dependency zu einem Produkt eines Drittanbieters, einer Open-Source-Bibliothek, einer kompromittierten CI/CD-Pipeline, einem offengelegten Secret oder aus KI-generiertem Code stammen. Je schneller Unternehmen Warnsignale mit ihren jeweiligen Produkten, den Auswirkungen auf die Kunden und möglichen Behebungs- oder Korrekturmaßnahmen korrelieren können, desto schneller erfolgt die Frühwarnung. Teams, die mit fragmentierten Scannern und voneinander getrennten ASPM (Application Security Posture Management)-Dashboards arbeiten, verlieren Stunden durch die manuelle Korrelation.

Die richtige Strategie wird zum wichtigsten Faktor

Unternehmen sollten zunächst vollständige Transparenz über alle Produkte mit digitalen Elementen schaffen und diese hinsichtlich ihres Supportstatus sowie ihrer regulatorischen Relevanz erfassen. Ebenso erforderlich sind klar definierte Verantwortlichkeiten für die Bewertung, Eskalation und Meldung von Sicherheitsvorfällen sowie aktiv ausgenutzten Schwachstellen. Neben klar definierten Ansprechpartnern und Vertretungsregelungen müssen sie auch Entscheidungswege, Rufbereitschaften sowie die Einbindung von Rechtsabteilung und Management festlegen. Es gilt sicherzustellen, dass Verantwortliche im Ernstfall innerhalb kürzester Zeit nachvollziehbar entscheiden können, ob ein Ereignis meldepflichtig ist und wer die erforderlichen Schritte veranlasst.

„Darüber hinaus müssen technische und organisatorische Prozesse etabliert werden, die eine schnelle Erkennung, Bewertung und Einordnung von Sicherheitsrisiken ermöglichen“, betont Jochen Koehler, Vice President of EMEA Sales bei Cycode. „Dazu gehört kontinuierliches Monitoring selbst entwickelter Software und Code-Basen, Open-Source-Komponenten, Drittanbieter-Abhängigkeiten, CI/CD-Umgebungen, Infrastruktur, Container, Secrets und KI-Komponenten. Ergänzend sind standardisierte Melde- und Freigabeprozesse, vorbereitete Vorlagen für regulatorische Meldungen, dokumentierte Runbooks sowie regelmäßige Übungen unter realistischen Bedingungen erforderlich.“

Weitere Informationen: www.cycode.com 

Disclaimer:
„Für den oben stehenden Beitrag sowie für das angezeigte Bild- und Tonmaterial ist allein der jeweils angegebene Nutzer verantwortlich. Eine inhaltliche Kontrolle des Beitrags seitens der Seitenbetreiberin erfolgt weder vor noch nach der Veröffentlichung. Die Seitenbetreiberin macht sich den Inhalt insbesondere nicht zu eigen.“