Context Card
Schwachstellenmeldungen annehmen nach BSI TR-03183-3: Meldung, Benachrichtigung, Sicherheitshinweis
Was erwartet die BSI TR-03183-3 von einem Hersteller, bevor die erste Schwachstellenmeldung eintrifft?
Die kurze Antwort
Einen öffentlichen, auffindbaren Zugang und einen Prozess dahinter: eine signierte security.txt unter /.well-known/, ein PSIRT und ein CSIRT mit Funktionspostfächern und OpenPGP-Schlüsseln, ein anonymes Webformular, eine zentrale Webseite für Schwachstellenmeldungen und eine veröffentlichte CVD-Richtlinie mit Reaktionszeiten. Die Richtlinie trennt außerdem drei Dinge, die oft vermischt werden: die vertrauliche Schwachstellenmeldung, die ein Hersteller erhält, die nicht öffentliche Benachrichtigung, die er an ein CSIRT oder die ENISA schickt, und den öffentlichen Sicherheitshinweis für Nutzer.
Für: Produktsicherheitsteams (PSIRT), Web- und IT-Teams, Compliance-Verantwortliche und Technische Redakteure, die für Sicherheitsinformationen zuständig sind
Das Wichtigste
- Drei Begriffe, drei Richtungen: Eine Schwachstellenmeldung kommt herein (vertraulich, oft mit Proof of Concept), eine Schwachstellenbenachrichtigung geht an ein nationales CSIRT oder die ENISA (nicht öffentlich, vorläufiger CVSS-Wert), ein Sicherheitshinweis geht an die Nutzer (öffentlich, vorzugsweise in CSAF).
- security.txt nach RFC 9116 unter /.well-known/, über HTTPS, mit OpenPGP signiert, mit PSIRT, CSIRT und Webseite als Kontakten, Englisch unter den bevorzugten Sprachen, einem Ablaufdatum höchstens ein Jahr voraus, mindestens vierteljährlich geprüft.
- Zwei Rollen, PSIRT für die Produkte und CSIRT für die Infrastruktur des Herstellers, von verschiedenen Personen besetzt, sofern der Hersteller kein Kleinstunternehmen ist; Meldungen müssen mindestens auf Englisch angenommen und bearbeitet werden können.
- Die CVD-Richtlinie sagt eine nicht automatisierte erste Antwort binnen fünf Arbeitstagen und eine ausführliche Rückmeldung binnen zehn zu sowie die öffentliche Offenlegung validierter und verifizierter Schwachstellen binnen 90 Tagen, einmal um 90 Tage verlängerbar mit dem nationalen CSIRT, mindestens in der Europäischen Schwachstellendatenbank.
- Das sind Anforderungen für die Konformität mit der Richtlinie; die eigenen Meldepflichten des CRA nach Artikel 14 gelten daneben und werden dadurch nicht ersetzt.
Der Zusammenhang
Warum der Zugang zuerst kommt
Teil 3 der BSI TR-03183 geht von einer schlichten Feststellung aus: Schwachstellen lassen sich nicht vermeiden, und nur wenige werden gefunden, bevor ein Produkt auf den Markt kommt. Jeder Prozess der koordinierten Offenlegung von Schwachstellen (CVD) beginnt deshalb damit, dass jemand eine melden kann. Die Richtlinie setzt Mindestanforderungen für diesen Zugang und bittet Hersteller, Meldungen positiv aufzunehmen und nicht mit rechtlichen Schritten zu drohen, solange keine kriminelle Absicht erkennbar ist.
Meldung, Benachrichtigung, Sicherheitshinweis
| Richtung | Empfänger | Inhalt | |
|---|---|---|---|
| Schwachstellenmeldung | an den Hersteller, von Forschenden oder CSIRTs | vertraulich | Identifikation, Ausnutzung, Reproduktion, oft ein Proof of Concept |
| Schwachstellenbenachrichtigung | vom Hersteller an ein nationales CSIRT oder die ENISA | nicht öffentlich | betroffenes Produkt, erste Bewertung, vorläufiger CVSS-Basiswert |
| Sicherheitshinweis | vom Hersteller an alle Nutzer | öffentlich, vorzugsweise CSAF | geprüfter CVSS-Wert, Behebung und Abhilfe |
Die Trennung zählt in der Dokumentation: Eine Release Note oder eine öffentliche Seite ist nie der Ort für die Einzelheiten einer eingegangenen Meldung.
Der Zugang
- Website: Sicherheitsinformationen sind öffentlich, ohne Anmeldung oder Bezahlschranke, in einer Sprache, die Nutzer und Marktüberwachungsbehörden verstehen.
- security.txt (RFC 9116): unter
/.well-known/security.txt, über HTTPS, als reiner Text, mit kanonischer URI, Kontakten (zuerst das PSIRT-Postfach, dann das CSIRT-Postfach, dann die Webseite für Meldungen), OpenPGP-Schlüsseln, bevorzugten Sprachen einschließlich Englisch, der CVD-Richtlinie, optional den CSAF-Provider-Metadaten, einem Ablaufdatum und einer OpenPGP-Signatur. Sie wird mindestens vierteljährlich geprüft und muss für Crawler erreichbar bleiben. - Rollen: ein PSIRT für die Produkte und ein CSIRT für die Infrastruktur, mit Funktionspostfächern wie psirt@ und csirt@ und eigenen Schlüsseln.
- Webformular und Webseite: ein anonymes Webformular ohne Komponenten Dritter oder Tracking und eine zentrale Seite für Schwachstellenmeldungen, von der Startseite aus ohne JavaScript erreichbar.
Die CVD-Richtlinie
Die veröffentlichte Richtlinie nennt die Zusagen des Herstellers und die Regeln für beide Seiten: eine erste, nicht automatisierte Antwort binnen fünf Arbeitstagen, eine ausführliche Rückmeldung binnen zehn, den klaren Hinweis, dass anonyme Meldungen nur eingeschränkt bearbeitet werden können, die öffentliche Offenlegung validierter und verifizierter Schwachstellen binnen 90 Tagen (einmal um 90 Tage verlängerbar in Abstimmung mit dem zuständigen nationalen CSIRT), die Offenlegung mindestens in der Europäischen Schwachstellendatenbank und die Bedingungen, unter denen ein CVD-Fall abgeschlossen ist.
Was die Richtlinie nicht ersetzt
Diese MUSS-Anforderungen gelten für die Konformität mit der Richtlinie. Der Cyber Resilience Act fügt eigene Pflichten hinzu – etwa die Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Vorfälle über die zentrale Meldeplattform der ENISA nach Artikel 14 –, die daneben gelten. Ein funktionierender Zugang ist Voraussetzung für Schwachstellenmanagement und Offenlegung von Schwachstellen, kein Nachweis der CRA-Konformität.
Fragen, die sich daran anschließen
- Verlangt der CRA eine security.txt?
- Der CRA verlangt eine Kontaktadresse für die Meldung von Schwachstellen und eine CVD-Richtlinie; eine security.txt nennt er nicht. Die TR-03183-3 macht eine signierte security.txt nach RFC 9116 zur Anforderung für die Konformität mit der Richtlinie.
- Darf ein Hersteller anonyme Meldungen ablehnen?
- Nach der Richtlinie nicht: Eine leicht auffindbare anonyme Möglichkeit ist Pflicht, vorzugsweise das Webformular. Der Hersteller muss klar sagen, dass anonyme Meldungen nur eingeschränkt bearbeitet werden können, weil Rückfragen unmöglich sind.
Quellen
- Technical Guideline TR-03183-3: Cyber Resilience Requirements for Manufacturers and Products, Part 3: Vulnerability Reports and Notifications, version 1.0.0 — Federal Office for Information Security (BSI), 20. August 2025
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure — IETF, 1. April 2022
- Regulation (EU) 2024/2847 (Cyber Resilience Act) — Official Journal of the European Union, 20. November 2024
- BSI TR-03183: overview of the four parts — CyberKlartext, 13. August 2026
Prüfprotokoll und Änderungen
Jede Context Card wird vor der Veröffentlichung und bei jeder Änderung erneut anhand ihrer Quellen geprüft; das Datum unter der Autorenzeile ist die letzte Prüfung. Korrekturen (etwas war falsch) und Ergänzungen (etwas fehlte) stehen unten mit Datum und Uhrzeit (deutsche Zeit). Tippfehler, Formatierung und Link-Korrekturen werden nicht aufgeführt.
Geprüft
Seit der Veröffentlichung keine Korrekturen oder Ergänzungen.