Wenn das Telefonbuch fehlt

Manchmal ist die größte Sicherheitslücke nicht der fehlende Patch, sondern das fehlende Telefonbuch. Genau das hat das BSI Anfang August in einer Meldung ziemlich unaufgeregt festgestellt: Nur 1,8 Prozent der Webseitenbetreiber in Deutschland stellen eine security.txt bereit. Heise hat daraus zurecht die Schlagzeile gemacht, dass Deutschland Sicherheit verschläft – und ich muss sagen, nachdem ich die Datei vor Kurzem selbst für unsere Unternehmenshomepage eingerichtet habe, wundert mich diese Zahl nicht. Sie erklärt sich fast von selbst, sobald man einmal versucht hat, als Außenstehender eine Sicherheitslücke bei einer beliebigen Firma zu melden.

Kurz zur Einordnung, für alle, die den Begriff zum ersten Mal lesen: security.txt ist eine simple Textdatei nach RFC 9116, die unter /.well-known/security.txt auf jedem Webserver liegen soll. Sie beantwortet eine einzige, aber entscheidende Frage: An wen wende ich mich, wenn ich hier gerade eine Schwachstelle gefunden habe? Pflichtfelder sind eigentlich nur zwei – Contact (wie erreiche ich euch) und Expires (bis wann gilt diese Angabe). Optional kommen Dinge wie Encryption (PGP-Key für verschlüsselte Meldungen), Policy (Link zur Responsible-Disclosure-Regelung), Preferred-Languages oder Acknowledgments dazu.

Das ist, ganz ehrlich, technisch trivial. Ich habe die Implementierung bei uns in ca. zwanzig Minuten erledigt, inklusive Testen und Deploy. Der Aufwand ist also nicht das Problem. So sieht unsere security.txt aus:

Contact: mailto:alert@cephei.com
Expires: 2027-08-10T00:00:00.000Z
Preferred-Languages: de, en

Was mir bei der Umsetzung aufgefallen ist: Man braucht kein Security-Team, keine Freigabeschleife, keinen Change-Request – man braucht nur jemanden, der überhaupt daran denkt. Und genau da liegt der Hase im Pfeffer. Websites werden von Marketing, von Agenturen, von wechselnden Dienstleistern gepflegt. Sicherheit ist bei diesen Projekten selten Teil des Lastenhefts, und ein Kontakt für „hallo, hier ist ein Loch in eurer Software“ kommt in keinem Briefing vor, weil niemand aktiv danach gefragt hat.

Das Ergebnis: Ein Forscher findet eine Lücke, will sie melden, landet in einem Kontaktformular, das nach drei Tagen eine automatische Empfangsbestätigung schickt – falls überhaupt. Oder er versucht es über LinkedIn, weil das schneller geht als der offizielle Weg. Manche resignieren, weil ihnen die Geduld fehlt, und veröffentlichen die Lücke einfach, statt sie dem Betreiber der Webseite vorher zu melden. Genau dieses Szenario beschreibt auch der Heise-Artikel: Es geht nicht darum, dass es keine Meldewege gäbe, sondern dass sie so undurchsichtig sind, dass Angreifer am Ende schneller sind als gutwillige Melder.

Interessant ist der regulatorische Rahmen, den BSI und Allianz für Cyber-Sicherheit gerade mitliefern: Der Cyber Resilience Act (CRA) wird ab Dezember 2027 verbindliche Meldepflichten für Schwachstellen bei vernetzten Produkten vorschreiben. Wer jetzt schon eine funktionierende security.txt mit klaren Verantwortlichkeiten hat, muss dann nicht in Torschlusspanik etwas zusammenschustern, sondern hat einen eingespielten Prozess. Das ist im Grunde die immer gleiche Lektion, die wir bei Compliance-Themen ständig sehen: Wer früh und aus eigenem Antrieb handelt, baut etwas, das funktioniert. Wer erst unter Regulierungsdruck handelt, baut etwas, das gerade so durch die Prüfung kommt.

Zum Vergleich der Größenordnung: Selbst international, unter den Top-1-Million-Domains weltweit, liegt die Adoptionsrate laut aktuellen Auswertungen nur bei etwa 1,25 Prozent – und davon erfüllen nur 44 Prozent wirklich alle RFC-Vorgaben korrekt (stattdessen fehlendes Ablaufdatum, falsche Canonical-URLs, das ganze Sortiment an Flüchtigkeitsfehlern). Deutschland liegt mit 1,8 Prozent sogar leicht über dem globalen Schnitt von 1,25 Prozent unter den Top-1-Million-Domains – was zeigt, dass hier kein rein deutsches, sondern ein globales Versagen vorliegt. Das macht die Lage nicht besser, es zeigt nur: Wer jetzt handelt, hebt sich wirklich ab.

Drei Dinge, die ich anderen mitgeben würde, die das jetzt auch angehen wollen:

1. Kein Personen-Postfach als Contact. Eine Rollen-Adresse (security@firma.de) verwenden, sonst ist die Datei tot, sobald die zuständige Person das Unternehmen verlässt.
2. Expires ernst nehmen und im Kalender eintragen. Eine abgelaufene security.txt wirkt schlimmer als keine – sie signalisiert, dass niemand hinschaut.
3. Digitale Signatur, wenn es die Infrastruktur zulässt. Klingt nach Kleinkram, verhindert aber, dass jemand eine gefälschte Kontaktseite unterschiebt, um Meldungen abzufangen.

Der eigentliche Punkt ist aber ein grundsätzlicherer: security.txt ist eine der wenigen Sicherheitsmaßnahmen, bei denen der Aufwand fast null und der Nutzen real ist. Kein Tool, kein Lizenzmodell, keine Roadmap-Diskussion – nur eine Textdatei, ein .well-known-Verzeichnis und der Wille, überhaupt erreichbar zu sein. Dass 98 Prozent der deutschen Unternehmen selbst diese Minimalhürde nicht nehmen, sagt mehr über unsere kollektive Prioritätensetzung bei IT-Sicherheit aus als jede Studie über Ransomware-Kosten.