Anhang I Teil II Buchstabe 5 des EU Cyber Resilience Act (Verordnung (EU) 2024/2847) verpflichtet jeden Hersteller, eine Richtlinie zur koordinierten Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure, CVD) einzuführen und durchzusetzen, und Artikel 13(17) verlangt einen einzigen, menschlich erreichbaren Ansprechpartner für Schwachstellenmeldungen. Eine KMU-Ausnahme besteht nicht. Diese Seite behandelt, was die Richtlinie enthalten muss, wie der Kontaktkanal zu veröffentlichen ist und wie CVD mit der Artikel-14-Meldepflicht und dem übergeordneten Rahmen aus Anhang I Teil II zusammenwirkt.
Zusammenfassung
- CVD-Richtlinie ist Pflicht nach Anhang I Teil II Buchstabe 5: schriftlich, veröffentlicht, durchgesetzt, ohne Größenschwelle.
- Artikel 13(17) verlangt einen einzigen Ansprechpartner, über den Nutzer Schwachstellen melden können; der Kanal darf nicht auf automatisierte Tools beschränkt sein.
security.txt(RFC 9116) ist die De-facto-Konvention zur Veröffentlichung des Kontakts, aber der CRA schreibt kein bestimmtes Format vor.- CVD ist nicht mit der Artikel-14-Meldung identisch: CVD regelt die Beziehung zum Meldenden; Artikel 14 betrifft die regulatorische Frist gegenüber ENISA und dem koordinierenden CSIRT, sobald eine Schwachstelle aktiv ausgenutzt wird.
- Die öffentliche Offenlegung behobener Schwachstellen ist Pflicht nach Anhang I Teil II Buchstabe 4, mit einer engen Ausnahme für Fälle, in denen das Sicherheitsrisiko der Veröffentlichung den Nutzen überwiegt, bis die Nutzer die Möglichkeit hatten, den Patch einzuspielen.
- Bußgelder der höchsten Stufe drohen: bis zu €15.000.000 oder 2,5 % des weltweiten Jahresumsatzes nach Artikel 64(2), je nachdem, was höher ist.
Die vier Ankerpunkte einer CRA-konformen CVD-Postur: die Richtlinienpflicht, die Kontaktpflicht, die Veröffentlichungskonvention und die Bußgeldobergrenze.
Was der CRA für CVD tatsächlich verlangt
Anhang I Teil II Buchstabe 5 ist kurz. Wortlaut aus Verordnung (EU) 2024/2847:
(5) eine Richtlinie zur koordinierten Offenlegung von Schwachstellen einzuführen und durchzusetzen;
Dieser einzelne Satz enthält vier operative Bestandteile, von denen jeder in der Praxis auf andere Weise versagt:
Bedeutet, dass eine schriftliche, zugängliche Richtlinie vorliegen muss. Eine undokumentierte interne Gewohnheit, security@-E-Mails zu triagieren, genügt nicht.
Bedeutet, dass die Richtlinie nicht nur veröffentlicht, sondern auch gelebt wird. Bestätigungsfristen, Triage-Zusagen und Offenlegungsbedingungen, die das Dokument nennt, müssen in der Praxis eingehalten werden. Eine Richtlinie, die eine 72-Stunden-Bestätigung verspricht, auf die routinemäßig drei Wochen folgen, wird nicht durchgesetzt.
Ist die Richtung, der die Richtlinie dienen muss. Anhang I Teil II Buchstabe 6 macht dies ausdrücklich: Hersteller müssen "den Austausch von Informationen über potenzielle Schwachstellen erleichtern", "unter anderem durch Bereitstellung einer Kontaktadresse".
Steht nicht im CRA-Text. Erwägungsgrund 76 beschreibt CVD als strukturierten Meldeprozess und nennt Bug-Bounty-Programme als möglichen Anreiz. Die Praxis der Branche (ISO/IEC 29147, ENISA-Leitfaden zur guten Praxis) behandelt Safe Harbour für gutgläubige Forschung als CVD-Richtliniennorm; der CRA selbst kodifiziert dies nicht.
Den übergeordneten Rahmen aus Anhang I Teil II (die acht nummerierten Pflichten, von denen CVD eine ist) finden Sie unter CRA-Schwachstellenbehandlung.
Der einzige Ansprechpartner (Artikel 13(17))
Artikel 13(17) steht neben Anhang I Teil II Buchstabe 5 und gibt ihm operationale Form. Wortlaut:
- Für die Zwecke dieser Verordnung benennen die Hersteller einen einzigen Ansprechpartner, damit die Nutzer direkt und schnell mit ihnen kommunizieren können, unter anderem um die Meldung von Schwachstellen des Produkts mit digitalen Elementen zu erleichtern.
Die Hersteller stellen sicher, dass der einzige Ansprechpartner für die Nutzer leicht identifizierbar ist. Sie geben den einzigen Ansprechpartner auch in den Informationen und Anweisungen für den Nutzer gemäß Anhang II an.
Der einzige Ansprechpartner ermöglicht es den Nutzern, ihr bevorzugtes Kommunikationsmittel zu wählen, und darf diese Mittel nicht auf automatisierte Tools beschränken.
Drei Regeln, die zu verinnerlichen sind:
- Leicht identifizierbar. Der Kontakt muss in den Produktinformationen, in den begleitenden Anhang-II-Anweisungen und auf der öffentlichen Website sichtbar sein. Ein Kontakt, der nur über die Datenschutzerklärung erreichbar ist, besteht diesen Test nicht.
- Mehrere Kanäle. "Ihr bevorzugtes Kommunikationsmittel wählen" bedeutet mindestens zwei. Ein funktionierendes
security@-Postfach sowie ein Webformular, mit einem PGP-Schlüssel für vertrauliche Einreichungen, sind die realistische Mindestanforderung. - Kein rein automatisierter Eingang. "Darf diese Mittel nicht auf automatisierte Tools beschränken" schließt eine Haltung aus, bei der die einzige erreichbare Adresse
security-noreply@oder ein Chatbot ist, der Tickets ohne menschliche Prüfung schließt.
Der CRA schreibt nicht vor, Verbrauchersupport und Schwachstelleneingang zu trennen, aber die meisten Hersteller betreiben ein dediziertes Sicherheitspostfach, das an das Produktsicherheitsteam weitergeleitet wird, um CVD von allgemeinem Support zu unterscheiden.
CVD-Richtlinie veröffentlichen: security.txt und darüber hinaus
Der CRA nennt security.txt, RFC 9116 oder ein bestimmtes Veröffentlichungsformat nicht. Er verlangt einen Kontaktkanal, der "leicht identifizierbar" ist, und eine CVD-Richtlinie, die "eingeführt und durchgesetzt" wird. Innerhalb dieser Grenzen hat sich die Branche auf security.txt als De-facto-Konvention geeinigt.
Empfehlenswerte RFC-9116-Felder:
| Feld | Zweck |
|---|---|
Contact: |
Einer oder mehrere Meldekanäle. Mindestens einer ist Pflicht. |
Expires: |
Datum, nach dem die Datei veraltet ist. Pflicht nach RFC 9116. |
Encryption: |
Öffentlicher Schlüssel (PGP, S/MIME) für vertrauliche Meldungen. |
Acknowledgments: |
Seite, die Forscher für frühere Offenlegungen würdigt. |
Policy: |
Link zum vollständigen CVD-Richtliniendokument. |
Preferred-Languages: |
Sprachen, in denen das Triage-Team arbeitet. |
Canonical: |
URL, unter der die Datei erwartet wird. |
Hosting. Der übliche Ablageort ist https://example.com/.well-known/security.txt, bereitgestellt über HTTPS. RFC 9116 akzeptiert auch https://example.com/security.txt als Fallback, aber well-known wird bevorzugt.
Über security.txt hinaus. Der Standard "leicht identifizierbar" bedeutet, dass der Kontakt auch auf der Produkt-Support- oder Kontaktseite erscheinen sollte, in den begleitenden Anhang-II-Anweisungen, in der Entwicklerdokumentation für API-Produkte und auf einer öffentlichen CVD-Richtlinienseite, auf die Forscher verlinken können.
Hersteller, die Bug-Bounties betreiben, fügen üblicherweise HackerOne, Bugcrowd oder Intigriti als zusätzliche Eingangskanäle hinzu. Diese erfüllen die Pflicht zur Erleichterung von Meldungen (Anhang I Teil II Buchstabe 6) und die Pflicht "nicht auf automatisierte Tools beschränkt" (Artikel 13(17)) nur dann, wenn sie für externe Meldende mit menschlicher Antwort offen sind. Ein privates, nur auf Einladung zugängliches Bounty-Programm erfüllt für sich allein die Anforderung an einen öffentlichen Kontakt nicht und muss neben einem öffentlichen Kanal bestehen.
Schwachstellenmeldungen empfangen und triagieren
Eine CVD-Richtlinie wird durch einen dokumentierten Eingang-und-Triage-Workflow durchgesetzt. Die nachfolgenden Mechanismen sind nicht vom CRA vorgeschrieben, aber sie zeigen, wie eine durchsetzbare Richtlinie in der Praxis aussieht.
| Phase | Was eine durchsetzbare Richtlinie tut | Häufiger Fehler |
|---|---|---|
| Bestätigung | Eingang innerhalb des veröffentlichten SLA bestätigen. Branchenübliche Basis sind 72 Stunden; viele Richtlinien sagen 24 oder 48 Stunden für hochgradige Meldungen zu. Was veröffentlicht wird, wird getan. | "Wir werden zeitnah antworten" ist auf den ersten Blick nicht durchsetzbar. |
| Triage | Validieren (reproduzierbar auf einer unterstützten Version), Schweregrad bewerten (CVSS v3.1 oder v4.0 mit Umgebungsanpassungen, siehe Schweregradbewertung), Ausnutzbarkeit beurteilen (bekannter Exploit, öffentlicher PoC oder In-the-Wild-Belege, was das Eingangstor zu Artikel 14 ist) und über das SBOM auf betroffene Versionen eingrenzen. | Schließen als "nicht reproduzierbar" ohne Angabe der getesteten Versionsrange. |
| Forscherbeziehung | Drei Dinge veröffentlichen: eine Safe-Harbour-Erklärung für gutgläubige Forschung im Geltungsbereich; Out-of-Scope-Punkte (Produktionsdaten, Social Engineering, Denial-of-Service gegen Live-Infrastruktur); und Offenlegungserwartungen (Embargo-Fenster, Fix-Bedingungen, Anerkennung). Typisches Embargo: bis der Patch ausgeliefert ist, mit einem harten Backstop von 90 Tagen. | Das Recht vorbehalten, rechtliche Schritte gegen Forschung im Geltungsbereich einzuleiten, was den Kanal zum Erliegen bringt. |
| Abschließen | Jede Meldung erhält eine abschließende Antwort: behoben (mit Advisory und CVE), Duplikat, wird nicht behoben (mit Begründung) oder außerhalb des Geltungsbereichs. | Einmal bestätigen und danach schweigen, der häufigste Grund, warum CVD-Richtlinien von außen nicht durchgesetzt wirken. |
Koordination mit ENISA und externen Forschern
CVD-Eingang und Artikel-14-ENISA-Meldung sind verschiedene Pflichten mit verschiedenen Adressaten. Die CVD-Richtlinie regelt die Beziehung zum Meldenden. Artikel 14 regelt die regulatorische Benachrichtigung des Herstellers an ENISA und das koordinierende CSIRT. Sie laufen parallel und werden durch unterschiedliche Ereignisse ausgelöst.
Wenn eine CVD-Meldung zum Artikel-14-Auslöser wird. Artikel 14(1) verpflichtet Hersteller, "jede aktiv ausgenutzte Schwachstelle" über die SRP zu melden. Artikel 14(2) legt den Takt fest: 24-Stunden-Frühwarnung, 72-Stunden-Meldung und ein Abschlussbericht innerhalb von 14 Tagen nach Verfügbarkeit einer Abhilfemaßnahme. Der Auslöser ist "aktiv ausgenutzt", nicht "gemeldet". Ein CVD-Eingang mit einem funktionierenden Proof-of-Concept ist für sich allein kein Artikel-14-Auslöser; er wird zu einem solchen, wenn ein begründeter Verdacht besteht, dass ein böswilliger Akteur die Schwachstelle gegen ein reales Ziel eingesetzt hat. Bei schwerwiegenden Vorfällen nach Artikel 14(3) und 14(4) gilt der Takt 24 Stunden, 72 Stunden und dann ein Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung. Die beiden Ströme teilen die frühen Phasen und divergieren beim Abschlussbericht. Beide dürfen nicht in ein einziges "24h/72h/14d"-Schema zusammengefasst werden. Siehe CRA Artikel-14-Meldung.
ENISA und als Koordinatoren benannte CSIRTs. Artikel 14(7) verlangt die Einreichung über die SRP unter Verwendung des elektronischen Endpunkts des CSIRT, das als Koordinator im Mitgliedstaat der Hauptniederlassung des Herstellers benannt ist. Erwägungsgrund 76 bildet den übergeordneten Rahmen: Hersteller können Meldungen direkt oder indirekt über ein nach Artikel 12(1) der Richtlinie (EU) 2022/2555 (NIS2) als Koordinator benanntes CSIRT entgegennehmen. Zur SRP-Onboarding-Mechanik siehe ENISA-SRP-Onboarding.
Forscherkoordination. Bietet ein Forscher ein Embargo an, während der Fix ausgeliefert wird, ist das vereinbarte Fenster zu dokumentieren und einzuhalten. Verweigert der Forscher das Embargo oder veröffentlicht frühzeitig, sollte die CVD-Richtlinie festlegen, wie der Hersteller reagiert, in der Regel durch Beschleunigung des Advisories und des Patches.
Zeitpunkt der öffentlichen Offenlegung
Die öffentliche Offenlegung einer behobenen Schwachstelle ist nach dem CRA nicht optional. Anhang I Teil II Buchstabe 4 verpflichtet Hersteller, "sobald ein Sicherheitsupdate verfügbar gemacht wurde", "Informationen über behobene Schwachstellen zu teilen und öffentlich bekannt zu machen, einschließlich einer Beschreibung der Schwachstellen, Informationen, die es den Nutzern ermöglichen, das betroffene Produkt mit digitalen Elementen zu identifizieren, die Auswirkungen der Schwachstellen, ihren Schweregrad sowie klare und zugängliche Informationen, die den Nutzern bei der Behebung helfen". Derselbe Buchstabe erlaubt eine Verzögerung "in hinreichend begründeten Fällen, in denen Hersteller der Auffassung sind, dass die Sicherheitsrisiken der Veröffentlichung die Sicherheitsvorteile überwiegen", jedoch "erst, nachdem den Nutzern die Möglichkeit gegeben wurde, den entsprechenden Patch anzuwenden".
Embargo-Fenster. Der De-facto-Branchenstandard sind 90 Tage von der Meldung bis zur öffentlichen Offenlegung, gemessen ab dem Datum, an dem der Hersteller erstmals benachrichtigt wurde. Project Zero, CERT/CC und die meisten nationalen CSIRTs arbeiten mit oder nahe diesem Richtwert. Bei aktiv ausgenutzten Schwachstellen kollabiert das Fenster typischerweise auf Tage, da Artikel 14(2)(c) einen Abschlussbericht innerhalb von 14 Tagen nach Verfügbarkeit einer Abhilfemaßnahme verlangt.
Format der öffentlichen Offenlegung. Ein CRA-konformes Advisory sollte mindestens eine CVE-ID, eine klare Beschreibung, betroffenes Produkt und Versionsrange, Schweregrad (CVSS-Basiswert), Auswirkung, Abhilfe und Anerkennung (sofern der Meldende einer Nennung zugestimmt hat) enthalten. CSAF (Common Security Advisory Framework) ist das maschinenlesbare Format, das die meisten nationalen CSIRTs und die ENISA-Schwachstellendatenbank erwarten.
Die "hinreichend begründete" Verzögerung in Buchstabe 4 ist eng gefasst. Sie erlaubt, öffentliche Details zurückzuhalten, bis Nutzer patchen können; sie erlaubt keine stillen Fixes, die nie veröffentlicht werden. Ein Hersteller, der einen Patch ausliefert und nie beschreibt, was er behoben hat, verstößt gegen Buchstabe 4, unabhängig von der Absicht.
Häufige Fehler
| Fehler | Warum er den CRA verletzt |
|---|---|
| Rechtliche Drohungen gegen gutgläubige Forscher | Verstößt gegen "eine Richtlinie zur koordinierten Offenlegung von Schwachstellen einzuführen und durchzusetzen" (Anhang I Teil II Buchstabe 5) und schreckt den Eingangskanal ab, den Buchstabe 6 verlangt. |
| Kein öffentlicher Kontaktkanal, nur ein internes Portal-Login | Verstößt gegen Artikel 13(17) "leicht identifizierbar" und Anhang I Teil II Buchstabe 6 "Bereitstellung einer Kontaktadresse". |
security-noreply@-Autoresponder ohne menschliche Triage |
Artikel 13(17) verbietet die Beschränkung der Kommunikation auf automatisierte Tools. |
| Eingang bestätigen und danach nie mehr antworten | Die Richtlinie ist "eingeführt", aber nicht "durchgesetzt". Anhang I Teil II Buchstabe 5 verlangt beides. |
| Meldungen als "wird nicht behoben" schließen ohne Begründung | Von außen nicht von Ignorieren zu unterscheiden; Forscher eskalieren durch Veröffentlichung. |
| Sicherheitsfixes in Feature-Releases bündeln, die Nutzer aufschieben | Verstößt gegen Anhang I Teil II Buchstabe 2: Sicherheitsupdates müssen von Funktionsupdates trennbar sein, "sofern technisch machbar". |
| Stilll patchen ohne Advisory | Verstößt gegen die öffentliche Offenlegungspflicht aus Anhang I Teil II Buchstabe 4. |
| CVD-Eingang als Artikel-14-ENISA-Einreichung behandeln | Verschiedene Adressaten, verschiedene Pflichten. CVD befreit nicht von Artikel 14, und Artikel 14 befreit nicht von CVD. |
Häufig gestellte Fragen
Benötigen kleine Hersteller eine CVD-Richtlinie nach dem CRA?
Ja. Die CVD-Richtlinienpflicht kennt keine Größenschwelle. Sie gilt für jeden Hersteller, der ein Produkt mit digitalen Elementen auf dem EU-Markt bereitstellt, unabhängig von Mitarbeiterzahl oder Umsatz. Kleinstunternehmen und Kleinunternehmen profitieren von einer engen Bußgeldentlastung bei den 24-Stunden-Frühwarnfristen nach Artikel 64(10)(a), die sowohl Artikel 14(2)(a) für aktiv ausgenutzte Schwachstellen als auch Artikel 14(4)(a) für schwerwiegende Vorfälle abdeckt. Diese Entlastung betrifft nur jene Bußgelder, nicht die zugrundeliegende Pflicht, und gilt nicht für mittlere Unternehmen. Ein zwei Personen starkes Unternehmen, das Firmware ausliefert, benötigt eine veröffentlichte CVD-Richtlinie, einen Kontaktkanal und einen Triage-Prozess genauso wie ein großer Anbieter. (Anhang I Teil II Nummer 5; Artikel 64(10)(a); Artikel 3(19).)
Ist `security.txt` nach dem CRA verpflichtend?
Nein. Der CRA nennt security.txt oder RFC 9116 nicht. Er schreibt einen "leicht identifizierbaren" einzigen Ansprechpartner und eine Kontaktadresse für Schwachstellenmeldungen vor. security.txt ist die De-facto-Konvention zur Erfüllung dieser Pflichten, weil es das ist, was automatisierte Scanner und die meisten Forscher zuerst prüfen; ein Kontakt, der prominent auf einer öffentlichen Sicherheitsseite und in den Anhang-II-Anweisungen veröffentlicht ist, ist aber ebenfalls konform. Die harte Anforderung ist ein veröffentlichter, funktionierender, menschlich erreichbarer Kanal; das Format ist eine Wahl. (Artikel 13(17); Anhang I Teil II Nummer 6; RFC 9116.)
Kann der CVD-Eingang denselben Kanal wie die ENISA-Artikel-14-Einreichung nutzen?
Nein. Es sind verschiedene Adressaten und verschiedene Pflichten. Der CVD-Eingang ist der Kanal, über den externe Forscher und Nutzer Schwachstellen an den Hersteller melden. Die Artikel-14-Einreichung ist die regulatorische Benachrichtigung des Herstellers an ENISA und das koordinierende CSIRT, die über die ENISA Single Reporting Platform erfolgt. Ein Forscher reicht nicht bei der SRP ein; der Hersteller tut es. Eine Verwechslung beider führt entweder dazu, einen Forscher nicht zu bestätigen (CVD-Verstoß) oder ENISA nicht zu benachrichtigen, wenn eine Ausnutzung bestätigt ist (Bußgeldrisiko der höchsten Stufe). (Artikel 14(1) und 14(7); Artikel 16; Artikel 64(2).)
Was passiert, wenn ein externer Forscher eine aktiv ausgenutzte Schwachstelle meldet?
Zwei Takte starten parallel. Der CVD-Prozess regelt die Forscherbeziehung: Eingang bestätigen, triagieren, ein Embargo vereinbaren, einen Fix ausliefern, ein Advisory veröffentlichen, den Meldenden anerkennen. Der Artikel-14-Prozess regelt die Regulatorbeziehung: eine 24-Stunden-Frühwarnung an ENISA und das koordinierende CSIRT, eine 72-Stunden-Meldung und ein Abschlussbericht innerhalb von 14 Tagen nach Verfügbarkeit einer Abhilfemaßnahme. Die 24-Stunden-Frist beginnt, wenn der Hersteller Kenntnis davon erlangt, dass eine Ausnutzung aktiv ist; das kann der Moment sein, in dem die Belege des Forschers diese Schlussfolgerung glaubwürdig machen. Auf forensische Gewissheit zu warten wird die Frist verpassen. Die beiden Prozesse laufen parallel und enden auf unterschiedlichen Oberflächen. (Artikel 14(1) und 14(2); Anhang I Teil II Nummer 5.)
Muss die CVD-Richtlinie Forschern einen rechtlichen Safe Harbour anbieten?
Nein, der CRA schreibt keine explizite Safe-Harbour-Klausel vor. Erwägungsgrund 76 beschreibt CVD als strukturierten Meldeprozess und nennt Bug-Bounty-Programme als Anreizmöglichkeit; er kodifiziert weder Safe Harbour noch rechtliche Entlastung für Forscher. Die Norm kommt aus der Branchenpraxis, nicht aus der Verordnung: ISO/IEC 29147, der ENISA-Leitfaden zur koordinierten Offenlegung von Schwachstellen und die meisten nationalen CSIRT-Empfehlungen konvergieren auf einer schriftlichen Safe-Harbour-Klausel für gutgläubige Forschung im veröffentlichten Geltungsbereich. Eine Richtlinie, die sich das Recht vorbehält, rechtliche Schritte gegen Forschung im Geltungsbereich einzuleiten, legt den Kanal still und verfehlt in der Praxis die "Durchsetzungs"-Hälfte von Anhang I Teil II Nummer 5. (Erwägungsgrund 76; ISO/IEC 29147; ENISA-Leitfaden zur koordinierten Offenlegung von Schwachstellen.)