Der schnellste Weg, den CRA misszuverstehen, ist die Annahme, dass jede Schwachstelle einem Regulierer gemeldet werden muss. Das muss sie nicht. Die Meldepflicht nach Artikel 14 ist bewusst eng gefasst. Die überwiegende Mehrheit der Schwachstellen, die ein Hersteller entdeckt, empfängt und behebt, überschreitet nie die Schwelle, die eine Meldung an Behörden auslöst. Sie werden intern unter den Schwachstellenbehandlungsregeln in Artikel 13 bearbeitet.
Zu wissen, wo diese Schwelle liegt, ist unerlässlich. Melden Sie zu wenig, verstoßen Sie gegen die Verordnung. Melden Sie alles, überschwemmen Sie die Behörden, erschöpfen Ihr eigenes Team und verlieren das Signal, das zählt. Dieser Beitrag definiert die zwei meldepflichtigen Kategorien, grenzt sie von der routinemäßigen Schwachstellenbehandlung ab und liefert einen Entscheidungsrahmen mit durchgearbeiteten Beispielen.
Es ist der zweite Beitrag unserer CRA-Meldeserie. Der erste behandelte wann die Meldung verpflichtend wird. Spätere Beiträge behandeln wohin Meldungen gehen und die geltenden Fristen. Für eine einseitige Übersicht des gesamten Melderegimes siehe unseren Leitfaden zu welche CRA-Meldepflichten gelten, wann sie beginnen und wie man bereit ist.
Zwei meldepflichtige Kategorien, und alles andere
Artikel 14 schafft zwei eigenständige Meldeauslöser. Sie sind verwandt, aber nicht dasselbe, und sie zu vermengen, ist eine häufige Fehlerquelle.
Kategorie eins: aktiv ausgenutzte Schwachstellen
Eine Schwachstelle wird meldepflichtig, wenn sie aktiv ausgenutzt wird. Der Test hat zwei Teile. Es muss eine Schwachstelle in Ihrem Produkt geben, und es muss Hinweise geben, dass ein böswilliger Akteur sie im Feld gegen reale Systeme ausnutzt.
Das Wort, das hier die Arbeit leistet, ist „aktiv“. Eine Schwachstelle, die theoretisch ausnutzbar ist, einen veröffentlichten Proof of Concept hat oder hoch auf CVSS bewertet ist, ist nicht automatisch meldepflichtig. Sie wird meldepflichtig, wenn die Ausnutzung tatsächlich stattfindet. Über genau diese Unterscheidung haben wir separat in ausnutzbar versus ausgenutzt bei den Meldepflichten geschrieben, weil sie die am häufigsten falsch eingeschätzte Entscheidung im gesamten Regime ist.
Kategorie zwei: schwerwiegende Vorfälle, die die Produktsicherheit beeinträchtigen
Der zweite Auslöser ist ein schwerwiegender Sicherheitsvorfall, der sich auf die Sicherheit des Produkts auswirkt. Das ist breiter als eine Schwachstelle im Code. Es erfasst Ereignisse wie eine Kompromittierung der Build-Pipeline, der Signaturinfrastruktur oder des Systems zur Update-Verteilung des Herstellers, wo diese Kompromittierung die Sicherheit von Produkten im Feld beeinträchtigt.
Ein schwerwiegender Vorfall erfordert keine bekannte Schwachstelle im Produkt selbst. Das klassische Beispiel ist eine Lieferkettenkompromittierung: Ein Angreifer erlangt Zugang zu Ihrer Softwareverteilung und liefert ein manipuliertes Update aus. Das Produkt mag makellos sein, aber der Vorfall, der seine Sicherheit beeinträchtigt, ist schwerwiegend und meldepflichtig.
Alles andere: behandelt, nicht gemeldet
Außerhalb dieser zwei Kategorien sitzt der große Bestand routinemäßiger Schwachstellenarbeit. Ein Forscher meldet einen gespeicherten Cross-Site-Scripting-Fehler in Ihrer Admin-Konsole. Ihr eigenes Team findet bei einem Code-Review einen Buffer Overflow. Ein Abhängigkeits-Scanner kennzeichnet eine verwundbare Bibliotheksversion. Keiner davon löst für sich genommen eine Artikel-14-Meldung aus. Sie werden unter Artikel 13 bearbeitet: triagiert, behoben und über Ihren Prozess der koordinierten Offenlegung offengelegt.
Das ist das Verhältnis, das die meisten Menschen falsch einschätzen. In einem gesunden Programm sind meldepflichtige Ereignisse selten und die routinemäßige Behandlung konstant. Wenn Sie das meiste, was Sie behandeln, auch melden, haben Sie die Schwelle falsch gelesen.
Der Entscheidungsrahmen
Arbeiten Sie für jede Schwachstelle oder jeden Vorfall vier Fragen der Reihe nach durch.
- Gibt es eine Schwachstelle in oder einen Sicherheitsvorfall betreffend ein Produkt mit digitalen Elementen, das wir auf den EU-Markt gebracht haben? Wenn nein, gilt Artikel 14 nicht. Ist das betroffene Ding ein internes Werkzeug ohne Bezug zu einem vermarkteten Produkt, fällt es nicht in den Geltungsbereich.
- Bei einer Schwachstelle: Wird sie im Feld aktiv ausgenutzt? Suchen Sie nach Hinweisen auf eine reale Ausnutzung: Kompromittierungsindikatoren, Exploit-Verkehr, Opfermeldungen, Bestätigung durch Bedrohungsinformationen. Ein hoher Schweregradwert oder ein öffentlicher PoC ist für sich genommen keine aktive Ausnutzung.
- Bei einem Vorfall: Ist er schwerwiegend, und beeinträchtigt er die Sicherheit des Produkts? Berücksichtigen Sie die Auswirkung auf Vertraulichkeit, Integrität oder Verfügbarkeit für Nutzer des Produkts, die Zahl der potenziell betroffenen Nutzer und ob der Vorfall Infrastruktur berührt, die das Produkt schützt.
- Haben wir davon Kenntnis erlangt? Die Pflicht läuft ab der Kenntnis. Eine glaubwürdige Meldung eines Forschers oder Kunden kann eine Kenntnis darstellen, noch bevor Sie sie vollständig bestätigt haben. Behandeln Sie ein glaubwürdiges Signal im Zweifel als Beginn der Uhr.
Besteht eine Schwachstelle die Fragen eins, zwei und vier, ist sie als aktiv ausgenutzte Schwachstelle meldepflichtig. Besteht ein Vorfall die Fragen eins, drei und vier, ist er als schwerwiegender Vorfall meldepflichtig. Alles andere ist routinemäßige Behandlung.
Durchgearbeitete Beispiele
Abstrakte Kriterien sind unter Druck schwer anzuwenden. Diese Beispiele zeigen den Rahmen im Einsatz.
Beispiel 1: kritischer CVSS, keine Ausnutzung
Ein Forscher meldet privat einen nicht authentifizierten Fehler für Remote Code Execution in Ihrer Netzwerkappliance. Er erreicht 9,8. Es gibt keine Hinweise, dass jemand ihn ausnutzt. Meldepflichtig nach Artikel 14? Nein. Es ist eine schwerwiegende Schwachstelle, die Sie unter Artikel 13 dringend behandeln, beheben und für die Sie die Offenlegung koordinieren müssen. Sie löst die Artikel-14-Uhr nicht aus, es sei denn und solange Sie keine aktive Ausnutzung sehen. Beginnt die Ausnutzung, ändert sich die Lage sofort.
Beispiel 2: niedriger Schweregrad, aktive Ausnutzung
Angreifer verketten einen bescheidenen Fehler zur Informationsoffenlegung in Ihrem Produkt, um Zugangsdaten abzugreifen, und Sie haben Log-Belege, dass das bei mehreren Kunden geschieht. Der einzelne Fehler ist auf einer Schweregradskala nicht dramatisch. Meldepflichtig? Ja. Er wird im Feld aktiv ausgenutzt. Die aktive Ausnutzung, nicht der Schweregradwert, ist der Auslöser.
Beispiel 3: Kompromittierung der Build-Pipeline
Ein Angreifer bricht in Ihr CI-System ein, und Sie entdecken, dass ein manipulierter Build signiert und mehrere Stunden lang zum Download bereitgestellt wurde, bevor Sie ihn bemerkten. Keine spezifische Code-Schwachstelle ist beteiligt. Meldepflichtig? Ja, als schwerwiegender Vorfall, der die Produktsicherheit beeinträchtigt. Die Integrität des Produkts, wie es an Nutzer ausgeliefert wurde, war kompromittiert.
Beispiel 4: verwundbare Abhängigkeit, keine Produktauswirkung
Ein Scanner kennzeichnet eine verwundbare Version einer Logging-Bibliothek, die in Ihrem Produkt gebündelt ist. Der verwundbare Codepfad ist in Ihrer Konfiguration nicht erreichbar, und es gibt keine Ausnutzung. Meldepflichtig? Nein. Behandeln Sie ihn: Erreichbarkeit bestätigen, Abhängigkeit aktualisieren, die Analyse dokumentieren. Verfolgen Sie ihn in Ihrem SBOM-gestützten Komponenteninventar. Er wird nur meldepflichtig, wenn sich herausstellt, dass er ausnutzbar ist, und dann aktiv ausgenutzt wird.
Beispiel 5: ausgenutzter Zero-Day in einem eingestellten, aber noch unterstützten Produkt
Ein Produkt, das Sie vor zwei Jahren nicht mehr verkauft haben, das aber noch innerhalb seines erklärten Unterstützungszeitraums ist, wird von einem ausgenutzten Zero-Day getroffen. Meldepflichtig? Ja. Der Support-Status, nicht der Verkaufsstatus, bestimmt den Geltungsbereich. Wenn Sie ihm noch Sicherheitsupdates schulden, ist eine aktiv ausgenutzte Schwachstelle darin meldepflichtig.
Randfälle, die man vorab entscheiden sollte
Ein paar Situationen treten oft genug auf, dass Sie Ihre Haltung im Voraus festlegen sollten statt unter Fristdruck.
- Vermutete, aber unbestätigte Ausnutzung. Eine glaubwürdige Meldung sagt, eine Ausnutzung finde statt, aber Sie können sie noch nicht bestätigen. Die kluge Lesart ist, dass ein glaubwürdiges Signal die Kenntnis-Uhr startet. Die Frühwarnung darf vorläufig sein, sodass Sie sie einreichen können, während Sie bestätigen, statt zu riskieren, das Fenster zu verpassen.
- Ausnutzung einer Drittkomponente, die Sie ausliefern. Ist die verwundbare Komponente Teil des Produkts, das Sie in Verkehr gebracht haben, und wird sie aktiv ausgenutzt, knüpft die Herstellerpflicht an Sie an, unabhängig davon, wer die Komponente geschrieben hat.
- Schwachstelle in einem nicht mehr unterstützten Produkt. Ist das Produkt wirklich außerhalb des Supports und schulden Sie keine weiteren Updates, sitzt es außerhalb des laufenden Behandlungsregimes. Stellen Sie sicher, dass Ihre Erklärungen zum Support-Ende klar und dokumentiert sind, denn genau hier entstehen Streitigkeiten.
- Ausnutzung, die von einem Kunden beobachtet wird, nicht von Ihnen. Ein Kunde, der Ihnen sagt, dass er über Ihr Produkt angegriffen wird, ist Kenntnis. Die Uhr wartet nicht darauf, dass Sie es im Labor reproduzieren.
Warum Überberichterstattung ihr eigenes Versagen ist
Es ist verlockend, die Schwelle konservativ zu behandeln und alles zu melden, was qualifizieren könnte. Das fühlt sich sicher an. Ist es nicht.
Behörden betreiben die Meldeplattform, um wirklich ausgenutzte Schwachstellen und schwerwiegende Vorfälle zutage zu fördern, damit sie eine Reaktion koordinieren und andere warnen können. Ein Strom nicht ausgenutzter, routinemäßiger Schwachstellen verwässert dieses Signal und verbraucht Kapazität, die zu echten Ereignissen gehen sollte. Es trainiert auch Ihre eigene Organisation, die Meldung als routinemäßigen Papierkram zu behandeln, was die Dringlichkeit untergräbt, die ein echtes Artikel-14-Ereignis verlangt.
Die Disziplin, die die Verordnung erwartet, ist die genaue Klassifizierung: die vielen behandeln, die wenigen melden und die Begründung in beide Richtungen zeigen können. Dieser Begründungspfad ist Teil des Grundes, warum das Audit-Log wichtig ist.
Die Entscheidung in beide Richtungen dokumentieren
Halten Sie für jedes Ereignis, das plausibel meldepflichtig sein könnte, die Feststellung und ihre Grundlage fest. Haben Sie gemeldet, halten Sie fest, auf welche Hinweise auf aktive Ausnutzung oder schwerwiegende Auswirkung Sie sich gestützt haben. Haben Sie nicht gemeldet, halten Sie fest, warum die Schwelle nicht erreicht war.
Diese Aufzeichnung dient zwei Zwecken. Sie zeigt einer Marktüberwachungsbehörde, dass Sie einen konsistenten, belastbaren Prozess angewandt haben. Und sie schützt die Personen, die die Entscheidung trafen, denn eine dokumentierte, in gutem Glauben getroffene Klassifizierung ist etwas ganz anderes als ein undokumentiertes Versäumnis.
CVD Portal erfasst das automatisch. Jede Einreichung trägt ihre Triage-Entscheidung, die Schweregradbewertung, die Feststellung zur aktiven Ausnutzung und einen mit Zeitstempel versehenen Pfad dazu, wer was wann entschied, sodass die Begründung sowohl gemeldeter als auch nicht gemeldeter Ereignisse ohne zusätzlichen Aufwand erhalten bleibt.
Das Fazit
Die Meldung nach Artikel 14 ist von ihrer Anlage her eng. Nur aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, die die Produktsicherheit beeinträchtigen, müssen gemeldet werden. Schweregradwerte, öffentliche Proofs of Concept und verwundbare Abhängigkeiten lösen für sich genommen keine Meldung aus. Sie lösen eine Behandlung aus.
Bekommen Sie die Klassifizierung richtig hin, und die Meldung wird zu einem seltenen, gut belegten Akt statt zu einer ständigen Last. Der nächste Beitrag der Serie verfolgt die Meldung, sobald sie eingereicht ist, und erklärt, wie die Meldung an ENISA und nationale Behörden organisiert ist.