Vulnerability Disclosure Policy (VDP) nach CRA Art. 13

Eine Vulnerability Disclosure Policy (VDP) ist nach Artikel 13 Absatz 6 des Cyber Resilience Act für jeden Hersteller eines Produkts mit digitalen Elementen verpflichtend. Veröffentlichen müssen Sie sie, bevor das Produkt in Verkehr gebracht wird — und sie muss echte Verfahren beschreiben.

Keine leere Compliance-Checkbox also. Sondern der Unterschied zwischen einer kontrollierten Schwachstellenoffenlegung und einem Twitter-Thread, der Ihren Ruf zerstört.

Dieser Artikel erklärt, was eine VDP nach CRA enthalten muss, welche Möglichkeiten Hersteller bei der Offenlegungsstrategie haben und wie eine praxistaugliche Vorlage aussieht.

Was Artikel 13 Absatz 6 CRA tatsächlich verlangt

Verpflichtet sind alle Hersteller von Produkten mit digitalen Elementen — unabhängig von Unternehmensgröße oder Produktklasse. Keine Ausnahme für KMUs. Keine Ausnahme für Kleinstunternehmen.

Was viele übersehen: Das gilt auch für Hersteller von embedded Software für Heizungssteuerungen, für IoT-Startups mit industriellen MQTT-Gateways und für Maschinenbauer, die ihre Steuerungssoftware als Produktbestandteil vertreiben. Wer ein Produkt mit digitalen Elementen in Verkehr bringt, braucht eine VDP — fertig.

Konkret verpflichtet Artikel 13 Absatz 6 jeden Hersteller, eine koordinierte Schwachstellenoffenlegungspolitik (Coordinated Vulnerability Disclosure Policy, CVD-Policy) festzulegen und zu veröffentlichen. Der Begriff “VDP” ist die in der Praxis verbreitete Kurzform. Die VDP muss:

• öffentlich zugänglich sein (nicht nur auf Anfrage)
• einen Meldekanal für Sicherheitsforschende benennen
• beschreiben, wie Hersteller mit gemeldeten Schwachstellen umgehen
• angeben, welche Frist sich der Hersteller zur ersten Rückmeldung gibt

Außerdem ist die VDP die Grundlage für die Meldepflicht nach Artikel 14 CRA: Nutzt jemand eine Schwachstelle aktiv aus, muss der Hersteller ENISA innerhalb von 24 Stunden eine Frühwarnung übermitteln. Ohne funktionierenden Meldekanal können Sie diese Frist nicht einhalten. Das ist kein theoretisches Risiko — das ist ein operatives Problem.

Weitere Informationen zur Meldepflicht finden Sie im Artikel zur Schwachstellenmeldepflicht nach CRA.

Pflichtinhalte einer VDP nach CRA

1. Meldekanal

Was er enthalten muss: Eine E-Mail-Adresse (typischerweise security@ihre-domain.de), optional ergänzt durch ein webbasiertes Meldeformular oder einen verschlüsselten Kanal (PGP-Key veröffentlicht auf Ihrer Domain oder auf einem Key-Server).

Anforderung: Der Kanal muss erreichbar sein und jemand muss ihn überwachen. Eine E-Mail-Adresse, auf die niemand antwortet, erfüllt die Anforderung formal — untergräbt aber das Vertrauen der Meldenden und ist in der Praxis wertlos.

Praxishinweis: Richten Sie security@ihre-domain.de ein und leiten Sie E-Mails an eine überwachte Inbox weiter. Wer verschlüsselte Kommunikation ermöglichen will: OpenPGP-Key veröffentlichen und im security.txt referenzieren. Für KMUs ohne dediziertes Security-Team reicht eine E-Mail-Weiterleitung an die Geschäftsführung oder an einen beauftragten IT-Dienstleister.

2. Scope

Was er enthalten muss: Eine klare Definition, welche Produkte und Systeme die VDP erfasst — und optional, welche sie explizit ausschließt.

Anforderung: Ohne Scope-Definition wissen Forschende nicht, worüber sie berichten sollen. Ohne explizite Ausschlüsse riskieren Hersteller Meldungen über Systeme, über die sie keine Kontrolle haben (z. B. Hosting-Infrastruktur des Cloud-Anbieters).

Ein Hersteller von industriellen MQTT-Gateways — typisches Industrie-4.0-Szenario — sollte hier klar unterscheiden: Gateway-Firmware ja, Cloud-Dashboard des SaaS-Providers nein. Sonst landen Meldungen zu Systemen bei ihm, über die er keine Kontrolle hat.

Praxishinweis: Listen Sie Ihre CRA-pflichtigen Produkte namentlich auf. Schließen Sie explizit aus: Systeme Dritter, die Sie nutzen aber nicht kontrollieren (z. B. GitHub, AWS), und Testsysteme oder Staging-Umgebungen, sofern Sie dort keine Patches bereitstellen können. Eine klare Scope-Definition reduziert unqualifizierte Meldungen erheblich.

3. Reaktionszeiten

Was sie enthalten muss: Eine verbindliche Aussage, innerhalb welcher Frist der Meldende eine erste Rückmeldung erhält und wann er mit einer Einschätzung zur gemeldeten Schwachstelle rechnen kann.

Anforderung: CRA schreibt keine spezifischen Fristen in der VDP vor. Die Branchenpraxis — und die ISO/IEC 30111-Norm für Schwachstellenbehandlung — empfehlen: erste Bestätigung innerhalb von 5 Werktagen, Bewertung innerhalb von 30 Tagen, Patch oder begründeter Alternativplan innerhalb von 90 Tagen.

Das klingt selbstverständlich. In der Praxis erleben wir das Gegenteil: Kleine Hersteller — ob IoT-Startup oder Maschinenbauer mit fünf Entwicklern — kopieren Fristen aus Enterprise-Policies, die sie mit ihrem Team nie einhalten können.

Praxishinweis: Setzen Sie Fristen, die Sie realistisch einhalten können. Eine VDP, die “24-Stunden-Response” verspricht aber wochenlang schweigt, ist schlechter als eine, die “5 Werktage” verspricht und dieses Versprechen hält. Sicherheitsforschende arbeiten mit mehreren Herstellern parallel — Verlässlichkeit ist wichtiger als schnelle Versprechen.

4. Danksagungskultur (Hall of Fame / Credits)

Was sie enthalten muss: Eine Aussage dazu, ob und wie Hersteller Forschende für valide Meldungen anerkennen — und unter welchen Bedingungen Anonymität möglich ist.

Anforderung: CRA schreibt keine Belohnungen oder Bug-Bounty-Zahlungen vor. Ein öffentliches “Hall of Fame” oder Credits in Release Notes reichen als Anerkennungsform aus. Wichtiger als die Form: die explizite Zusage, dass Hersteller valide Meldungen nicht rechtlich verfolgen.

Praxishinweis: Fügen Sie eine Safe-Harbour-Klausel ein (keine rechtlichen Schritte gegen Forschende, die sich an Ihre VDP halten und keine Daten exfiltrieren oder Systeme beschädigen). Das ist kein Rechtsverzicht — Hersteller behalten alle Rechte gegenüber Personen, die Systeme vorsätzlich schädigen. Aber es senkt die Schwelle für legitime Meldungen erheblich.

Coordinated Disclosure vs. Full Disclosure

Wer als Hersteller eine VDP veröffentlicht, legt damit auch fest, nach welchem Offenlegungsmodell er arbeitet. Das beeinflusst direkt, wie Forschende mit Ihrer Policy umgehen.

Koordinierte Offenlegung (Coordinated Vulnerability Disclosure, CVD)

Funktionsweise: Der Forschende meldet die Schwachstelle privat an den Hersteller. Der Hersteller bekommt Zeit, einen Patch zu entwickeln und auszurollen. Nach einer vereinbarten Frist (typisch: 90 Tage) veröffentlichen Hersteller und Forschende die Schwachstelle gemeinsam — oder der Forschende allein.

Vorteile: Nutzer sind geschützt, bevor die Schwachstelle öffentlich bekannt ist. Der Hersteller kann Kontext liefern und den Patch koordiniert kommunizieren.

Nachteile: Erfordert Vertrauen zwischen Forschenden und Hersteller. Ignoriert der Hersteller die Frist oder setzt er den Forschenden unter Druck, wechseln erfahrene Forschende zur Full Disclosure.

CRA-Relevanz: Artikel 13 Absatz 6 schreibt explizit eine “koordinierte” Offenlegungspolitik vor. CVD ist die regulatorisch bevorzugte Form.

Vollständige Offenlegung (Full Disclosure)

Funktionsweise: Die Schwachstelle wird sofort oder nach sehr kurzer Frist öffentlich bekannt gemacht — ohne oder trotz vorheriger Herstellerbenachrichtigung.

Wann es passiert: Wenn der Hersteller auf eine Meldung nicht reagiert, die Schwachstelle verharmlost oder den Forschenden rechtlich bedroht.

Konsequenz für Hersteller: Volle öffentliche Exposition, ohne Zeit für einen koordinierten Patch. Oft verbunden mit Medienberichterstattung und Kundenfragen — das ist das Twitter-Thread-Szenario.

Praxishinweis: Eine glaubwürdige CVD-Policy, die konsequent gelebt wird, ist die beste Prävention gegen unkoordinierte Full Disclosure. Forschende wählen in aller Regel CVD, wenn sie glauben, dass der Hersteller ernsthaft reagiert.

security.txt nach RFC 9116

RFC 9116 definiert ein maschinenlesbares Format für Sicherheitskontaktinformationen. Die Datei heißt security.txt und wird unter https://ihre-domain.de/.well-known/security.txt veröffentlicht.

Pflichtfelder:

Contact: mailto:security@ihre-domain.de
Expires: 2027-05-20T00:00:00.000Z

Empfohlene Zusatzfelder:

Acknowledgments: https://ihre-domain.de/security/hall-of-fame
Policy: https://ihre-domain.de/security/vulnerability-disclosure-policy
Preferred-Languages: de, en
Encryption: https://ihre-domain.de/.well-known/pgp-key.txt

Praxishinweis: Das Expires-Feld ist Pflicht nach RFC 9116. Setzen Sie es auf maximal 1 Jahr in der Zukunft — automatisierte Scanner ignorieren abgelaufene security.txt-Dateien. Richten Sie eine Kalender-Erinnerung ein, um die Datei jährlich zu aktualisieren. Die security.txt ist kein Ersatz für eine vollständige VDP — sie ist der maschinenlesbare Verweis auf Ihren Meldekanal.

Vorlage-Struktur für eine CRA-konforme VDP

Hinweis: Das folgende Muster ist kein Rechtsformular. Es illustriert die empfohlene Struktur. Lassen Sie Ihre finale VDP von einem Rechtsanwalt prüfen.

Vulnerability Disclosure Policy — [Ihr Unternehmen]

Version: 1.0 | Gültig ab: [Datum]

1. Geltungsbereich

Diese Policy gilt für alle Sicherheitsschwachstellen in folgenden Produkten und Diensten von [Unternehmen]:

• [Produkt A, Version X.x und höher]
• [Produkt B, alle Versionen]

Nicht erfasst sind: Systeme Dritter (z. B. Cloud-Infrastruktur von Hosting-Anbietern), interne Testsysteme ohne Produktionsdaten sowie Sicherheitslücken in Open-Source-Komponenten, die direkt beim jeweiligen Projekt gemeldet werden sollten.

2. Meldekanal

Schwachstellen melden Sie bitte an: security@ihre-domain.de

Für verschlüsselte Kommunikation: PGP-Key unter [URL]. Bitte geben Sie in Ihrer Meldung an: betroffenes Produkt und Version, Art der Schwachstelle, Schritte zur Reproduktion und ggf. Proof-of-Concept.

3. Reaktionszeiten

• Eingangsbestätigung: innerhalb von 5 Werktagen
• Erste Bewertung der Schwachstelle: innerhalb von 20 Werktagen
• Patch oder begründeter Alternativplan: innerhalb von 90 Tagen bei kritischen und hohen Schwachstellen

4. Koordinierte Offenlegung

Wir bitten darum, uns 90 Tage Zeit zu geben, eine Schwachstelle zu beheben, bevor sie öffentlich bekannt gemacht wird. Bei besonders kritischen Schwachstellen (CVSS ≥ 9.0) koordinieren wir die Veröffentlichung gemeinsam mit Ihnen. Wir informieren Sie über den Fortschritt und teilen mit, wann ein Patch verfügbar ist.

5. Safe Harbour

Wir werden keine rechtlichen Schritte gegen Personen einleiten, die Schwachstellen gemäß dieser Policy melden — sofern sie: keine Daten exfiltrieren, keine Systeme beschädigen oder stören, keine Daten Dritter einsehen und die Schwachstelle nicht vor Ablauf der Koordinierungsfrist veröffentlichen.

6. Anerkennung

Forschende, die valide Schwachstellen melden, werden auf unserer [Hall-of-Fame-Seite / in unseren Release Notes] namentlich (oder auf Wunsch anonym) genannt.

Verhältnis zur Meldepflicht nach Artikel 14 CRA

Die VDP regelt den Kanal für externe Meldungen. Artikel 14 CRA regelt, was Hersteller tun müssen, wenn jemand eine Schwachstelle aktiv ausnutzt:

• Innerhalb von 24 Stunden: Frühwarnung an ENISA übermitteln
• Innerhalb von 72 Stunden: Vollständige Schwachstellenmeldung an ENISA übermitteln
• Innerhalb von 14 Tagen: Abschlussbericht mit Patch-Status einreichen

Diese Fristen gelten unabhängig davon, ob jemand die Schwachstelle extern gemeldet oder der Hersteller sie intern entdeckt hat. Das ist der Punkt, den viele übersehen: Wer keine funktionierende interne Bewertungsroutine hat, wird die 24-Stunden-Frist unter Stress nicht einhalten. Eine gut strukturierte VDP beschleunigt intern die Bewertung und Reaktion — das zahlt direkt auf diese Fähigkeit ein.

Alles zur Meldepflicht im Detail erklärt der Artikel zur Schwachstellenmeldepflicht nach CRA. Einen Überblick über alle Herstellerpflichten gibt der Artikel zu den CRA-Pflichten für Hersteller.

Zusammenfassung

Keine Rechtsberatung. Indikative Einschätzung auf Basis der Verordnung (EU) 2024/2847. Für verbindliche Aussagen zu Ihrer konkreten VDP wenden Sie sich an einen spezialisierten Rechtsanwalt.