Dein Blog zum Thema digitales Business

Ein Sicherheitsforscher findet eine Lücke in deiner Software. Er will sie melden, bevor sie jemand anders findet und ausnutzt. Er sucht nach einem Kontakt: Impressum, „Kontakt“-Seite, vielleicht ein generisches info@-Postfach. Was er nicht findet, ist ein Weg, der ihm sagt: hier bist du richtig, so meldest du, das erwartet dich.

Drei Dinge passieren dann typischerweise. Er gibt auf und die Lücke bleibt offen. Er meldet sie öffentlich, etwa über eine Mailingliste oder Social Media, was du erst erfährst, wenn längst andere mitlesen. Oder seine Mail landet über die Presseabteilung oder ein Kontaktformular bei jemandem, der mit dem Begriff „Responsible Disclosure“ nichts anfangen kann, und dort verstaubt sie in einer Warteschlange, während die Uhr läuft.

Alle drei Fälle haben dieselbe Ursache: es gibt keinen definierten Meldeweg. Genau dafür existiert RFC 9116.

Was RFC 9116 vorschreibt

RFC 9116 (veröffentlicht im April 2022, informational, kein Standards-Track-Dokument) definiert das Format einer Datei namens security.txt. Zwingend vorgeschrieben sind laut RFC nur zwei Felder:

Contact muss immer vorhanden sein und darf mehrfach auftreten, jeweils in Reihenfolge der Präferenz. Erlaubt sind E-Mail-Adressen, Telefonnummern oder Webformulare.

Expires muss ebenfalls immer vorhanden sein, darf aber nur einmal auftreten. Der Wert folgt dem Datumsformat aus RFC 3339, zum Beispiel Expires: 2027-04-30T18:00:00z. Der RFC empfiehlt, den Wert nicht mehr als ein Jahr in die Zukunft zu legen, damit die Datei nicht veraltet, ohne dass es jemand merkt.

Optionale Felder, die den Unterschied machen

Alles Weitere ist optional, macht die Datei aber erst wirklich brauchbar. Encryption verweist auf einen öffentlichen Schlüssel, falls eine Meldung verschlüsselt erfolgen soll. Preferred-Languages gibt in Sprachcodes nach RFC 5646 an, in welcher Sprache Meldungen ankommen sollen, etwa Preferred-Languages: de, en. Canonical nennt die eigentliche, vertrauenswürdige URI der Datei selbst und schützt davor, dass eine kopierte oder gefälschte Version an anderer Stelle als echt durchgeht. Policy verlinkt auf eine ausformulierte Offenlegungsrichtlinie, Acknowledgments auf eine Seite, die Melder öffentlich nennt, Hiring auf offene Stellen im Sicherheitsbereich.

Zeilen, die mit # beginnen, gelten laut RFC als Kommentar. Der RFC nennt außerdem informelle Grenzen, an denen Parser eine Datei ablehnen dürfen: mehr als 32 KB, Felder über 2.048 Zeichen oder mehr als 1.000 Zeilen.

Wo die Datei liegen muss

Der verbindliche Pfad ist https://deine-domain.tld/.well-known/security.txt. HTTPS ist Pflicht, der RFC schreibt das Schema ausdrücklich vor. Für Übergangsfälle erlaubt der RFC zusätzlich eine Kopie im Root-Verzeichnis oder eine Weiterleitung dorthin, macht aber klar: liegt die Datei an beiden Orten, gilt die Version unter /.well-known/. Sicherheitsforscher wiederum sind laut RFC gut beraten, Weiterleitungen genau zu prüfen, weil sie auf eine andere, unter Umständen manipulierte Domain zeigen können.

Einrichtung in wenigen Schritten

Die Datei ist reiner Text, kein Skript, kein Formular, keine Datenbank. Eine minimale, valide Version enthält eine Kontaktadresse und ein Ablaufdatum:

Contact: mailto:security@deine-domain.tld
Expires: 2027-04-30T18:00:00z

Wer mehr geben will, ergänzt Canonical mit der eigenen URL, Preferred-Languages und optional Encryption mit einem Verweis auf einen öffentlichen Schlüssel. Die Datei kommt unter /.well-known/security.txt auf den Webserver, wird per HTTPS ausgeliefert und braucht danach vor allem eines: einen wiederkehrenden Termin im Kalender, an dem das Ablaufdatum geprüft und verlängert wird. Eine security.txt mit abgelaufenem Expires-Feld sieht für einen Forscher aus wie eine verwaiste, nicht mehr gepflegte Adresse.

Von der Recon-Perspektive eines Angreifers auf öffentlich sichtbare, ungewollte Informationen ist das hier ausdrücklich getrennt: es geht um einen bewusst eingerichteten, legitimen Kanal für Sicherheitsforscher, nicht um das, was sich von außen ungefragt auslesen lässt.

Was am Ende zählt

Eine security.txt ersetzt keine Sicherheitsmaßnahme. Sie ist die Voraussetzung dafür, dass jemand, der eine Lücke findet, sie dir sagen kann, bevor sie zum Problem wird. Ohne sie entscheidet der Zufall, ob eine Meldung überhaupt bei der richtigen Person ankommt.

Ob es um die einzelne Umsetzung eines Sicherheitsbausteins wie diesem geht, um die Frage, wie sich KI-Anwendungen im Unternehmen mit klaren Regeln einführen lassen, oder um das ungelöste Problem, wem ein System nach dem Go-Live gehört: das sind unterschiedlich große Aufgaben mit unterschiedlichem Zuschnitt. Ein festes Angebot daraus entsteht erst, wenn klar ist, was der Kunde wirklich braucht. Kontakt: mm@mhm-dl.de