Der Cyber Resilience Act (CRA) setzt Softwarehersteller unter Zeitdruck: Aktiv ausgenutzte Sicherheitslücken müssen innerhalb enger Fristen gemeldet werden. Doch wie schnell können Unternehmen betroffene Produkte identifizieren und Schwachstellen beheben? In seinem Gastbeitrag zeigt Michael Krusche, Gründer und CEO der Krusche & Company GmbH, worauf es bei der technischen und organisatorischen Vorbereitung ankommt.

Freitag, 16 Uhr. Im Postfach der Entwicklungsleitung liegt eine Sicherheitswarnung: Eine weitverbreitete Open-Source-Bibliothek hat eine kritische Lücke, und Angreifer nutzen sie bereits aus. Jetzt zählt jede Stunde.

Für Hersteller, deren Produkte unter den Cyber Resilience Act (CRA) fallen, gelten seit dem 11. September 2026 konkrete Meldepflichten. Bei einer aktiv ausgenutzten Schwachstelle im eigenen Produkt müssen sie unverzüglich melden: Die Frühwarnung ist spätestens 24 Stunden nach Kenntnisnahme fällig, die ausführliche Meldung innerhalb von 72 Stunden. Ab dem 11. Dezember 2027 greifen grundsätzlich auch die übrigen Pflichten des CRA. Dazu gehört, Sicherheitslücken während des maßgeblichen Supportzeitraums systematisch zu behandeln und ohne unangemessene Verzögerung zu beheben.

Die entscheidende Frage lautet an diesem Nachmittag deshalb nicht, wer das Formular ausfüllt. Sie lautet: Wissen wir überhaupt, ob und wo wir betroffen sind? Und wie schnell bekommen wir das Problem gelöst?

Ein Meldeprozess allein schafft noch keine technische Reaktionsfähigkeit. Security kann eine Schwachstelle erkennen. Die Antworten auf beide Fragen müssen Entwicklung und Betrieb liefern.

Schwachstelle entdeckt: Was jetzt passieren muss

1. Betroffenheit erklären

Zuerst muss feststehen, ob die verwundbare Komponente überhaupt in der eigenen Software steckt. Dafür braucht ein Unternehmen einen Überblick über seine Produkte, unterstützte Versionen und die darin enthaltenen Bausteine. Ebenso wichtig ist die Frage, welche Version bei welchem Kunden installiert ist.

In der Praxis liegen diese Informationen häufig verteilt über Repositories, Ticketsysteme, Dokumentationen und das Wissen einzelner Mitarbeiterinnen und Mitarbeiter. Wer sie erst jetzt zusammensuchen muss, verliert wertvolle Zeit.

Wie schwierig diese Bestandsaufnahme sein kann, hat Log4Shell gezeigt. Die Ende 2021 bekannt gewordene kritische Schwachstelle betraf Log4j, eine weit verbreitete Java-Bibliothek zur Protokollierung. Angreifer konnten auf verwundbaren Systemen aus der Ferne Code ausführen. Für viele Unternehmen begann die Arbeit deshalb mit der Frage, in welchen eigenen und zugekauften Anwendungen die Bibliothek überhaupt enthalten war. Oft war Log4j nicht direkt eingebunden, sondern über andere Abhängigkeiten Teil der Software.

Eine aktuelle Software Bill of Materials (SBOM), also eine strukturierte Übersicht über die enthaltenen Komponenten, kann diese Suche deutlich verkürzen. Allein reicht sie jedoch nicht. Erst die Verknüpfung mit Produktversionen und Kundeninstallationen zeigt, wo tatsächlich Handlungsbedarf besteht. Bei Fremdsoftware braucht es zusätzlich eine belastbare Aussage des Anbieters zur Betroffenheit. Bleibt sie aus, bedeutet das keine Entwarnung.

2. Meldung anstoßen und Risiko begrenzen

Steht fest, dass die aktiv ausgenutzte Schwachstelle im eigenen Produkt enthalten ist, laufen mehrere Aufgaben parallel. Melden und Beheben sind dabei zwei verschiedene Dinge. Die 24- und 72-Stunden-Fristen sind keine Reparaturfristen. Mit der ersten Meldung darf ein Unternehmen aber auch nicht warten, bis jede technische Frage abschließend geklärt ist.

Von Beginn an sollte dokumentiert werden, was bereits gesichert ist, welche Fragen noch offen sind, welche Maßnahmen eingeleitet wurden und wann das Unternehmen Kenntnis von der aktiv ausgenutzten Schwachstelle im eigenen Produkt erhalten hat.

Gleichzeitig führen Security, Entwicklung und Betrieb ihre Informationen zusammen. Security bewertet Bedrohung und Risiko, die Entwicklung untersucht die technischen Auswirkungen, der Betrieb prüft Installationen, Konfigurationen und mögliche Angriffsspuren.

Solange noch keine Korrektur verfügbar ist, können eingeschränkte Zugriffe, Netzsegmentierung oder das Abschalten nicht benötigter Schnittstellen die Gefahr begrenzen.

3. Patch entwickeln, testen und freigeben

Ist klar, wo die Schwachstelle steckt, zeigt sich, wie gut die Software wartbar ist. Veraltete Frameworks ohne Sicherheitsupdates, fehlende Testautomatisierung, kundenspezifische Sonderversionen oder manuelle Deployments können selbst kleine Korrekturen erheblich verzögern.

Technische Schulden werden so zu Reaktionsschulden. Automatisierte Tests helfen, unerwünschte Nebenwirkungen früh zu erkennen. Kleine, gezielte Patches lassen sich zudem leichter bewerten als große Sammelupdates.

Für kritische Schwachstellen braucht es einen vorbereiteten Emergency-Release-Prozess. Mindesttests, Freigabeberechtigungen und Eskalationswege sollten bereits feststehen. Beschleunigung bedeutet dabei, unnötige Wartezeiten zu vermeiden. Die Qualitätssicherung bleibt bestehen.

4. Patch ausliefern und Wirkung prüfen

Ein fertiger Patch hilft wenig, wenn er sich nicht sicher verteilen und einspielen lässt. Läuft die Software beim Kunden, muss deshalb geklärt sein, wie das Update dorthin gelangt und wer die Installation übernimmt.

Danach folgt die Kontrolle. Unternehmen müssen prüfen, ob der Patch auf den betroffenen Systemen installiert ist und die Schwachstelle dort behebt. Monitoring hilft, weitere Auffälligkeiten zu erkennen. Für unerwartete Probleme sollte ein getesteter Rückfallplan vorliegen. Hinweise auf bereits erfolgte Angriffe müssen unabhängig davon untersucht werden.

Auch die Meldepflicht läuft weiter. Bei aktiv ausgenutzten Schwachstellen folgt der Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur oder Schutzmaßnahme verfügbar ist.

So bereiten sich Unternehmen auf den Ernstfall vor

Ob diese vier Schritte funktionieren, entscheidet sich lange vor einer Sicherheitswarnung am Freitagnachmittag. Drei Dinge sollten Unternehmen deshalb vorher klären.

Transparenz und Änderbarkeit schaffen

Komponentenübersichten, Abhängigkeitsprüfungen und Security-Checks sollten automatisiert in den Entwicklungsprozess integriert sein. Bei Fremdsoftware ist diese Transparenz oft schwieriger herzustellen, weil Unternehmen enthaltene Komponenten, Abhängigkeiten und Supportstatus nicht vollständig selbst überblicken können. SBOMs, Sicherheitsmeldungen und klare Supportzeiträume gehören deshalb in die Anforderungen an Softwarelieferanten.

Liefert ein Anbieter dauerhaft weder Sicherheitsinformationen noch Aktualisierungen, braucht es einen Ersatz- oder Abschaltplan. Fehlende Unterstützung wird damit irgendwann zur Managemententscheidung.

Rollen und Zuständigkeiten festlegen

Ein gemeinsamer Incident-Prozess braucht einen klar benannten Koordinator. Wer entscheidet, wer meldet und wer mit Kunden kommuniziert, muss ebenso vorab feststehen wie Vertretungen, Zugriffsrechte, Erreichbarkeit und die Regeln für Emergency Releases.

Das gilt auch für externe oder international verteilte Entwicklungsteams. Reaktionszeiten und Eskalationswege sollten verbindlich vereinbart, die nötigen Zugänge geklärt und Übergaben sauber organisiert sein. Unterschiedliche Zeitzonen können sogar helfen, weil die Bearbeitung ohne lange Unterbrechung weiterläuft. Wer einen Entwicklungspartner einbindet, bleibt als Hersteller selbst in der Pflicht.

Den Ablauf einmal durchspielen

Ob die vorbereiteten Prozesse tragen, zeigt am besten ein Testszenario auf Basis einer bereits bekannten Schwachstelle. Unternehmen spielen dabei einen fiktiven Sicherheitsvorfall durch. So lässt sich prüfen, wie lange es dauert, betroffene Produkte und Kunden zu identifizieren, ob Eskalation, Meldung und Anbieterkommunikation funktionieren und wie schnell eine Korrektur entwickelt, getestet, freigegeben und ausgeliefert werden kann.

Fehlende Befugnisse, unklare Zuständigkeiten oder lange Abstimmungswege werden so sichtbar, bevor ein echter Vorfall den Takt vorgibt. Damit diese Reaktionsfähigkeit erhalten bleibt, braucht es feste Verantwortliche und Kapazitäten statt eines einmaligen Compliance-Projekts.

Sicherheit endet nicht mit der Auslieferung

Die neuen Meldefristen legen offen, ob eine Softwareorganisation ihre Produkte kennt und im Griff hat. Wartbarkeit und kontrollierte Änderbarkeit werden damit zu Sicherheitseigenschaften, die über den gesamten Supportzeitraum erhalten bleiben müssen. Neben der Frage, wie schnell ein Unternehmen neue Funktionen liefert, gewinnt deshalb eine zweite an Gewicht: Wie schnell können wir ein Sicherheitsproblem verstehen und zuverlässig beheben?