security.txt in Deutschland: 1,8 Prozent der Webseiten haben einen Meldeweg

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat gemessen, wie viele Webseitenbetreiber in Deutschland einen standardisierten Meldeweg für Sicherheitshinweise anbieten. Das Ergebnis der Messung im Cyberdome-Projekt: 1,8 Prozent. Gemeinsam mit der Allianz für Cyber-Sicherheit ruft das BSI dazu auf, das zu ändern, und nennt die Datei eine der niedrigschwelligsten IT-Sicherheitsmaßnahmen überhaupt.

Was steht in einer security.txt nach RFC 9116?

Pflicht sind zwei Angaben: eine Kontaktmöglichkeit und ein Ablaufdatum. Alles Weitere ist optional. Die Datei ist reiner Text, liegt unter /.well-known/security.txt und sagt Sicherheitsforschenden, an wen ein Fund gemeldet werden soll. Den Aufbau erklärt der Wiki-Eintrag zu security.txt im Detail.

Wohin meldet man eine Schwachstelle ohne Kontaktadresse?

Ohne Kontaktadresse bleiben drei Wege, und alle drei sind schlecht. Das allgemeine Kontaktformular, in der Hoffnung, dass die Nachricht den Weg durch Vertrieb und Support findet. Ein Name aus dem Impressum. Oder gar nicht melden. Alle drei Wege kosten Zeit, und Zeit ist im Schwachstellenmanagement die knappste Größe.

Der organisatorische Kern des Problems sitzt hinter der Datei. Geschrieben ist sie in wenigen Minuten. Danach braucht es ein Postfach, das jemand liest. Es braucht eine Eskalation, die greift, und eine Antwortzeit, die irgendwo dokumentiert steht. Die security.txt macht diese Zuständigkeit nach außen sichtbar. Existiert sie nicht, existiert für Außenstehende auch der Prozess nicht.

Wie konkret diese Zuständigkeit gemeint ist, zeigt die Empfehlung BSI-CS 149 der Allianz für Cyber-Sicherheit. Sie rät, zwei Kontakte zu trennen. Für Schwachstellen in der eigenen Infrastruktur etwa security@ oder cert@, für Schwachstellen in eigenen Produkten ein PSIRT unter psirt@. In größeren Organisationen sind das zwei verschiedene Teams mit zwei verschiedenen Prozessen. Landet beides im selben Postfach, sortiert es am Ende der Zufall. Das BSI erwartet außerdem, dass Unternehmen den Erhalt einer Schwachstellenmeldung innerhalb von drei Werktagen bestätigen.

Ab wann gilt der Cyber Resilience Act?

Die Verordnung (EU) 2024/2847 gilt ab dem 11. Dezember 2027. Zwei Teile greifen früher: Kapitel IV ab dem 11. Juni 2026 und Artikel 14 ab dem 11. September 2026. Artikel 14 ist der für den Meldeweg entscheidende. Er verpflichtet Hersteller von Produkten mit digitalen Elementen, eine aktiv ausgenutzte Schwachstelle an das koordinierende CSIRT und an die ENISA zu melden. Fällig sind eine Frühwarnung binnen 24 Stunden und eine vollständige Schwachstellenmeldung binnen 72 Stunden.

Beide Fristen beginnen mit der Kenntnisnahme. Damit hängt die Meldepflicht am Meldeweg. Wer den Hinweis eines Forschers erst nach zwei Wochen aus dem Sammelpostfach fischt, erlangt seine Kenntnis zwei Wochen zu spät. Die Uhr läuft dann, und die Meldung ist bereits überfällig.

Wer ist vom Cyber Resilience Act betroffen?

Die Meldepflicht aus Artikel 14 trifft Hersteller, nicht jeden Webseitenbetreiber. Hersteller ist nach Artikel 3 Nummer 13, wer Produkte mit digitalen Elementen entwickelt oder entwickeln lässt. Dazu muss er sie unter eigenem Namen oder eigener Marke vermarkten. Ob dafür Geld fließt, spielt keine Rolle, unentgeltliche Abgabe zählt ebenso.

Der Anwendungsbereich in Artikel 2 knüpft am Produkt an, nicht an der Branche. Erfasst ist, was bestimmungsgemäß oder vorhersehbar eine Datenverbindung zu einem Gerät oder Netz hat. Ausgenommen sind Produkte, für die bereits eigene EU-Regelwerke gelten, etwa Medizinprodukte nach den Verordnungen (EU) 2017/745 und 2017/746 oder Kraftfahrzeuge nach der Verordnung (EU) 2019/2144.

Für ein Unternehmen, das lediglich eine Webseite betreibt und keine Software vermarktet, entsteht daraus keine Meldepflicht. Die Empfehlung des BSI zur security.txt gilt trotzdem: Sie ist keine CRA-Pflicht, sondern der Weg, auf dem ein Hinweis überhaupt ankommt.

Drei Punkte, die in der Diskussion oft fehlen

Eine security.txt ist keine Erlaubnis zum Testen. RFC 9116 stellt in Abschnitt 5.5 ausdrücklich klar, dass ihre Existenz nicht als Freigabe für Sicherheitstests gegen die Domain gelesen werden darf. Wer Tests erlauben oder ausschließen will, braucht eine Richtlinie, auf die das optionale Policy-Feld verweist.

Zweitens ist die Datei so vertrauenswürdig wie der Server, auf dem sie liegt. Wer eine Webseite übernimmt, kann auch die security.txt ändern oder umleiten, und Meldungen erreichen dann den Angreifer statt das Unternehmen. RFC 9116 empfiehlt dagegen das Canonical-Feld, das die gültigen Fundorte der Datei benennt.

Drittens ist das Ablaufdatum kein Formalismus. Der Standard empfiehlt einen Wert von weniger als einem Jahr in der Zukunft. So meldet niemand an eine Adresse, die seit drei Jahren niemand mehr liest. Ein abgelaufenes Feld macht die Datei ungültig und den Aufwand zunichte.

Einordnung

Hinter der Zahl von 1,8 Prozent steckt kein technisches Problem, sondern eine Entscheidung: so viele Organisationen wollten bisher für Sicherheitshinweise erreichbar sein. Der Aufwand liegt bei einer Textdatei plus einem Postfach mit Zuständigkeit. Der Nutzen zeigt sich an einem einzigen Tag, nämlich dann, wenn jemand von außen etwas weiß, das intern noch niemand weiß.

AWARE7 betreibt selbst eine security.txt nach RFC 9116, PGP-signiert, mit Kontaktadresse, Ablaufdatum, Canonical-Angabe und bevorzugten Sprachen. Wer den Meldeweg strukturiert aufbauen will, findet den nächsten Schritt in der Vulnerability Disclosure und im Beitrag zum Aufbau eines Bug-Bounty-Programms. Für die Einbettung in ein bestehendes Sicherheitskonzept ist die Sicherheitsberatung der passende Rahmen, für die laufende Erkennung der Schwachstellenscan.