Wer eine Schwachstelle in Ihrem Produkt findet, braucht einen klaren, menschlich erreichbaren Meldeweg, und Ihr Team braucht eine schriftliche Richtlinie dafür, wie eine solche Meldung bestätigt, triagiert, behoben und offengelegt wird. Nach dem EU Cyber Resilience Act (Verordnung (EU) 2024/2847) bedeutet das, eine Richtlinie zur koordinierten Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure, CVD) einzuführen und durchzusetzen sowie eine zentrale Anlaufstelle für Schwachstellenmeldungen zu veröffentlichen. Eine KMU-Ausnahme gibt es nicht. Diese Seite behandelt, was die Richtlinie enthalten muss, wie der Kontaktkanal zu veröffentlichen ist und wie CVD mit der Schwachstellenmeldung und dem übergeordneten Rahmen der Schwachstellenbehandlung zusammenwirkt.
Zusammenfassung
- Die CVD-Richtlinie ist Pflicht. Schriftlich, veröffentlicht, durchgesetzt, ohne Größenschwelle. Im Detail unter Was der CRA für CVD tatsächlich verlangt unten.
- Eine zentrale Anlaufstelle ist Pflicht. Nutzer müssen einen Menschen erreichen 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 dasselbe wie die ENISA-Meldung. CVD regelt Ihre Beziehung zum Meldenden; die regulatorische Frist gegenüber ENISA und dem koordinierenden CSIRT läuft parallel. Siehe Koordination mit ENISA unten.
- Die öffentliche Offenlegung behobener Schwachstellen ist Pflicht, mit einer engen Ausnahme für Verzögerungen, in denen das Sicherheitsrisiko der Veröffentlichung den Nutzen überwiegt, bis die Nutzer die Möglichkeit zum Einspielen des Patches hatten.
- Sanktionsdetails gehören in den Durchsetzungsleitfaden. Die Bußgeldstufen und Marktmaßnahmen stehen in Sanktionen und Durchsetzung.
Die vier Ankerpunkte einer CRA-konformen CVD-Postur: die Richtlinienpflicht, die Kontaktpflicht, die Veröffentlichungskonvention und der Verweis auf Durchsetzung.
Was der CRA für CVD tatsächlich verlangt
Die CVD-Pflicht ist kurz: Hersteller müssen "eine Strategie für die koordinierte Offenlegung von Schwachstellen aufstellen und umsetzen". Dieser einzelne Satz enthält vier operative Bestandteile, von denen jeder auf andere Weise versagt:
| Anforderung | Was das praktisch bedeutet | Typischer Fehler |
|---|---|---|
| AufstellenDokumentierte Richtlinie | Eine schriftliche, zugängliche Richtlinie liegt vor. Sie nennt Meldenden den Geltungsbereich, den Meldeweg, die zu erwartende Reaktion und den Zeitpunkt der Offenlegung. | Die undokumentierte interne Gewohnheit, security@-E-Mails zu triagieren, genügt nicht. |
| UmsetzenGelebter Prozess | Die Richtlinie wird betrieben, nicht nur veröffentlicht. Bestätigungsfristen, Triage-Zusagen und Offenlegungsbedingungen, die das Dokument nennt, werden in der Praxis eingehalten. | Eine Richtlinie, die eine 72-Stunden-Bestätigung verspricht, auf die routinemäßig drei Wochen folgen, wird nicht umgesetzt. |
| Meldungen erleichternZugänglicher Kanal | Die Richtlinie macht es externen Meldenden leicht, Schwachstelleninformationen zu teilen: eine Kontaktadresse, ein veröffentlichter Ablauf und ein menschlich erreichbarer Kanal, der nicht hinter einem Login oder Chatbot verborgen ist. | Ein Portal nur mit Login, ein rein automatisierter Eingang oder ein versteckter Kontaktpfad verfehlt die Richtung der Pflicht. |
| Meldende nicht sanktionierenNorm gutgläubiger Forschung | Steht so nicht wörtlich im CRA. Die Verordnung beschreibt CVD als strukturierten Meldeprozess und nennt Bug-Bounty-Programme als Anreiz zur Meldung. ISO/IEC 29147 und der ENISA-Leitfaden behandeln Safe Harbour für gutgläubige Forschung als übliches Element einer CVD-Richtlinie. | Sich rechtliche Schritte gegen gutgläubige Forschung im Geltungsbereich vorzubehalten, lässt den Meldekanal zusammenbrechen, selbst wenn eine Kontaktadresse besteht. |
Den übergeordneten Rahmen (die acht nummerierten Pflichten, von denen CVD eine ist) finden Sie unter Schwachstellenbehandlung.
Die zentrale Anlaufstelle
Die CVD-Richtlinie funktioniert nur, wenn Meldende einen echten Kontakt finden und einen menschlichen Weg in den Hersteller hinein haben. Die Pflicht zur zentralen Anlaufstelle wird im CRA zu drei konkreten Anforderungen:
- Leicht ermittelbar. Der Kontakt muss für Nutzer leicht auffindbar sein und in den dem Produkt beigefügten Nutzeranleitungen erscheinen. In der Praxis bedeutet das, ihn dort sichtbar zu machen, wo Nutzer suchen, etwa auf einer öffentlichen Sicherheits- oder Kontaktseite – nicht in einer Datenschutzerklärung zu vergraben.
- Mehrere Kanäle. "Ihr bevorzugtes Kommunikationsmittel wählen" bedeutet mindestens zwei. Ein funktionierendes
security@-Postfach sowie ein Webformular, ergänzt um einen PGP-Schlüssel für sensible Einreichungen, sind die realistische Mindestbasis. - Kein rein automatisierter Eingang. "Diese Mittel dürfen nicht auf automatisierte Tools beschränkt werden" 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 verlangt nicht, Verbrauchersupport und Schwachstelleneingang zu trennen, doch die meisten Hersteller betreiben ein dediziertes Sicherheitspostfach, das an das Produktsicherheitsteam weitergeleitet wird, um CVD von allgemeinem Support abzugrenzen.
Die CVD-Richtlinie veröffentlichen: security.txt und mehr
Der CRA nennt security.txt, RFC 9116 oder ein bestimmtes Veröffentlichungsformat nicht. Er verlangt einen Kontaktkanal, der "leicht ermittelbar" ist, und eine CVD-Richtlinie, die "aufgestellt und umgesetzt" 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 Forschende 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. |
Wo hosten. Der übliche Ablageort ist https://example.com/.well-known/security.txt, ausgeliefert über HTTPS. RFC 9116 akzeptiert auch https://example.com/security.txt als Fallback, doch der well-known-Pfad ist vorzuziehen.
Über security.txt hinaus. Der Maßstab "leicht ermittelbar" bedeutet, dass der Kontakt zusätzlich auf der Produkt-Support- oder Kontaktseite, in den dem Produkt beigefügten Nutzeranleitungen, in der Entwicklerdokumentation für API-Produkte sowie auf einer öffentlichen CVD-Richtlinienseite erscheinen sollte, auf die Forschende verlinken können.
Hersteller, die Bug-Bounty-Programme betreiben, ergänzen den Eingang üblicherweise um HackerOne, Bugcrowd oder Intigriti. Diese erfüllen die Pflicht "Meldungen erleichtern" und die Pflicht "nicht auf automatisierte Tools beschränkt" nur, 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 Eingangs- und Triage-Workflow umgesetzt. Die nachfolgenden Mechanismen sind nicht vom CRA vorgeschrieben, sie zeigen aber, wie eine durchsetzbare Richtlinie in der Praxis aussieht.
| Phase | Was eine durchsetzbare Richtlinie tut | Typischer Fehler |
|---|---|---|
| Bestätigung | Eingang innerhalb der veröffentlichten SLA bestätigen. Branchenübliche Basis sind 72 Stunden; viele Richtlinien sagen 24 oder 48 Stunden für hochgradige Meldungen zu. Was Sie veröffentlichen, halten Sie ein. | "Wir antworten zeitnah" ist von Grund auf 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 Belege aus der Praxis, was die regulatorische Eskalation auslöst) und den Geltungsbereich über die SBOM auf betroffene Versionen eingrenzen. | Schließen als "nicht reproduzierbar" ohne Angabe der getesteten Versionsrange. |
| Beziehung zu Forschenden | 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, Nennung). Typisches Embargo: bis der Patch ausgeliefert ist, mit hartem Backstop von 90 Tagen. | Sich rechtliche Schritte gegen gutgläubige Forschung im Geltungsbereich vorzubehalten, was den Kanal zum Erliegen bringt. |
| Den Kreis schließ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 umgesetzt wirken. |
Koordination mit ENISA und externen Forschenden
CVD-Eingang und ENISA-Meldung sind unterschiedliche Pflichten mit unterschiedlichen Adressaten. Die CVD-Richtlinie regelt die Beziehung zum Meldenden. Die regulatorische Meldung regelt die Pflicht gegenüber ENISA und dem koordinierenden CSIRT. Sie laufen parallel und werden durch verschiedene Ereignisse ausgelöst.
Wenn eine CVD-Meldung zum regulatorischen Auslöser wird. Hersteller müssen "jede aktiv ausgenutzte Schwachstelle" über die SRP melden, mit einem Takt von 24 Stunden, 72 Stunden und 14 Tagen. Der Auslöser ist "aktiv ausgenutzt", nicht "gemeldet". Ein CVD-Eingang mit einem funktionierenden Proof-of-Concept ist für sich allein noch kein regulatorischer Auslöser; er wird zum Auslöser, sobald verlässliche Nachweise vorliegen, dass ein böswilliger Akteur die Schwachstelle ohne Zustimmung des Systemeigners in einem System ausgenutzt hat.
Bei schwerwiegenden Vorfällen gilt ein anderer Takt: 24 Stunden, 72 Stunden und dann ein Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung. Die beiden Ströme teilen sich die frühen Phasen und divergieren beim Abschlussbericht. Fassen Sie sie nicht zu einem einzigen "24h/72h/14d"-Schema zusammen. Siehe Schwachstellenmeldung.
ENISA und als Koordinatoren benannte CSIRTs. Die Einreichung erfolgt über die SRP unter Verwendung des elektronischen Endpunkts des CSIRT, das im Mitgliedstaat der Hauptniederlassung des Herstellers als Koordinator benannt ist. Hersteller können Meldungen direkt oder indirekt über ein nach der NIS2-Richtlinie als Koordinator benanntes CSIRT entgegennehmen. Zur SRP-Onboarding-Mechanik siehe ENISA-SRP-Onboarding.
Koordination mit Forschenden. Bietet ein Forschender ein Embargo an, während Sie einen Fix ausliefern, dokumentieren Sie das vereinbarte Fenster und halten Sie es ein. Verweigert der Forschende das Embargo oder veröffentlicht frühzeitig, sollte Ihre CVD-Richtlinie regeln, wie Sie reagieren, in der Regel durch Beschleunigung von Advisory und Patch.
Zeitpunkt der öffentlichen Offenlegung
Die öffentliche Offenlegung einer behobenen Schwachstelle ist nach dem CRA nicht optional. Sobald eine Sicherheitsaktualisierung bereitgestellt wurde, müssen Hersteller eine Beschreibung der Schwachstelle, Informationen zur Identifizierung des betroffenen Produkts, die Auswirkungen, den Schweregrad sowie klare Hinweise zur Behebung teilen und öffentlich bekannt machen. Eine Verzögerung ist "in hinreichend begründeten Fällen" erlaubt, in denen die Sicherheitsrisiken der Veröffentlichung den Nutzen überwiegen, aber nur "bis den Nutzern die Möglichkeit gegeben wurde, den entsprechenden Patch anzuwenden".
Embargo-Fenster. Der De-facto-Branchenstandard liegt bei 90 Tagen von der Meldung bis zur öffentlichen Offenlegung, gerechnet ab dem Tag der ersten Benachrichtigung des Herstellers. Project Zero, CERT/CC und die meisten nationalen CSIRTs arbeiten auf oder nahe diesem Richtwert. Bei aktiv ausgenutzten Schwachstellen kollabiert das Fenster typischerweise auf Tage, da der regulatorische Abschlussbericht innerhalb von 14 Tagen nach Verfügbarkeit einer Abhilfemaßnahme fällig ist.
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 sowie Nennung enthalten, sofern der Meldende einer Nennung zugestimmt hat. 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 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, verletzt die öffentliche Offenlegungspflicht unabhängig von der Absicht.
Häufige Fallstricke
| Fallstrick | Warum er den CRA verletzt |
|---|---|
| Rechtliche Drohungen gegen gutgläubige Forschende | Verstößt gegen die Pflicht, "eine Strategie für die koordinierte Offenlegung von Schwachstellen aufzustellen und umzusetzen", und schreckt den Eingangskanal ab, den die Pflicht verlangt. |
| Kein öffentlicher Kontaktkanal, nur ein internes Portal-Login | Verfehlt die leicht ermittelbare Kontaktstelle und die Pflicht zur Bereitstellung einer Kontaktadresse. |
security-noreply@-Autoresponder ohne menschliche Triage |
Die zentrale Anlaufstelle darf die Kommunikation nicht auf automatisierte Tools beschränken. |
| Eingang bestätigen und danach nie wieder antworten | Die Richtlinie ist aufgestellt, aber nicht umgesetzt; beides ist Pflicht. |
| Meldungen als "wird nicht behoben" schließen ohne Begründung | Von außen nicht von Ignorieren zu unterscheiden; Forschende eskalieren durch Veröffentlichung. |
| Sicherheitsfixes in Feature-Releases bündeln, die Nutzer aufschieben | Sicherheitsaktualisierungen müssen soweit technisch machbar getrennt von Funktionsaktualisierungen bereitgestellt werden. |
| Still patchen ohne Advisory | Verstößt gegen die öffentliche Offenlegungspflicht. |
| CVD-Eingang als ENISA-Einreichung behandeln | Verschiedene Adressaten, verschiedene Pflichten. CVD befreit nicht von der regulatorischen Meldung, und die regulatorische Meldung befreit nicht von CVD. |
Häufig gestellte Fragen
Brauchen kleine Hersteller nach dem CRA eine CVD-Richtlinie?
Ja. Die Pflicht zur CVD-Richtlinie kennt keine Größenschwelle. Sie gilt für jeden Hersteller, der ein Produkt mit digitalen Elementen auf dem EU-Markt in Verkehr bringt, unabhängig von Mitarbeiterzahl oder Umsatz. Kleinstunternehmen und Kleinunternehmen profitieren von einer engen Bußgeldentlastung bei den 24-Stunden-Frühwarnfristen, doch diese Entlastung betrifft nur [jene Bußgelder](/cra-compliance/penalties-and-enforcement), nicht die zugrundeliegende Pflicht, und sie gilt nicht für mittlere Unternehmen. Ein zwei Personen starker Firmware-Anbieter braucht genauso eine veröffentlichte CVD-Richtlinie, einen Kontaktkanal und einen Triage-Prozess wie ein großer Anbieter.
Ist `security.txt` nach dem CRA verpflichtend?
Nein. Der CRA nennt security.txt oder RFC 9116 nicht. Er verlangt eine "leicht ermittelbare" zentrale Anlaufstelle und eine Kontaktadresse für Schwachstellenmeldungen. security.txt ist die De-facto-Konvention zur Erfüllung dieser Pflichten, weil automatisierte Scanner und die meisten Forschenden zuerst dort nachsehen, aber ein Kontakt, der prominent auf einer öffentlichen Sicherheitsseite und in den dem Produkt beigefügten Nutzeranleitungen veröffentlicht ist, ist ebenfalls konform. Die harte Anforderung ist ein veröffentlichter, funktionierender, menschlich erreichbarer Kanal; das Format ist eine Wahl.
Kann der CVD-Eingang derselbe Kanal wie die ENISA-Einreichung sein?
Nein. Es sind verschiedene Adressaten und verschiedene Pflichten. Der CVD-Eingang ist der Kanal, über den externe Forschende und Nutzer Schwachstellen an den Hersteller melden. Die ENISA-Einreichung ist die regulatorische Meldung des Herstellers an ENISA und das koordinierende CSIRT, die über die einheitliche Meldeplattform (SRP) erfolgt. Forschende reichen nicht bei der SRP ein; der Hersteller tut es. Eine Vermischung beider führt entweder dazu, dass ein Forschender nicht bestätigt wird (CVD-Verstoß), oder dass ENISA bei bestätigter Ausnutzung nicht benachrichtigt wird (erhebliches Durchsetzungsrisiko).
Was passiert, wenn ein externer Forschender eine aktiv ausgenutzte Schwachstelle meldet?
Zwei Takte starten parallel. Der CVD-Prozess regelt die Beziehung zum Forschenden: Eingang bestätigen, triagieren, ein Embargo vereinbaren, einen Fix ausliefern, ein Advisory veröffentlichen, den Meldenden nennen. Der regulatorische Prozess regelt die Beziehung zu ENISA und dem koordinierenden CSIRT: eine 24-Stunden-Frühwarnung, eine 72-Stunden-Meldung und ein Abschlussbericht innerhalb von 14 Tagen nach Verfügbarkeit einer Abhilfemaßnahme. Die 24-Stunden-Frist beginnt, sobald der Hersteller davon Kenntnis erlangt, dass eine Ausnutzung aktiv ist, was der Moment sein kann, in dem die Belege des Forschenden diese Schlussfolgerung glaubwürdig machen. Wer auf forensische Gewissheit wartet, verpasst die Frist. Die beiden Prozesse laufen parallel und enden auf unterschiedlichen Oberflächen.
Muss die CVD-Richtlinie Forschenden einen rechtlichen Safe Harbour bieten?
Nein, der CRA verlangt keine ausdrückliche Safe-Harbour-Klausel. Der CRA beschreibt CVD als strukturierten Meldeprozess und nennt Bug-Bounty-Programme als Anreiz zur Meldung; er kodifiziert weder Safe Harbour noch eine rechtliche Entlastung für Forschende. Die Norm stammt aus der Branchenpraxis und nicht aus der Verordnung: ISO/IEC 29147, der ENISA-Leitfaden 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 rechtliche Schritte gegen Forschung im Geltungsbereich vorbehält, legt den Kanal still und verfehlt in der Praxis die "Umsetzen"-Hälfte der CVD-Pflicht.