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 den vollständigen CVD-Rahmen. Die BSI TR-03183 empfiehlt beide Standards explizit als Grundlage für EU-Hersteller.

Eine wichtige Abgrenzung: CVD ist kein Bug Bounty. Weder verlangt CVD eine monetäre Entlohnung, noch setzt es ein professionelles Bug-Bounty-Programm voraus. Was es braucht, ist rechtlicher Schutz für den Melder, der sogenannte Safe Harbor. Eine klare Zusicherung, dass der Forscher keine rechtlichen Konsequenzen fürchten muss, solange er sich an die Policy hält. Ohne Safe Harbor melden Sicherheitsforscher nicht, und das schadet am Ende dem Hersteller.

Was der CRA konkret fordert

Die relevanten Anforderungen stecken in Annex I Part II des Cyber Resilience Act (EU) 2024/2847. Anforderung 5 verpflichtet Hersteller, eine Strategie zur koordinierten Offenlegung von Schwachstellen aufzustellen und zu veröffentlichen. Anforderung 6 verlangt eine erreichbare Kontaktstelle, über die Dritte Schwachstellen melden können. Gesetzliche Grundlage dafür ist Art. 13 Abs. 6 CRA. Beide Anforderungen sind verpflichtend ab dem 11. September 2026.

Konkret muss vorhanden sein:

• 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 → ENISA). Annex I Req. 5 und 6 regeln eingehende Meldungen, wenn Dritte dem Hersteller eine Schwachstelle melden (Forscher/Kunde → Hersteller). Beide gelten ab September 2026, erfordern aber unterschiedliche Artefakte und Prozesse.

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

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.

Neben der Policy selbst ist security.txt nach RFC 9116 das Minimum an maschinenlesbarer Auffindbarkeit. 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. Die Meldepflicht an ENISA greift erst, wenn die Schwachstelle aktiv ausgenutzt wird. Wer im CVD-Prozess erkennt, dass eine gemeldete Schwachstelle bereits in freier Wildbahn ausgenutzt wird, wechselt sofort in den Art.-14-Eskalationspfad.

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 30111 deshalb mit dem FIRST PSIRT Framework und BSI TR-03183 zu einem vollständigen 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, und beide sind ab dem 11. September 2026 verpflichtend. 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.