Vulnerability Disclosure: Was Hersteller regulatorisch beachten müssen

Wenn eine Sicherheitslücke zur Compliance-Frage wird

Ich erinnere mich an ein Gespräch mit einem Sicherheitsforscher aus Berlin, der mir schilderte, wie er eine kritische Schwachstelle in einem vernetzten Industriesteuergerät entdeckte — und dann wochenlang nicht wusste, wohin damit. Der Hersteller hatte keine erkennbare Meldestelle, keine Policy, kein Feedback. Die Lücke blieb offen. Das war vor drei Jahren. Heute wäre dieser Zustand nicht mehr nur ein ethisches Problem, sondern ein regulatorisches.

Die Entdeckung von Schwachstellen durch externe Forscher ist längst kein Ausnahmefall mehr. Für Hersteller vernetzter Produkte in Europa gehört es zum Alltag — oder sollte es zumindest. Mit Inkrafttreten des Cyber Resilience Act und der überarbeiteten NIS2-Richtlinie haben sich die Spielregeln grundlegend verschoben: Was früher freiwillige Best Practice war, ist heute regulatorische Pflicht. Wer das unterschätzt, riskiert nicht nur Bußgelder, sondern auch das Vertrauen der Sicherheitsgemeinschaft.

Ein Blick auf aktuelle Entwicklungen zeigt dabei interessante Unterschiede zwischen Frankreich und Deutschland. Die ANSSI ist seit Jahren für ihre strukturierte Koordinationsrolle bekannt und hat früh eigene CVD-Leitlinien entwickelt. Das BSI zog nach, arbeitet aber noch an der vollständigen Integration in nationale Umsetzungsmaßnahmen des CRA. Beide Behörden stehen vor derselben Grundfrage: Wie wird koordinierte Offenlegung vom Prinzip zur gelebten Praxis?

Was CRA und NIS2 konkret fordern

Der Cyber Resilience Act verpflichtet Hersteller von Produkten mit digitalen Elementen zur Einrichtung eines strukturierten CVD-Prozesses — Coordinated Vulnerability Disclosure. Das umfasst nicht nur interne Abläufe, sondern explizit auch die Meldepflicht gegenüber ENISA. Artikel 14 des CRA ist dabei bemerkenswert konkret: Hersteller müssen aktiv ausnutzbare Schwachstellen und Sicherheitsvorfälle melden, nicht nur passiv auf Berichte reagieren.

NIS2 ergänzt dies auf der Betreiberseite: Kritische und wichtige Einrichtungen müssen Schwachstellen in genutzten Komponenten aktiv monitoren — und bei Relevanz melden. Das betrifft auch eingekaufte Software und Hardware. Wer als Betreiber ein Produkt einsetzt, das eine bekannte, ungepatchte Schwachstelle enthält, trägt Mitverantwortung für das Risikomanagement.

Das Entscheidende: Beide Regelwerke greifen ineinander. Ein Hersteller, der gleichzeitig Betreiber kritischer Infrastruktur ist — etwa im Energiesektor —, unterliegt doppelten Anforderungen. Eine isolierte Betrachtung nach dem Motto „Das ist ein CRA-Thema, kein NIS2-Thema" ist regulatorisch gefährlich und in der Praxis schlicht falsch.

Der CVD-Prozess: Architektur einer regulatorisch konformen Offenlegung

Ein wirksamer CVD-Prozess ist keine Checkliste — er ist ein operatives System. Zu den Mindestanforderungen gehören:

• Eingangskanäle: Eine security.txt-Datei nach RFC 9116 ist der einfachste erste Schritt, um Forscher nicht im Leeren stehen zu lassen.
• Reaktionsfristen: Interne SLAs für Erstbestätigung (72 Stunden), Bewertung (10 Tage) und Remediation — kommuniziert und eingehalten.
• Transparente Kommunikation: Melder müssen wissen, was mit ihrer Meldung passiert. Keine Rückmeldung ist kein akzeptabler Standard.

Der CRA schreibt vor, dass Hersteller aktiv ausnutzbare Schwachstellen innerhalb von 24 Stunden nach Kenntnis an ENISA melden müssen. Das ist ein ambitionierter Zeitrahmen. Wer glaubt, das ad hoc lösen zu können, unterschätzt die operative Komplexität: Zuständigkeiten klären, CVE-Koordination anstoßen, Behördenmeldung formulieren, interne Eskalation — all das in unter einem Tag.

„Ein Prozess, der nur auf dem Papier existiert, ist kein Prozess. Er ist ein falsches Sicherheitsgefühl."

Als prozessuale Grundlage empfehlen sich ISO/IEC 29147 (Vulnerability Disclosure) und ISO/IEC 30111 (Vulnerability Handling Processes). Diese Normen sind nicht verpflichtend, aber sie liefern die strukturelle Sprache, die Auditoren und Behörden erwarten.

Security Research und rechtliche Graubereiche

Hier liegt eines der ungelösten Probleme des europäischen Regulierungsrahmens. Sicherheitsforscher operieren noch immer in einem rechtlich unklaren Raum. In Deutschland kann § 202a StGB greifen — der Tatbestand des unbefugten Zugriffs auf Computerdaten —, selbst wenn die Absicht eindeutig konstruktiv war. In Frankreich ist Art. 323-1 Code pénal vergleichbar formuliert.

Der CRA enthält keine explizite Safe-Harbour-Regelung für Researcher. Diese Lücke wird in der Community intensiv diskutiert. Im Vergleich: Die USA haben mit dem CFAA-Reform-Diskurs und einzelnen Prosecutor-Leitlinien zumindest Bewegung gezeigt. Europa hinkt nach.

Was Hersteller tun können — und sollten: Bug-Bounty-Programme mit klar definierten Legal-Safe-Zones. Nicht weil es die Regulierung verlangt, sondern weil es funktioniert. Programme wie die von HackerOne oder YesWeHack — das letztere mit starker französischer Verwurzelung — bieten Plattformen, auf denen Hersteller Scope, Regeln und rechtliche Absicherung klar kommunizieren können.

Wer das tut, reduziert nicht nur sein Rechtsrisiko. Er signalisiert der Forschercommunity: Nous vous écoutons. Das ist ein strategischer Vorteil.

Meldepflichten in der Praxis: Fristen, Behörden, Eskalationswege

Die zeitliche Komplexität verdient besondere Aufmerksamkeit. Hersteller müssen im Ernstfall zwei Uhren gleichzeitig im Blick behalten:

• 24 Stunden (CRA): Erstmeldung aktiv ausnutzbarer Schwachstellen an ENISA
• 72 Stunden (NIS2): Meldung erheblicher Sicherheitsvorfälle an nationale Behörden

Dazu kommen nationale Besonderheiten. Das BSI und die ANSSI fungieren als koordinierende Stellen und können eigene Anforderungen ergänzen. Die ANSSI hat beispielsweise mit ihrem Cadre de référence pour la divulgation coordonnée des vulnérabilités bereits Orientierung gegeben. Das BSI arbeitet an vergleichbaren operativen Leitlinien im Kontext der CRA-Umsetzung.

Die Konsequenzen verspäteter oder fehlender Meldungen sind unter NIS2 erheblich: bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes. Für mittelständische Hersteller kann das existenzbedrohend sein. Und: Die Bußgelder treffen nicht nur Betreiber. Hersteller, die ihre CRA-Pflichten verletzen, können Marktzugangsbeschränkungen riskieren.

Typische Implementierungsfehler und wie man sie vermeidet

In meiner Beobachtung von Unternehmensreaktionen auf neue Regulierungsanforderungen zeigen sich immer wieder dieselben Muster:

• Falle Nr. 1 — Policy ohne Operationalisierung: CVD-Dokumente existieren, aber die zuständigen Teams kennen sie nicht. Die Policy wurde vom Legal-Team geschrieben und nie in operative Abläufe übersetzt. Beim ersten echten Vorfall bricht das System zusammen.

• Falle Nr. 2 — Silos zwischen Legal, Security und Kommunikation: Drei Abteilungen, drei verschiedene Botschaften gegenüber dem Melder und der Behörde. Das erzeugt Vertrauensverlust — und dokumentierte Inkonsistenz, die Auditoren nicht gerne sehen.

• Falle Nr. 3 — Keine Übung unter Zeitdruck: Prozesse, die nie gestresst wurden, versagen unter Stress. Ein regelmäßiges Tabletop-Exercise — eine simulierte Schwachstellenmeldung mit Stoppuhr — deckt Lücken auf, bevor es ein Auditor tut. Oder schlimmer: ein Angreifer, der genau weiß, dass der Hersteller 72 Stunden braucht, um intern Klarheit zu schaffen.

Was Hersteller jetzt konkret angehen sollten

Der Regulierungsrahmen ist gesetzt. Die Umsetzungsfristen laufen. Was jetzt zählt, ist operative Konsequenz:

• Regulatorische Klarheit schaffen: Prüfen, ob das eigene Produkt in den Anwendungsbereich des CRA fällt — die Klassifikation als „Produkt mit digitalen Elementen" ist weiter als viele annehmen. CVD-Anforderungen gehören in die Produktentwicklung, nicht ans Ende des Release-Zyklus.

• Prozesse formalisieren und publizieren: CVD-Policy veröffentlichen, security.txt einrichten, interne Eskalationswege dokumentieren, mit ISO 29147/30111 abgleichen. Das ist keine Einmalaufgabe, sondern ein lebender Prozess.

• Behördliche Meldewege vorbereiten: Kontakte zu BSI und ANSSI — je nach Marktpräsenz — aufbauen, bevor der erste Ernstfall eintritt. Behörden schätzen proaktive Hersteller. Das zahlt sich im Krisenfall aus.

EACG unterstützt Hersteller bei der regulatorischen Einordnung, der Prozessgestaltung und der konkreten Vorbereitung auf BSI- und ANSSI-Anforderungen. Die Frage ist nicht ob eine Schwachstelle gemeldet wird — sondern ob Ihr Unternehmen bereit ist, wenn es passiert.

Zur Person

Schreibt für französische Outlets über EU-Regulierung im Cybersecurity-Kontext.

Gastbeitrag. Tech-Journalistin, EACG ist regulatorische Quelle. Nicht vergütet.