CVD-Policy unter dem CRA: So baust du eine echte Vulnerability Disclosure Policy auf

Viele Hersteller von Produkten mit digitalen Elementen haben weder eine CVD-Policy noch einen funktionierenden internen Prozess dahinter. Coordinated Vulnerability Disclosure, kurz CVD, ist dabei mehr als eine regulatorische Pflicht. Eine Vulnerability Disclosure Policy ist das Signal an die Sicherheitsforschercommunity, dass gemeldete Schwachstellen ernst genommen und strukturiert bearbeitet werden. Wer keine Policy hat, signalisiert das Gegenteil, und viele Forscher verzichten dann auf die Meldung ganz oder veröffentlichen sofort.

Dieser Artikel behandelt Annex I Part II Req. 5 und 6 des CRA, also die Anforderungen an CVD-Policy und Kontaktstelle für Schwachstellenmeldungen. Die ausgehenden Meldepflichten nach Art. 14 sind ein anderes Thema; wer dazu mehr wissen will, schaut in unseren Artikel CRA Meldepflichten. Als Grundlage empfiehlt sich außerdem unser Überblick über alle acht Annex-I-Part-II-Anforderungen im Artikel Schwachstellenbehandlung nach Annex I Part II.

Was ist Coordinated Vulnerability Disclosure?

CVD (Coordinated Vulnerability Disclosure) beschreibt einen Prozess, bei dem ein Sicherheitsforscher eine entdeckte Schwachstelle zunächst dem Hersteller meldet, bevor sie öffentlich bekannt gemacht wird. Dem Hersteller wird damit Zeit gegeben, einen Patch zu entwickeln und bereitzustellen, bevor Angreifer die Lücke ausnutzen können. Das klingt selbstverständlich, war aber nicht immer Standard. Jahrzehntelang standen sich Full Disclosure (sofortige Veröffentlichung ohne Vorwarnung) und No Disclosure (Totschweigen durch den Hersteller) als konkurrierende Ansätze gegenüber. Das CERT/CC der Carnegie Mellon University etablierte Mitte der 1980er-Jahre einen dritten Weg, den koordinierten Ansatz. Der Begriff Responsible Disclosure wurde später zu Coordinated Vulnerability Disclosure umbenannt, weil die Verantwortung auf beiden Seiten liegt, beim Melder und beim Hersteller.

Den internationalen Rahmen für CVD bilden zwei ISO-Standards. ISO/IEC 29147:2018 definiert, wie Hersteller Schwachstellenmeldungen entgegennehmen und kommunizieren, also die externe Sicht auf Policy und Kommunikation. ISO/IEC 30111:2019 beschreibt den internen Umgang mit Schwachstellen. Die Norm deckt Empfang, Triage, Analyse, Remediation und Disclosure ab und definiert Rollen, Verantwortlichkeiten und Eskalationspfade. Beide zusammen bilden einen etablierten CVD-Rahmen. Die BSI TR-03183-3: Vulnerability Reports and Notifications in Version 1.0.0 beschreibt den Umgang mit eingehenden Schwachstellenmeldungen und Benachrichtigungen und bietet dafür eine aktuelle technische Orientierung.

Eine wichtige Abgrenzung: CVD ist kein Bug Bounty. Weder verlangt CVD eine monetäre Entlohnung, noch setzt es ein professionelles Bug-Bounty-Programm voraus. Für eine forschungsfreundliche CVD-Policy ist rechtlicher Schutz für den Melder, der sogenannte Safe Harbor, empfehlenswert. Gemeint ist eine klare Zusicherung, dass der Forscher keine rechtlichen Konsequenzen fürchten muss, solange er sich an die Policy hält. Fehlt eine solche Zusicherung, kann das die Bereitschaft zur Meldung von Schwachstellen erheblich reduzieren.

Was der CRA konkret fordert

Die relevanten Anforderungen stecken in Annex I Part II des Cyber Resilience Act (EU) 2024/2847. Anforderung 5 verlangt von Herstellern, eine Strategie zur koordinierten Offenlegung von Schwachstellen aufzustellen und umzusetzen. Anforderung 6 verlangt Maßnahmen, die den Austausch von Informationen über mögliche Schwachstellen erleichtern, darunter eine Kontaktadresse für Schwachstellenmeldungen. Ergänzend muss nach Annex II Nr. 2 in den Nutzerinformationen die zentrale Kontaktstelle angegeben werden. Dort muss außerdem erkennbar sein, wo die CVD-Policy des Herstellers zu finden ist.

Die Herstellerpflichten zum Vulnerability Handling ergeben sich insbesondere aus Art. 13 Abs. 8 CRA. Art. 13 Abs. 6 betrifft dagegen einen anderen Fall, nämlich Schwachstellen in integrierten Komponenten und die Information des Herstellers oder Maintainers dieser Komponenten.

Diese allgemeinen Anforderungen gelten grundsätzlich mit der allgemeinen Anwendbarkeit des CRA ab dem 11. Dezember 2027. Ab dem 11. September 2026 gilt zunächst Art. 14 CRA. Danach müssen Hersteller insbesondere aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle über die einheitliche Meldeplattform an das zuständige koordinierende CSIRT und ENISA melden.

Für eine belastbare praktische Umsetzung sollten vorbereitet werden:

• Eine öffentlich zugängliche CVD-Policy (als URL, kein internes Dokument)
• Eine dedizierte Kontaktadresse (z.B. security@company.com)
• Ein klarer interner Prozess, wie mit eingehenden Meldungen umgegangen wird

Eine häufige Verwechslung in der Praxis ist die Gleichsetzung dieser Anforderungen mit den Meldepflichten nach Art. 14. Der Unterschied ist strukturell. Art. 14 regelt ausgehende Meldungen, wenn ein Hersteller Kenntnis von einer aktiv ausgenutzten Schwachstelle erlangt (Hersteller → koordinierendes CSIRT und ENISA). Annex I Req. 5 und 6 regeln eingehende Meldungen, wenn Dritte dem Hersteller eine Schwachstelle melden (Forscher/Kunde → Hersteller). Rechtlich sind CVD-Policy und Kontaktstelle damit nicht bereits ab September 2026 aufgrund von Annex I Req. 5 und 6 verpflichtend. Operativ hängen die Themen dennoch eng zusammen: Hersteller können auf Hinweise zu einer aktiven Ausnutzung nur reagieren, wenn relevante Informationen sie zuverlässig erreichen und intern bewertet werden. Eine erreichbare Meldestelle und ein definierter CVD-Prozess sind deshalb wichtige Vorbereitungen auf die Meldepflichten ab September 2026.

CVD-Policy und CVD-Prozess

Viele Hersteller verwechseln die Policy mit dem Prozess. Beide sind notwendig, aber sie richten sich an verschiedene Zielgruppen und folgen verschiedenen ISO-Standards.

Hersteller, die nur eine Policy schreiben aber keinen internen Prozess haben, werden beim ersten echten Fall scheitern. Umgekehrt nützt ein perfekter interner Prozess nichts, wenn niemand von außen weiß, wie er eine Schwachstelle melden soll. Beide Artefakte sollten voneinander referenzieren. Die Policy nennt Reaktionszeiten, die intern als verbindliche Service Levels umgesetzt sind.

Eine CVD-Policy aufbauen

Der CRA schreibt die folgende Ausgestaltung nicht im Detail vor. Die genannten Bestandteile sind Praxisempfehlungen auf Grundlage etablierter CVD-Standards und Erfahrungen.

Eine praxistaugliche CVD-Policy braucht mindestens diese sieben Bestandteile:

1. Scope: Welche Produkte, Versionen und Systeme sind abgedeckt? Was ist explizit out-of-scope (z.B. EOL-Versionen, Drittprodukte, gehostete Dienste)?
2. Meldewege: Wie kann eine Schwachstelle gemeldet werden (E-Mail, Webformular, Bug-Bounty-Plattform)?
3. Verschlüsselung: Ein PGP-Public-Key für vertrauliche Kommunikation, referenziert in der Policy und in security.txt
4. Reaktionszeiten: Klare Zusagen, z.B. Eingangsbestätigung innerhalb von 5 Werktagen, Status-Update alle 30 Tage
5. Disclosure-Timeline: Wann wird die Schwachstelle veröffentlicht? Der etablierte Orientierungswert liegt bei 90 Tagen nach Erstkontakt, angelehnt an CERT/CC und Google Project Zero
6. Safe Harbor: Die Zusicherung, dass Melder keine rechtlichen Konsequenzen fürchten müssen, solange sie im Rahmen der Policy und in gutem Glauben handeln
7. Anerkennung: Optional, aber empfehlenswert. Eine Hall of Fame oder namentliche Erwähnung bei behobenen Schwachstellen ist ein gutes Zeichen, setzt aber voraus, dass die meldende Person vorab GDPR-konform zugestimmt hat

Den Einstieg erleichtert der Disclose.io PolicyMaker, ein kostenloser Policy Builder, der alle oben genannten Bestandteile von Scope über Safe Harbor bis zur Disclosure-Timeline als konfigurierbaren Baukasten zusammenstellt. Er generiert auch eine fertige security.txt.

security.txt ist nicht ausdrücklich durch den CRA vorgeschrieben. Als maschinenlesbarer und standardisierter Weg zur Auffindbarkeit einer Meldestelle ist die Datei nach RFC 9116 dennoch eine sinnvolle praktische Ergänzung. Die Datei gehört unter /.well-known/security.txt und enthält zwei Pflichtfelder (Contact: und Expires:) sowie optionale Felder für Verschlüsselung, Policy-Link und bevorzugte Sprachen. Wer nur die security.txt ohne eine vollständige Policy aufsetzen möchte, kann den securitytxt.org Generator nutzen, der die Datei korrekt erstellt und validiert.

# security.txt nach RFC 9116

# Pflichtfelder
Contact: mailto:security@example.com
Expires: 2027-05-19T00:00:00.000Z

# Optionale Felder (empfohlen)
Encryption: https://example.com/pgp-key.asc
Policy: https://example.com/security/vulnerability-disclosure-policy
Acknowledgments: https://example.com/security/hall-of-fame
Preferred-Languages: de, en

Das Beispiel nutzt Platzhalter-Domains. In der Praxis müssen URL, Ablaufdatum und PGP-Schlüssel zu eurer echten Meldestelle und eurem Wartungsprozess passen.

Der PGP-Schlüssel muss aktiv gepflegt werden. Ein abgelaufener oder verlorener Schlüssel macht verschlüsselte Kommunikation unmöglich und signalisiert dem Forscher, dass die Policy nicht ernsthaft betrieben wird. Kläre intern, wer den Schlüssel verwaltet und wer im Vertretungsfall Zugriff hat.

Von der Meldung zum Fix

Eine eingehende Schwachstellenmeldung durchläuft typischerweise fünf Phasen, alle in ISO/IEC 30111 beschrieben:

Eine wichtige Querschnittsfrage betrifft die Abgrenzung zu Art. 14. Eine eingehende CVD-Meldung löst die 24h-Frist nach Art. 14 nicht automatisch aus. Bei einer Schwachstelle entsteht die Meldepflicht, wenn der Hersteller von ihrer aktiven Ausnutzung Kenntnis erlangt. Wer im CVD-Prozess erkennt, dass eine gemeldete Schwachstelle bereits aktiv ausgenutzt wird, wechselt sofort in den Art.-14-Eskalationspfad. Die Meldung erfolgt über die einheitliche Meldeplattform an das zuständige koordinierende CSIRT und ENISA.

ISO/IEC 30111 behandelt Eskalation als risikobasierte Prozesssteuerung. Die Norm legt fest, wann Entwicklung, Legal oder Management einzubinden sind, wie mit Fristen und erhöhtem Risiko umgegangen wird und wann externe Koordinatoren hinzugezogen werden müssen. Unter dem CRA kommen vier Eskalationsdimensionen zusammen, nämlich technische, organisatorische, regulatorische und kommunikative. Viele Hersteller kombinieren ISO/IEC 30111 deshalb mit dem FIRST PSIRT Framework und der BSI TR-03183-3 in Version 1.0.0 zu einem strukturierten Vulnerability-Management-Modell.

Für europäische Hersteller ist heute ENISA als CVE Root der passendere Referenzpunkt als ein reiner Verweis auf MITRE (die gemeinnützige US-Organisation, die das CVE-Programm 1999 begründet hat und bis heute als Root CNA betreibt). Die eigentliche CVE-Vergabe erfolgt weiterhin über zuständige CVE Numbering Authorities (CNAs), aber ENISA baut die europäische Rolle im Schwachstellenmanagement und die Verzahnung mit EUVD gezielt aus. Die Schwere einer Schwachstelle wird nach dem aktuellen CVSS v4.0 Standard bewertet. Hersteller mit größerem Produktportfolio profitieren davon, sich selbst als CNA zu registrieren, da das die CVE-Vergabe deutlich beschleunigen kann.

Multi-Vendor CVD

Nicht jede Schwachstelle betrifft nur einen Hersteller. Wenn eine Lücke in einer weit verbreiteten Open-Source-Bibliothek oder einem gemeinsam genutzten Protokoll-Stack steckt, sind oft Dutzende Hersteller gleichzeitig betroffen. Log4Shell ist das bekannteste Beispiel. Es gab keinen koordinierten Disclosure-Zeitpunkt, und Patch-Chaos entstand, weil verschiedene Hersteller in verschiedenen Zyklen reagiert haben.

In solchen Szenarien übernimmt ein Koordinator die Rolle des neutralen Vermittlers. ENISA kann auf EU-Ebene Koordinationsaufgaben übernehmen, besonders bei EU-übergreifenden Vorfällen. Für Hersteller im deutschsprachigen Raum kann CERT@VDE der naheliegendere Ansprechpartner sein, wenn mehrere Hersteller koordiniert werden müssen. Für internationale Fälle bleibt CERT/CC mit der VINCE-Plattform ein relevanter Koordinator. Hersteller sollten in ihrer CVD-Policy festhalten, wie sie in Multi-Vendor-Szenarien vorgehen, wann sie externe Koordinatoren einschalten und wer intern die Koordinationsrolle übernimmt.

Typische Fehler beim CVD-Aufbau

Die häufigsten Fehler sind vorhersehbar:

1. Keine öffentliche Policy: Forscher wissen nicht, ob sie melden dürfen, viele verzichten ganz.
2. Keine dedizierte Kontaktadresse: Die Meldung landet im allgemeinen Postfach und geht unter.
3. Kein Safe Harbor: Forscher fürchten rechtliche Konsequenzen und meiden den Hersteller bewusst.
4. Fehlende oder unrealistische Reaktionszeiten: Wer den Melder nicht über den Fortschritt informiert, riskiert eine vorzeitige Veröffentlichung.
5. Policy vorhanden, Prozess nicht: Bei der ersten echten Meldung entsteht internes Chaos, weil Zuständigkeiten und Abläufe unklar sind.
6. PGP-Schlüssel abgelaufen oder verloren: Forscher können nicht verschlüsselt kommunizieren, was Vertrauen kostet.
7. security.txt ohne Expires: oder mit abgelaufenem Datum: RFC 9116 erklärt eine solche Datei als ungültig.
8. Scope unklar definiert: Wenn Hersteller eine Meldung als out-of-scope ablehnen, die der Forscher für in-scope hielt, entsteht Konflikt. Klare Scope-Definition schützt beide Seiten.
9. Policy behandelt nur externe Melder: Intern entdeckte Schwachstellen durchlaufen denselben CVD-Prozess, was in der Policy explizit benannt sein sollte.
10. Policy wird nie aktualisiert: Produkte, Kontakte und Timelines ändern sich. Eine veraltete Policy signalisiert mangelnde Ernsthaftigkeit.

Die ENISA Vulnerability Disclosure Guidelines und der Disclose.io PolicyMaker liefern Vorlagen und Textbausteine, mit denen sich viele dieser Fehler von Anfang an vermeiden lassen.

Jetzt anfangen, bevor der erste Forscher anklopft

CVD-Policy und CVD-Prozess sind zwei verschiedene Artefakte. Die entsprechenden CRA-Anforderungen gelten grundsätzlich ab dem 11. Dezember 2027. Für die Meldepflichten ab September 2026 bilden sie jedoch schon vorher eine wichtige operative Grundlage. Eine Policy ohne Prozess ist ein leeres Versprechen; ein Prozess ohne Policy ist von außen unsichtbar. Wer jetzt anfängt, hat die Zeit für einen geordneten Aufbau und kann vor dem Stichtag einen Trockenlauf durchführen.

Die vier wichtigsten Schritte zum Aufbau:

1. CVD-Policy schreiben und veröffentlichen (Scope, Kontakt, Safe Harbor, Disclosure-Timeline)
2. security.txt anlegen, validieren und in den Deployment-Prozess integrieren, damit sie nicht veraltet
3. Internen CVD-Prozess definieren, einschließlich Triage, Analyse, Fix, Disclosure und Eskalation nach Art. 14
4. Trockenlauf durchführen und dabei eine fiktive Meldung durch den gesamten Prozess führen, um Lücken zu dokumentieren

Alle acht Annex-I-Part-II-Anforderungen im Überblick findest du im Artikel Schwachstellenbehandlung nach Annex I Part II. Wie weit dein Unternehmen beim Secure Development Lifecycle insgesamt steht, zeigt unser Lunaris SDL-Assessment.

Wie gehst du mit dem Thema CVD in deinem Unternehmen um? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.

Dieser Artikel wurde am 24. August 2026 überarbeitet.