Bild: Generiert mit Gemini Flash

Coordinated Vulnerability Disclosure nach CRA: Policy, security.txt, Advisories und CSAF

5 Min Lesezeit Serie: CRA-Reihe #compliance#cra#cvd#advisories#security-txt#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.

Inhalt dieses Beitrags
  1. Problem
  2. Kurze Antwort
  3. Tiefgang
  4. Abgelehnte Alternativen
  5. Verifikation
  6. Was Sie jetzt tun sollten
  7. Wie Dernium hilft
  8. Offene Punkte
  9. Häufige Fragen
  10. Was ist Coordinated Vulnerability Disclosure (CVD)?
  11. Wozu dient die security.txt?
  12. Warum sollen Advisories maschinenlesbar im CSAF-Format sein?
  13. Ist die koordinierte Offenlegung dasselbe wie die CRA-Meldepflicht?
  14. Mehr aus unserer CRA-Reihe

Problem

Ein Sicherheitsforscher findet eine Lücke in Ihrem Produkt und sucht jemanden, dem er sie melden kann, findet aber keinen Kontakt. Genau dieser blinde Fleck wird unter dem CRA zur Pflichtverletzung. Der Cyber Resilience Act macht die Schwachstellenbehandlung zur Dauerpflicht. Drei Bausteine muss jeder Hersteller eines Produkts mit digitalen Elementen bereitstellen: eine Richtlinie zur koordinierten Offenlegung von Schwachstellen (kurz CVD - der geregelte Weg, auf dem Finder melden und Hersteller beheben), einen auffindbaren Meldekontakt und - sobald eine Korrektur vorliegt - die Veröffentlichung der behobenen Schwachstellen (Anhang I Teil II der Verordnung).

Ad hoc scheitert das an Details: Der Meldekontakt muss für Sicherheitsforscher zuverlässig auffindbar sein - dafür gibt es mit der security.txt einen Standard, eine kleine Textdatei an fester Stelle der Website. Die Hinweise zu behobenen Schwachstellen (Advisories) sollen maschinenlesbar sein, also so strukturiert, dass auch Programme sie automatisch einlesen. Und jede Korrektur muss nachvollziehbar bleiben - was eine handgepflegte HTML-Seite nicht leistet.

Für wen ist das? Für Hersteller, die eine Schwachstellen-Meldestelle und Advisories betreiben müssen.

Kurze Antwort

Dernium CRA hostet die CVD-Strecke (den Weg für koordinierte Schwachstellen-Offenlegung) als öffentliche PSIRT-Seite (die Anlaufstelle des Herstellers für Sicherheitsmeldungen). Kurz zusammengefasst:

  • Eine Seite ohne Login unter cvd.dernium.de/<handle>, mit nicht erratbarem Handle (Kennung) statt sprechendem Org-Namen.
  • Drei Inhalte je Produkt: CVD-Policy (die Offenlegungs-Richtlinie), Meldekontakt und Advisories (die Hinweise zu behobenen Schwachstellen).
  • security.txt nach RFC 9116 entsteht automatisch aus den Policy-Feldern - fertig zum Ablegen auf Ihrer Domain.
  • Jedes Advisory zusätzlich als CSAF-2.0-Dokument - das maschinenlesbare Standardformat für Advisories, das auch das BSI einsetzt.
  • Assist-only: Inhalt, Einstufung und Verantwortung liegen bei Ihnen; Dernium strukturiert und hostet.

Tiefgang

Aus einmal gepflegter Policy fallen PSIRT-Seite, security.txt und maschinenlesbare CSAF-Advisories automatisch ab.
Aus einmal gepflegter Policy fallen PSIRT-Seite, security.txt und maschinenlesbare CSAF-Advisories automatisch ab.

CVD-Policy + Meldekontakt. Sie pflegen je Organisation einmal den Kontaktpunkt (z. B. mailto:security@ihre-domain.de oder eine URL), optional eine PGP-Schlüssel-URL (für verschlüsselte Meldungen), bevorzugte Sprachen und den Richtlinientext. Erst beim Schalten auf "öffentlich" wird die PSIRT-Seite live.

security.txt (RFC 9116). Die Datei trägt Contact, ein Pflicht-Expires in der Zukunft (ein Ablaufdatum, damit veraltete Angaben auffallen) und einen Policy-Verweis. Steuerzeichen werden vor der Ausgabe entfernt, damit niemand zusätzliche Felder einschmuggelt. Sie gehört unter /.well-known/security.txt auf Ihre Produkt-Domain; den Text liefert das Werkzeug.

Produktgebundene Advisories. Advisories hängen am Produkt und durchlaufen Entwurf, Veröffentlichung und Rücknahme. Beim ersten Veröffentlichen vergibt das System eine Jahresnummer (ADV-<Jahr>-<Nr>, nach gängiger CSAF-/CVE-Konvention). Öffentlich sichtbar ist nur Veröffentlichtes; Entwürfe und Zurückgezogenes bleiben außen vor.

Revisionssichere Historie. Jede Änderung an einem veröffentlichten Advisory wird append-only festgehalten, also nur ergänzt, nie überschrieben. So bleibt nachvollziehbar, was wann veröffentlicht und korrigiert wurde - genau die Transparenz der CSAF-revision_history (der im Format vorgesehenen Änderungshistorie).

Maschinenlesbar als CSAF 2.0. Jedes veröffentlichte Advisory steht als CSAF-2.0-Datei bereit - mit Hersteller, betroffenem Produkt, Schwere/CVSS (einer standardisierten Schwere-Bewertung von 0 bis 10), Abhilfemaßnahmen, Referenzen und voller Versionshistorie. Geprüft gegen das offizielle OASIS-Schema und den CSAF-Profil-Validator, damit nachgelagerte Werkzeuge ohne Nacharbeit einlesen.

Abgelehnte Alternativen

  • Ein simples Kontaktformular. Erfüllt weder die Auffindbarkeit per security.txt noch die Veröffentlichungspflicht behobener Schwachstellen.
  • Advisories nur als HTML-Seite. Menschen lesen sie, Werkzeuge nicht. Ohne CSAF überträgt jeder Abnehmer die Daten von Hand; die Revisionshistorie fehlt.
  • "Wir melden und entscheiden für Sie". Bewusst nicht: Ob eine Schwachstelle "aktiv ausgenutzt" oder ein Vorfall "schwer" ist, klassifizieren Sie. Eine Stellvertretung wäre haftungs- und RDG-kritisch (das Rechtsdienstleistungsgesetz beschränkt, wer fremde Rechtsangelegenheiten besorgen darf).

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.

Was Sie jetzt tun sollten

  1. Einen Meldekontakt benennen. Richten Sie eine überwachte Adresse wie security@ihre-domain.de ein - eine Stelle, an die Sicherheitsforscher zuverlässig melden können.
  2. Die security.txt ablegen. Erzeugen Sie die Datei und legen Sie sie unter /.well-known/security.txt auf Ihrer Produkt-Domain ab; achten Sie auf ein Expires-Datum in der Zukunft und erneuern Sie es rechtzeitig.
  3. Eine CVD-Policy schreiben. Halten Sie kurz fest, wie Sie mit Meldungen umgehen: Eingangsbestätigung, Bearbeitungsweg, Offenlegungszeitpunkt. Das gibt Findern Orientierung.
  4. Advisories als CSAF planen. Legen Sie fest, dass jede behobene Schwachstelle nicht nur als Text, sondern maschinenlesbar als CSAF-2.0-Dokument veröffentlicht wird - so können Abnehmer sie automatisch einlesen.
  5. Die Offenlegung von der Meldepflicht trennen. Halten Sie im Kopf, dass die koordinierte Offenlegung etwas anderes ist als die Frist-gebundene Meldung an CSIRT und ENISA - planen Sie beide Prozesse getrennt.

Wie Dernium hilft

Sie pflegen Policy und Advisories im Portal; PSIRT-Seite, security.txt und CSAF-Exporte fallen daraus ab. Ein Disclaimer trennt sichtbar, was Dernium hostet, von dem, was Sie verantworten. So wird der CRA-Baustein "koordinierte Offenlegung" abgedeckt, ohne eigene Infrastruktur.

Offene Punkte

  • Einstufung und Veröffentlichungszeitpunkt einer Schwachstelle 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.

Häufige Fragen

Was ist Coordinated Vulnerability Disclosure (CVD)?

CVD ist der geregelte Weg, auf dem jemand eine gefundene Schwachstelle an den Hersteller meldet, dieser sie behebt und beide die Veröffentlichung abstimmen. Ziel ist, dass eine Lücke erst öffentlich wird, wenn eine Korrektur bereitsteht - statt dass Finder im Dunkeln tappen oder Details vorzeitig offenlegen. Der CRA verlangt eine solche Richtlinie und einen auffindbaren Meldekontakt.

Wozu dient die security.txt?

Die security.txt ist eine kleine Textdatei an fester Stelle der Website (/.well-known/security.txt), in der ein Sicherheitskontakt und ein Verweis auf die Offenlegungs-Richtlinie stehen. So findet ein Sicherheitsforscher zuverlässig die richtige Anlaufstelle, ohne lange zu suchen. Der Standard dafür ist RFC 9116; ein Pflicht-Ablaufdatum sorgt dafür, dass veraltete Angaben auffallen.

Warum sollen Advisories maschinenlesbar im CSAF-Format sein?

Eine reine HTML-Seite können Menschen lesen, aber keine Werkzeuge automatisch verarbeiten. CSAF 2.0 ist ein standardisiertes Format (eingesetzt auch vom BSI), das betroffenes Produkt, Schwere, Abhilfen und Änderungshistorie strukturiert enthält. Dadurch können Abnehmer Ihre Sicherheitshinweise automatisch in ihre eigenen Systeme einspielen, statt jede Angabe von Hand zu übertragen.

Ist die koordinierte Offenlegung dasselbe wie die CRA-Meldepflicht?

Nein, das sind zwei getrennte Pflichten. Die koordinierte Offenlegung regelt den Umgang mit von außen gemeldeten Schwachstellen und deren spätere Veröffentlichung. Die Meldepflicht nach Artikel 14 verlangt davon unabhängig, aktiv ausgenutzte Schwachstellen und schwere Vorfälle fristgebunden an das zuständige CSIRT und an ENISA zu melden.

Mehr aus unserer CRA-Reihe