CVD-Richtlinie: was hineingehört
Die Richtlinie zur koordinierten Offenlegung (englisch Coordinated Vulnerability Disclosure Policy) sagt Meldenden, was sie erwarten dürfen und was Sie von ihnen erwarten. Auf sie zeigt das Feld Policy in der security.txt. Die BSI TR-03183-3 legt in Abschnitt 4.4 die Mindestinhalte fest.
Wozu die Richtlinie?
Wer eine Lücke findet, will wissen, ob eine Meldung sicher ist: ob er eine Anzeige riskiert, ob jemand antwortet und wann die Lücke öffentlich wird. Eine klare Richtlinie beantwortet das vorab. Das senkt die Hürde für eine saubere Meldung und verhindert, dass Lücken ungefragt veröffentlicht werden.
Nach der TR ist die Richtlinie Pflicht (4.4, 4.5.2) und braucht eine eigene Webseite, die ohne JavaScript und ohne Anmeldung erreichbar ist (4.5.2); die security.txt verweist im Feld Policy darauf (4.2.7). Für Hersteller unter dem Cyber Resilience Act (CRA) verlangt die Verordnung ab dem 11. Dezember 2027 eine Strategie zur koordinierten Offenlegung (Anhang I Teil II Nummer 5). Was die Richtlinie dafür enthalten muss, erklärt der Leitfaden CVD-Richtlinie nach dem CRA.
Checkliste nach TR-03183-3 Abschnitt 4.4
| Inhalt | Stufe | TR |
|---|---|---|
| Datum der letzten Änderung sichtbar, Richtlinie eindeutig dem Hersteller zuzuordnen, jährlich geprüft | Pflicht | 4.4.1 |
| Bei aktiv ausgenutzten Schwachstellen unverzüglich das nationale CSIRT informieren (in Deutschland CERT-Bund) | Pflicht | 4.4.2 |
| Funktionspostfächer von PSIRT und CSIRT mit Schlüsseln und Fingerabdrücken | Pflicht | 4.4.3 |
| Vertraulichkeit, keine Weitergabe personenbezogener Daten ohne Zustimmung, keine Strafanzeige bei Einhaltung, keine Verschwiegenheitserklärung, Antwort in den zugesagten Fristen, Ansprechbarkeit während des ganzen Verfahrens, Empfehlung verschlüsselter und signierter Mail | Pflicht | 4.4.4 |
| Nennung in einer Hall of Fame auf Wunsch | Soll | 4.4.4 f |
| Was als gültige Schwachstelle gilt | Pflicht | 4.4.5 |
| Verhaltensregeln für Meldende und Folgen bei Verstoß; Meldungen werden trotzdem bearbeitet | optional (wenn vorhanden: Bearbeitung trotz Verstoß Pflicht) | 4.4.6 |
| E-Mail und Telefon als Kontakt der Meldenden akzeptieren; keine Meldung von einer Person allein schließen | Pflicht | 4.4.7 |
| Persönliche Antwort binnen 5 Werktagen, ausführliche Rückmeldung binnen 10 Werktagen | Pflicht | 4.4.8 |
| Leicht auffindbare anonyme Meldemöglichkeit mit Hinweis auf eingeschränkte Bearbeitung | Pflicht | 4.4.9 |
| Veröffentlichung bestätigter Schwachstellen binnen 90 Tagen, mindestens in der EUVD der ENISA | Pflicht | 4.4.10 |
| Bedingungen für den Abschluss des Verfahrens | Pflicht | 4.4.11 |
Die TR empfiehlt außerdem ein Belohnungsprogramm (Bug-Bounty). Ob Sie eins anbieten, können Sie seit März 2026 auch in der security.txt mit dem Feld Bug-Bounty sagen. Wer keins anbietet, schreibt das ausdrücklich in die Richtlinie; das ist das einfachste Mittel gegen Beg-Bounty-Mails.
Der Entwurf aus dem Generator
Unter dem Generator erzeugen Sie einen Entwurf als Markdown-Datei mit allen Pflichtinhalten der Checkliste, Ihren Adressen und Schlüsseln aus dem Formular, auf Deutsch oder Englisch. Offene Stellen stehen in eckigen Klammern: Name des Herstellers, Geltungsbereich, Fingerabdrücke, zuständiges nationales CSIRT, Adresse der Datenschutzerklärung und ein Prüfhinweis zu zivilrechtlichen Schritten; fehlen im Formular Adressen oder Schlüssel, auch diese.
Der Entwurf ist ein Ausgangspunkt, keine Rechtsberatung. Prüfen Sie jede Zusage darauf, ob Sie sie auch im Urlaub und mit Vertretung einhalten können, und klären Sie offene Fragen, etwa einen Verzicht auf zivilrechtliche Schritte, mit Ihrer Rechtsberatung. Wie eine fertige Richtlinie aussieht, zeigt unsere eigene: security-txt.de/security-policy/.
Wo die Richtlinie hingehört
- Auf eine eigene Seite Ihrer Website, etwa
/security-policy, ohne Anmeldung und ohne JavaScript lesbar (TR 4.5.2). - Verlinkt von Ihrer Meldeseite und im Feld
Policyder security.txt. - In einer Sprache, die Nutzer und Marktüberwachung verstehen (TR 4.1.1 c); eine englische Fassung ist naheliegend, weil die TR verlangt, dass Sie Meldungen auf Englisch annehmen (4.3.1 n) und das Meldeformular auf Englisch anbieten (4.3.3 d).
Quellen
- BSI TR-03183-3 Vulnerability Reports and Notifications, Version 1.0.0, 20. August 2025, Abschnitte 4.4 und 4.5.
- Verordnung (EU) 2024/2847 (Cyber Resilience Act), Anhang I Teil II.
- IANA-Register security.txt Fields.