Coordinated Vulnerability Disclosure nach CRA: Policy, security.txt, Advisories und CSAF
Der Cyber Resilience Act verlangt von Herstellern eine Richtlinie zur koordinierten Schwachstellenoffenlegung, einen auffindbaren Meldekontakt und die Veröffentlichung behobener Schwachstellen. Dernium CRA-Nachweis hostet die CVD-Policy auf einer öffentlichen PSIRT-Seite, erzeugt die security.txt (RFC 9116) und veröffentlicht produktgebundene Advisories - menschen- und maschinenlesbar als CSAF 2.0 mit Revisionshistorie. Dieser Beitrag zeigt die Bausteine und wo bewusst die Verantwortung beim Hersteller bleibt.
Problem
Der Cyber Resilience Act macht die Schwachstellenbehandlung zur Dauerpflicht, nicht zur Kür. Drei Bausteine muss jeder Hersteller eines Produkts mit digitalen Elementen bereitstellen: eine Richtlinie zur koordinierten Offenlegung von Schwachstellen, einen auffindbaren Meldekontakt, und - sobald eine Korrektur verfügbar ist - die Veröffentlichung von Informationen zu behobenen Schwachstellen (Anhang I Teil II der Verordnung).
Wer das ad hoc macht, stolpert über Details: Der Meldekontakt muss für Sicherheitsforscher zuverlässig auffindbar sein (dafür gibt es mit der security.txt einen Standard), die Advisories sollen nicht nur als Fließtext irgendwo stehen, sondern maschinenlesbar konsumierbar sein, und jede nachträgliche Korrektur eines bereits veröffentlichten Advisories muss nachvollziehbar bleiben. Eine handgepflegte HTML-Seite leistet das nicht.
Kurze Antwort
Dernium CRA-Nachweis hostet die CVD-Strecke als eigene öffentliche PSIRT-Seite unter cvd.dernium.de/<handle> - ohne Login, mit einem nicht erratbaren Handle statt eines sprechenden Org-Namens. Dort liegen die CVD-Policy, der Meldekontakt und die veröffentlichten Advisories je Produkt. Aus den Policy-Feldern erzeugt das Werkzeug eine fertige security.txt nach RFC 9116, und jedes veröffentlichte Advisory gibt es zusätzlich als CSAF-2.0-Dokument (das maschinenlesbare OASIS-Format, das auch das BSI für Advisories einsetzt). Assist-only: Inhalt, Einstufung und Verantwortung liegen beim Hersteller; Dernium strukturiert und hostet.
Tiefgang
CVD-Policy + Meldekontakt. Sie pflegen einmal je Organisation den Kontaktpunkt (z. B. mailto:security@ihre-domain.de oder eine URL), optional eine Verschlüsselungs-/PGP-Schlüssel-URL, bevorzugte Sprachen und den Richtlinientext. Erst wenn Sie die Policy auf "öffentlich" schalten, wird die PSIRT-Seite live.
security.txt (RFC 9116). Aus den Policy-Feldern fällt eine fertige security.txt ab - mit Contact, einem Pflicht-Expires in der Zukunft und einem Policy-Verweis auf Ihre PSIRT-Seite. Steuerzeichen werden entfernt, bevor Werte zu security.txt-Zeilen werden, damit niemand zusätzliche Felder einschmuggeln kann. Die Datei gehört unter /.well-known/security.txt auf Ihre Produkt-Domain; das Werkzeug liefert den fertigen Text.
Produktgebundene Advisories. Advisories hängen am Produkt und durchlaufen Entwurf, Veröffentlichung und Rücknahme. Beim ersten Veröffentlichen vergibt das System eine Nummer je Jahr (ADV-<Jahr>-<Nr>, CSAF-/CVE-Konvention). Die öffentliche Seite zeigt ausschließlich Veröffentlichtes; Entwürfe und zurückgezogene Einträge bleiben außen vor.
Revisionssichere Historie. Jede Änderung an einem bereits veröffentlichten Advisory wird append-only als Revision festgehalten. So bleibt nachvollziehbar, was wann veröffentlicht und später korrigiert wurde - genau die Transparenz, die die CSAF-revision_history verlangt.
Maschinenlesbar als CSAF 2.0. Jedes veröffentlichte Advisory gibt es als CSAF-2.0-JSON zum Download. Das Dokument enthält Hersteller, betroffenes Produkt, Schwere/CVSS als Notes, Abhilfemaßnahmen, Referenzen und die volle Versionshistorie. Es ist gegen das offizielle OASIS-Schema und den CSAF-Profil-Validator geprüft, damit nachgelagerte Werkzeuge es ohne Nacharbeit einlesen können.
Abgelehnte Alternativen
- Ein simples Kontaktformular. Erfüllt weder die Auffindbarkeit per security.txt noch die Pflicht zur Veröffentlichung behobener Schwachstellen.
- Advisories nur als HTML-Seite. Menschen lesen sie, Werkzeuge nicht. Ohne CSAF muss jeder Abnehmer die Daten von Hand übertragen; eine Revisionshistorie fehlt.
- "Wir melden und entscheiden für Sie". Bewusst nicht: Ob eine Schwachstelle "aktiv ausgenutzt" oder ein Vorfall "schwer" ist, klassifiziert der Hersteller. Eine Stellvertretung wäre haftungs- und RDG-kritisch.
Wie Dernium hilft
Sie pflegen Policy und Advisories im Portal; die öffentliche PSIRT-Seite, die security.txt und die CSAF-Exporte fallen daraus ab. Der Handle ist nicht erratbar, die Seite zeigt nur Freigegebenes, und ein Disclaimer trennt sichtbar, was Dernium hostet, von dem, was Sie als Hersteller verantworten. So ist der CRA-Baustein "koordinierte Offenlegung" abgedeckt, ohne dass Sie eigene Infrastruktur dafür betreiben.
Offene Punkte
- Die Einstufung einer Schwachstelle und der Zeitpunkt der Veröffentlichung bleiben Ihre Entscheidung als Hersteller. Das Werkzeug hostet und strukturiert, es gibt keine Konformitätsbewertung und keine Rechtsberatung ab.
- Die koordinierte Offenlegung (dieser Beitrag) ist getrennt von der CRA-Meldepflicht an CSIRT und ENISA (24h/72h/14 Tage) - dafür gibt es den separaten assistierten Meldeworkflow.
Verifikation
Die Pflicht zur koordinierten Offenlegung, zum Meldekontakt und zur Veröffentlichung behobener Schwachstellen steht in Anhang I Teil II der Verordnung (EU) 2024/2847. Der Meldekontakt folgt RFC 9116 (security.txt), die maschinenlesbaren Advisories dem OASIS-Standard CSAF 2.0.