Darf ich das prüfen, wem sage ich es, und was passiert dann?
Der Cyber Resilience Act verlangt in Anhang I Teil II Nummer 5 eine Richtlinie zur koordinierten Offenlegung von Schwachstellen und in Nummer 6 eine Kontaktstelle für Meldungen, beides ab dem 11. Dezember 2027; NIS2 Artikel 12 regelt die koordinierte Offenlegung auf EU-Ebene. Das Modul macht daraus die Eingangsseite Ihrer Schwachstellenkommunikation: Die Richtlinie entsteht aus einer Vorlagenbibliothek, durchläuft Entwurf, Prüfung und Freigabe und wird unter einer stabilen öffentlichen Adresse veröffentlicht. Eine security.txt nach RFC 9116 nennt den Meldeweg dort, wo Sicherheitsforscher zuerst nachsehen, und isidaten prüft täglich nach, ob sie wirklich liegt. Jede Meldung wird zur Fallakte mit Fristen, die am Eingang festgeschrieben werden.
Ihre Produktdomain zeigt nicht auf die isidaten-Instanz. isidaten erzeugt die security.txt, verwahrt sie und prüft täglich per Abruf, ob sie dort liegt, zum Profil passt und noch gilt. Das belegt, dass die Kontaktstelle erreichbar ist, statt es zu behaupten.
Aus den Reaktionszeiten der Richtlinie entstehen je Meldung drei Fristen: Eingangsbestätigung, erste Einschätzung, Veröffentlichung. Sie stehen fest am Datensatz und ändern sich nicht mehr, auch wenn die Richtlinie später angepasst wird. Der protokollierte Eingang ist zugleich der Beleg für den Start der 24-Stunden-Frist des CRA.
Der Freigabestempel lässt sich nicht über ein Formularfeld zurechtrücken, und eine veröffentlichte Fassung bleibt erreichbar, bis eine Neufassung sie ersetzt. Die Adresse trägt ein Token je Mandant und gilt dauerhaft, auch wenn die Richtlinie zwischenzeitlich zurückgezogen war.
Wer eine Lücke in Ihrem Produkt findet, weiß, was erlaubt ist, wen er erreicht und wann er Antwort bekommt. Und Sie können belegen, dass das stimmt.
Vereinbaren Sie eine unverbindliche Demo – wir zeigen Ihnen das Modul an Ihren eigenen Anwendungsfällen.
