CRA Coordinated Vulnerability Disclosure: CVD-Policy, Security-Kontakt und Ablauf

Eine Coordinated Vulnerability Disclosure Policy ist unter dem CRA Teil eines belastbaren Schwachstellenprozesses. Hersteller müssen einen klaren Weg schaffen, über den Sicherheitsforscher, Kunden und Partner Schwachstellen melden können, und sie müssen festlegen, wie Meldungen geprüft, koordiniert, behoben und kommuniziert werden.

Einordnung im CRA-Wissen: Dieser Fachartikel gehört zum Themenbereich Schwachstellen & Meldeprozesse. Dort finden Sie die angrenzenden Anforderungen und eine praktische Reihenfolge für die Umsetzung.

Was bedeutet Coordinated Vulnerability Disclosure?

Coordinated Vulnerability Disclosure, kurz CVD, bezeichnet einen abgestimmten Prozess für die Meldung und Veröffentlichung von Schwachstellen. Finder melden eine Sicherheitslücke zunächst an den verantwortlichen Hersteller oder Maintainer. Dieser prüft die Meldung, entwickelt gegebenenfalls eine Korrektur und stimmt die Veröffentlichung so ab, dass Nutzer geschützt werden und ausreichend Zeit für Maßnahmen besteht.

Der CRA macht diese Praxis für Hersteller relevant, weil die Behandlung von Schwachstellen ausdrücklich organisiert und transparent erfolgen soll. CVD ist damit Schnittstelle zwischen externen Hinweisen und internem Risikomanagement.

Braucht jeder Hersteller eine CVD-Policy?

Hersteller von Produkten mit digitalen Elementen müssen im Rahmen der CRA-Anforderungen einen koordinierten Offenlegungsprozess etablieren. Die konkrete Ausgestaltung kann proportional zur Unternehmensgröße und zum Risiko sein, aber ein völlig informeller Prozess ohne veröffentlichten Kontakt und nachvollziehbare Regeln ist keine belastbare Lösung.

Auch kleine Hersteller profitieren von einer kurzen, klaren Policy. Sie verhindert, dass Sicherheitsforscher sensible Details an allgemeine Support-Adressen, soziale Netzwerke oder Vertriebsmitarbeiter senden.

Welche Angaben gehören in eine CVD-Policy?

Eine gute Policy beantwortet die wichtigsten Fragen bereits vor der ersten Meldung. Sie sollte verständlich, öffentlich auffindbar und in einer für die Zielgruppe geeigneten Sprache verfügbar sein.

Wo sollte der Sicherheitskontakt veröffentlicht werden?

Der Kontakt muss leicht auffindbar sein. Sinnvoll sind eine eigene Security-Seite, die Nutzerinformationen zum Produkt und gegebenenfalls standardisierte technische Mechanismen wie eine security.txt-Datei. Entscheidend ist, dass ein Finder nicht raten muss, ob support@, info@ oder sales@ zuständig ist.

Die Nutzerinformationen nach CRA verlangen einen zentralen Kontaktpunkt für Schwachstellenmeldungen. Deshalb sollte derselbe Kontakt konsistent in Website, Produktdokumentation und technischen Hinweisen verwendet werden.

Wie schnell sollte auf eine Meldung reagiert werden?

Der CRA legt für die interne Eingangsbestätigung einer normalen externen Schwachstellenmeldung keine allgemeine Stundenzahl fest. Trotzdem ist ein eigenes Serviceziel sinnvoll. Viele Unternehmen bestätigen den Eingang innerhalb weniger Arbeitstage und geben anschließend einen ersten Status.

Wichtiger als ein aggressives Versprechen ist, dass der Prozess zuverlässig funktioniert. Eine Policy, die eine Antwort innerhalb von 24 Stunden verspricht und dann zwei Wochen schweigt, schafft unnötige Eskalationen. Kritische Meldungen sollten intern selbstverständlich schneller priorisiert werden.

Wie wird eine gemeldete Schwachstelle intern bewertet?

Nach Eingang muss zuerst geprüft werden, ob die Meldung reproduzierbar ist und welches Produkt oder welche Version betroffen ist. Danach folgt die technische und geschäftliche Risikobewertung: Ausnutzbarkeit, mögliche Auswirkungen, Exposition, betroffene Nutzer und vorhandene Schutzmaßnahmen.

Die Bewertung sollte nicht ausschließlich auf einem Score beruhen. Ein technisch hoher Wert kann in einer abgeschotteten Umgebung anders zu behandeln sein als eine moderat bewertete Schwachstelle, die bereits aktiv ausgenutzt wird. Bei aktiver Ausnutzung kann zusätzlich die CRA-Meldepflicht ausgelöst werden.

Wie geht man mit Schwachstellen in Open-Source- oder Drittkomponenten um?

Stellt sich heraus, dass die Schwachstelle in einer eingebundenen Komponente liegt, endet die Verantwortung nicht mit dem Hinweis „kommt von einem Zulieferer“. Hersteller müssen die Schwachstelle im eigenen Produktkontext bewerten und angemessen behandeln.

Der CRA verlangt außerdem, dass identifizierte Schwachstellen in integrierten Komponenten an die Person oder Organisation gemeldet werden, die diese Komponente herstellt oder wartet. Das gilt auch für Open Source. Der Beitrag zu CRA und Open Source erklärt diese Abgrenzung.

Wie koordiniert man die Veröffentlichung?

Ziel der Koordination ist, Nutzer nicht unnötig zu gefährden. Technische Details sollten nicht voreilig veröffentlicht werden, wenn noch kein Patch oder keine Minderungsmaßnahme verfügbar ist. Gleichzeitig darf ein Hersteller eine berechtigte Meldung nicht unbegrenzt zurückhalten.

Ein sinnvoller Ablauf legt fest, wann ein Advisory vorbereitet wird, wann der Finder Feedback erhält und welche Informationen öffentlich werden. Bei komplexen Lieferketten kann auch eine Koordination mit Komponentenherstellern, Distributoren oder CSIRTs erforderlich sein.

Sollte eine CVD-Policy einen Safe-Harbor-Abschnitt enthalten?

Ein klar formulierter Umgang mit gutgläubiger Sicherheitsforschung kann Hemmschwellen für Meldungen senken. Ein Safe-Harbor-Hinweis kann beschreiben, welche Forschungsmethoden akzeptiert werden, welche Grenzen gelten und dass der Hersteller bei Einhaltung der Regeln nicht unnötig gegen den Finder vorgeht.

Die genaue rechtliche Formulierung sollte zum Unternehmen und zur Rechtsordnung passen. Wichtig ist vor allem, dass Sicherheitsforscher erkennen können, welche Tests erlaubt sind und welche Systeme ausdrücklich nicht angegriffen werden dürfen.

Welche Rolle spielt eine security.txt-Datei?

Eine security.txt-Datei kann maschinenlesbar auf Kontakt, Policy und weitere Hinweise verweisen. Sie ersetzt die CVD-Policy nicht, verbessert aber die Auffindbarkeit für automatisierte Tools und Sicherheitsforscher.

Für einen schlanken Prozess ist die Kombination aus öffentlicher Security-Seite, dediziertem Kontakt und security.txt sinnvoll. Alle drei sollten dieselben Kontaktdaten und konsistente Gültigkeitsinformationen enthalten.

Wie verbindet man CVD mit dem internen Schwachstellenmanagement?

Externe Meldungen müssen nach Eingang in denselben kontrollierten Prozess laufen wie intern gefundene Schwachstellen. Das bedeutet: eindeutige Fall-ID, Produktzuordnung, Priorität, Owner, Frist, Maßnahme, Test, Freigabe und Abschluss.

Dadurch verhindert das Unternehmen zwei Parallelwelten – eine für externe Forscher und eine für Entwicklung. Die spätere technische Dokumentation kann auf dieselben Nachweise zurückgreifen. Der geplante Artikel zur CRA-technischen Dokumentation zeigt, welche Prozessnachweise relevant sind.

Welche Fehler sind bei CVD häufig?

• Die Security-Adresse wird nicht überwacht oder landet im Spam.
• Es gibt keine Vertretung bei Urlaub oder Krankheit.
• Finder erhalten keine Eingangsbestätigung.
• Produktversionen können intern nicht schnell zugeordnet werden.
• Schwachstellen in Drittkomponenten werden einfach weitergereicht und nicht im eigenen Produkt bewertet.
• Marketing entscheidet über technische Veröffentlichung ohne Security-Freigabe.
• Die Policy nennt Regeln, die intern niemand kennt.

Wie sieht ein praktikabler CVD-Prozess für ein KMU aus?

Ein kleines Unternehmen kann mit sehr wenigen Bausteinen starten: security@-Adresse, öffentliche Policy, Ticketvorlage, verantwortlicher Security-Owner und definierter Eskalationsweg. Jede Meldung erhält eine Fall-ID und wird einem Produkt und einer Version zugeordnet.

Danach reichen zunächst fünf Statuswerte: eingegangen, in Prüfung, bestätigt, in Behebung, abgeschlossen. Ergänzt um eine Vorlage für Advisory und Finder-Kommunikation entsteht bereits ein reproduzierbarer Prozess.

Wie hängt CVD mit der CRA-Meldeplattform zusammen?

CVD und behördliche Meldung sind zwei unterschiedliche Prozesse. CVD betrifft die koordinierte Bearbeitung und Offenlegung einer Schwachstelle. Die CRA-Single-Reporting-Platform betrifft gesetzliche Meldungen bestimmter aktiv ausgenutzter Schwachstellen und schwerer Sicherheitsvorfälle.

Eine gute CVD-Struktur hilft aber, die relevanten Informationen schnell zu erfassen. Wenn eine externe Meldung eine aktive Ausnutzung belegt, muss der Fall zügig in den gesetzlichen Reporting-Prozess übergeben werden.

Wo stehen die CVD-Anforderungen im CRA?

Die Anforderungen an koordinierte Schwachstellenoffenlegung, Kontaktmöglichkeit und sichere Behandlung finden sich insbesondere in Anhang I Teil II der Verordnung (EU) 2024/2847. Die konkrete Umsetzung sollte an Produktart, Risiko und Unternehmensgröße angepasst werden.

Wie trennt man CVD von allgemeinem Kundensupport?

Ein Supportticket wie „die App stürzt ab“ und eine Meldung wie „Authentisierung lässt sich umgehen“ brauchen unterschiedliche Behandlung. Deshalb sollte der Security-Kontakt nicht einfach in der normalen Ticketwarteschlange verschwinden. Support darf zwar Meldungen weiterleiten, muss aber erkennen, wann ein möglicher Sicherheitsfall vorliegt.

Praktisch helfen kurze Erkennungsregeln und ein internes Eskalationslabel. Mitarbeiter sollten wissen, dass Proof-of-Concept-Code, Hinweise auf Datenzugriff oder Umgehung von Schutzmechanismen nicht in öffentliche Tickets oder ungeschützte Chatkanäle kopiert werden.

Welche Informationen sollte der Finder bereitstellen?

Eine CVD-Policy kann klar erklären, welche Angaben die Analyse beschleunigen: Produktname, Version, Plattform, betroffene Funktion, Reproduktionsschritte, beobachtete Auswirkungen und gegebenenfalls technische Nachweise. Zwingend vollständig müssen diese Angaben beim ersten Kontakt aber nicht sein.

Der Hersteller sollte fehlende Informationen strukturiert nachfragen. Zu viele Pflichtfelder können dazu führen, dass wertvolle Hinweise gar nicht gemeldet werden. Ein guter Meldeweg balanciert technische Tiefe und niedrige Einstiegshürde.

Wie behandelt man anonyme Schwachstellenmeldungen?

Auch anonyme Hinweise können technisch wertvoll sein. Der Hersteller sollte eine Meldung daher nicht allein deshalb verwerfen, weil der Finder keine Identität offenlegt. Entscheidend sind Reproduzierbarkeit und Sicherheitsrelevanz.

Fehlt ein Rückkanal, wird Koordination allerdings schwieriger. Die Policy kann deshalb Möglichkeiten für pseudonyme oder verschlüsselte Kommunikation anbieten. Für die interne Dokumentation sollte kenntlich sein, dass keine weiteren Rückfragen möglich sind und welche Informationen aus eigener Analyse ergänzt wurden.

Was passiert bei strittigen Schwachstellen?

Nicht jede gemeldete Beobachtung ist tatsächlich eine Schwachstelle. Manchmal handelt es sich um erwartetes Verhalten, eine Fehlkonfiguration oder ein Risiko außerhalb der Zweckbestimmung. Auch dann sollte der Hersteller nachvollziehbar antworten und die Entscheidung dokumentieren.

Ein pauschales „works as designed“ ohne Begründung kann unnötige Konflikte auslösen. Besser ist eine kurze technische Einordnung: warum keine Sicherheitsanforderung verletzt wird, welche Annahmen gelten und ob eine Dokumentationsverbesserung trotzdem sinnvoll ist.

Wie arbeitet man mit einem Veröffentlichungstermin?

Viele CVD-Fälle profitieren von einem Zieltermin für die koordinierte Veröffentlichung. Dieser Termin gibt Finder und Hersteller Orientierung, darf aber bei komplexen Produkten nicht starr sein. Ein kritischer Fix kann zusätzliche Tests oder Abstimmung mit Zulieferern benötigen.

Wichtig ist die Kommunikation. Wenn sich ein Termin verschiebt, sollte der Finder wissen, warum und welche Maßnahmen laufen. Umgekehrt kann eine frühere Veröffentlichung sinnvoll sein, wenn Exploit-Code bereits öffentlich ist oder Nutzer akut gefährdet sind.

Welche Rolle spielt Anerkennung für Sicherheitsforscher?

Eine Hall-of-Fame-Seite, Danksagung oder ein Bug-Bounty-Programm ist keine CRA-Pflicht. Anerkennung kann aber eine konstruktive Sicherheitskultur fördern und die Wahrscheinlichkeit erhöhen, dass Finder verantwortungsvoll melden statt sofort zu veröffentlichen.

Unternehmen sollten nur Leistungen versprechen, die sie dauerhaft erfüllen können. Ein formelles Bug Bounty benötigt Budget, Regeln und Missbrauchsschutz. Für viele KMU reicht zunächst eine verlässliche Kommunikation und auf Wunsch eine öffentliche Danksagung.

Wie wird die CVD-Policy versioniert und gepflegt?

Kontaktadressen, Produktbereiche und interne Zuständigkeiten ändern sich. Deshalb sollte auch die CVD-Policy einen Owner und ein regelmäßiges Review haben. Mindestens bei organisatorischen Änderungen, neuen Produktlinien oder geänderten Meldewegen ist eine Aktualisierung notwendig.

Ein einfacher jährlicher Test reicht oft, um tote Postfächer oder veraltete Links zu entdecken. Zusätzlich sollte geprüft werden, ob die Policy mit den Nutzerinformationen und der technischen Dokumentation übereinstimmt.

Wie kann Verschlüsselung für vertrauliche Meldungen angeboten werden?

Bei besonders sensiblen Schwachstellen möchten Finder technische Details nicht unverschlüsselt per E-Mail senden. Ein Hersteller kann deshalb einen öffentlichen PGP-Schlüssel, ein geschütztes Webformular oder einen anderen sicheren Übertragungsweg anbieten.

Der Kanal sollte allerdings gewartet und getestet werden. Ein jahrelang abgelaufener Schlüssel oder ein Formular, das Anhänge verwirft, ist schlechter als ein einfacher, funktionierender Kontakt. Die Policy sollte eindeutig sagen, welchen Weg der Hersteller für vertrauliche Details empfiehlt.

Wie dokumentiert man die Kommunikation mit dem Finder?

Relevante Nachrichten sollten Teil der Fallakte sein: Eingangsbestätigung, Rückfragen, technische Einordnung, vereinbarter Veröffentlichungszeitpunkt und Abschluss. Das hilft bei späteren Reviews und verhindert widersprüchliche Aussagen verschiedener Mitarbeiter.

Persönliche Daten des Meldenden sollten nur soweit verarbeitet werden, wie es für die Bearbeitung nötig ist. Security-Prozess und Datenschutz müssen deshalb zusammenpassen, ohne die technische Kommunikation unnötig zu erschweren.

Wann sollte eine CVD-Policy überarbeitet werden?

Ein Review ist besonders sinnvoll nach einem echten Fall, einer Tabletop-Übung, einer Änderung des Produktportfolios oder wenn neue externe Kontaktwege eingeführt werden. Auch Erkenntnisse aus dem Support können zeigen, dass Melder die Policy nicht finden oder missverstehen.

Die Überarbeitung sollte nicht nur den Webtext betreffen. Interne Workflows, Ticketvorlagen und Vertretungsregeln müssen im selben Schritt angepasst werden, damit veröffentlichte Versprechen und interne Praxis zusammenpassen.