Wer eine Sicherheitslücke findet, aber keinen Ansprechpartner, veröffentlicht sie im Zweifel zuerst öffentlich – oder meldet sie gar nicht. RFC 9116 löst genau dieses Problem mit einer einfachen, maschinenlesbaren Textdatei: security.txt. Das BSI empfiehlt sie seit April 2024 in BSI-CS 149 ausdrücklich, und zunicode hat sie gerade unter /.well-known/security.txt veröffentlicht. Wir ordnen ein, wie die Datei aufgebaut ist, was das BSI konkret empfiehlt – und was bei der eigenen technischen Umsetzung schiefgehen kann.
Das Wichtigste vorab
RFC 9116, im April 2022 von der IETF veröffentlicht, legt mit Contact und Expires zwei Pflichtfelder für eine security.txt fest. Kanonischer Ablageort ist /.well-known/security.txt. Das BSI empfiehlt die Datei in BSI-CS 149 vom 9. April 2024 ausdrücklich, warnt aber zugleich: Ohne einen internen Prozess für eingehende Meldungen bleibt sie wirkungslos. zunicode hat die eigene Datei mit dem Kontakt security@zunicode.de veröffentlicht; der interne Meldeprozess dazu befindet sich noch im Aufbau.
Warum es security.txt überhaupt gibt
Software und Hardware sind ab einem gewissen Komplexitätsgrad fehlerbehaftet – Schwachstellen sind, wie das BSI es formuliert, allgegenwärtig. Organisationen prüfen ihre eigenen Produkte zwar regelmäßig, doch viele Lücken werden von unabhängigen Sicherheitsforschenden gefunden, die oft eher zufällig oder im Rahmen eigener Recherchen darauf stoßen. Ihr Fund nützt niemandem, wenn die Meldung an der falschen Stelle landet, in einem allgemeinen Support-Postfach untergeht oder gar nicht erst zugestellt werden kann, weil kein Kontakt bekannt ist.
Genau dafür wurde security.txt entwickelt: eine Datei, die relevante Kontaktinformationen in menschen- und maschinenlesbarer Form an einem definierten Ort bereitstellt. Die Spezifikation stammt von den Sicherheitsforschenden Edwin Foudil und Yakov Shafranovich und wurde im April 2022 als RFC 9116 von der IETF (Internet Engineering Task Force) veröffentlicht. Web-Crawler und automatisierte Prüfwerkzeuge finden die Datei am erwarteten Pfad, ohne dass Meldende erst die Kontaktseite, das Impressum oder eine generische Info-Adresse durchsuchen müssen. Sie ersetzt dabei keine bestehenden Kommunikationskanäle, Richtlinien oder Informationen, sondern ergänzt sie um einen standardisierten, eindeutig auffindbaren Einstiegspunkt.
Aufbau: Pflichtfelder und optionale Angaben
security.txt ist eine reine Klartextdatei in ASCII- beziehungsweise UTF-8-Kodierung, die über HTTPS erreichbar sein muss. Jedes Feld steht in einer eigenen Zeile, Kommentare lassen sich mit einem vorangestellten # ergänzen. Verpflichtend sind laut RFC 9116 und BSI-CS 149 nur zwei Angaben – alle weiteren Felder sind optional, aber jedes davon hat einen klaren Zweck:
| Feld | Pflicht | Zweck |
|---|---|---|
Contact | Ja | Primärer Kontaktweg als E-Mail (mailto:), Web-Adresse (https:) oder Telefonnummer (tel:); mehrere Angaben sind zulässig. |
Expires | Ja | RFC-3339-Zeitstempel mit großem „T“ als Trenner; zeigt, dass die Angaben noch aktuell sind. |
Encryption | Nein | Verweis auf einen öffentlichen OpenPGP-Schlüssel für verschlüsselte Meldungen. |
Acknowledgments | Nein | Verweis auf eine Seite, die Sicherheitsforschende für ihre Funde würdigt. |
Preferred-Languages | Nein | Sprachen, in denen Meldungen akzeptiert werden; ohne Angabe gilt Englisch als Standard. |
Canonical | Nein | Die kanonische URI der Datei selbst – zusammen mit einer Signatur prüfbar. |
Policy | Nein | Verweis auf eine Richtlinie zum Umgang mit Meldungen, etwa ein Coordinated-Disclosure-Verfahren. |
Hiring | Nein | Verweis auf offene Stellen im Sicherheitsbereich. |
CSAF | Nein | Verweis auf die provider-metadata.json für maschinenlesbare Security Advisories nach dem Common Security Advisory Framework. |
Ablageort: /.well-known/ als kanonischer Pfad
RFC 8615 reserviert den Pfadpräfix /.well-known/ genau für solche standardisierten, gut auffindbaren Dateien – die kanonische Position ist deshalb /.well-known/security.txt. BSI-CS 149 nennt daneben auch /security.txt direkt im Wurzelverzeichnis als zulässigen Ort. In der Praxis ist das vor allem ein Fallback für ältere Scanner und Werkzeuge, die noch nicht auf den /.well-known/-Pfad umgestellt wurden; RFC 9116 selbst behandelt die Root-Position als Legacy-Variante. Sinnvoll ist deshalb, beide Pfade zu bedienen, den Root-Pfad aber per Weiterleitung auf die kanonische Datei zeigen zu lassen, statt zwei getrennte Dateien zu pflegen, die auseinanderlaufen können.
Digitale Signatur: empfehlenswert, aber keine Pflicht
Eine digitale Signatur der Datei per OpenPGP-Cleartext-Signatur nach RFC 4880 ist laut BSI empfehlenswert, insbesondere in Verbindung mit dem Feld Canonical: Damit lässt sich prüfen, ob die abgerufene Datei tatsächlich am vorgesehenen Ort liegt und nicht durch eine Manipulation der Webseite unterschoben wurde. Verpflichtend ist die Signatur nicht – das BSI weist aber darauf hin, dass auch eine signierte Datei und die referenzierte URI regelmäßig kontrolliert werden sollten, um Missbrauch zu verhindern. Eine Signatur ist damit ein zusätzlicher Vertrauensanker, kein einmaliges Häkchen.
Was das BSI in BSI-CS 149 konkret empfiehlt
BSI-CS 149 fasst die praktische Umsetzung in sieben Empfehlungen zusammen:
- Ablageort:
/.well-known/security.txtoder alternativ/security.txt, als reine ASCII- beziehungsweise UTF-8-Klartextdatei. - Kontakte trennen: Produkt- und Service-Kontakte (etwa PSIRT oder ProductCERT) von Infrastruktur-Kontakten (etwa SOC, CERT oder CSIRT) unterscheiden, insbesondere in größeren Organisationen.
- Expires aktuell halten: Der Wert sollte regelmäßig geprüft und erneuert werden, üblicherweise mit weniger als einem Jahr Vorlauf.
- Pflicht- und Zusatzfelder:
ContactundExpiressind verpflichtend, die übrigen Felder optional. - Auffindbarkeit sicherstellen: Firewall- und DDoS-Schutzregeln dürfen den Zugriff auf
/.well-known/nicht blockieren, sonst finden Web-Crawler und Prüfwerkzeuge wie findsecuritycontacts.com oder internet.nl die Datei nicht. - Signatur und kanonische URI nutzen: Beides schützt vor Manipulation, ersetzt aber keine regelmäßige Kontrolle.
- Richtlinien veröffentlichen: Eine Policy macht zusätzlich transparent, wie eine Organisation mit Schwachstellenfunden und Sicherheitstests umgeht.
Eine Datei allein reicht nicht
Das BSI stellt in BSI-CS 149 klar, dass eine security.txt eine grundlegende, aber technische Maßnahme ist. Sie benennt einen Kontakt – sie beantwortet nicht, was intern passiert, nachdem eine Meldung eingegangen ist. Dafür verweist das BSI ausdrücklich auf die separate Empfehlung BSI-CS 019 „Handhabung von Schwachstellen“, die beschreibt, wie eingehende Meldungen gesichtet, bewertet und bearbeitet werden sollten.
„Eine Vielzahl von Risiken und Bedrohungen kann nicht alleine durch die Umsetzung technischer Maßnahmen, wie einer security.txt-Datei, sondern vielmehr durch die Kombination von organisatorischen Regelungen und technischen Maßnahmen minimiert werden.“
BSI-CS 149, Weitere Informationen
zunicodes Umsetzung: eine dynamische Route statt einer statischen Datei
Statt security.txt als statische Datei im Webroot abzulegen, hat zunicode sie als virtuelle Route im eigenen WordPress-Core-Plugin umgesetzt: Ein Rewrite-Rule leitet Anfragen an /.well-known/security.txt durch index.php, die Datei wird bei jedem Aufruf neu generiert. Der praktische Vorteil betrifft genau das Feld, das am ehesten veraltet: Expires wird bei jeder Anfrage neu aus dem aktuellen Zeitpunkt berechnet und liegt dabei deutlich unter der vom BSI empfohlenen Jahresgrenze – die Angabe kann dadurch nie unbemerkt in der Vergangenheit landen, ohne dass das manuell nachgepflegt werden müsste. Der Legacy-Pfad /security.txt leitet mit einer 301-Weiterleitung auf die kanonische Datei um, statt eine zweite, potenziell abweichende Kopie zu pflegen.
Ein Aufruf von https://zunicode.de/.well-known/security.txt liefert zum Zeitpunkt der Anfrage sinngemäß folgenden Inhalt – das Expires-Datum verschiebt sich mit jedem Request:
# zunicode – Sicherheitskontakt nach RFC 9116
Canonical: https://zunicode.de/.well-known/security.txt
Contact: mailto:security@zunicode.de
Preferred-Languages: de, en
Expires: 2027-02-07T00:00:00ZDie Felder Encryption und Policy fehlen darin bewusst noch: Ein veröffentlichter OpenPGP-Schlüssel und eine dokumentierte Disclosure-Richtlinie sind sinnvolle nächste Ausbaustufen, aber noch nicht umgesetzt. Ebenso ist der interne Prozess hinter security@zunicode.de – Sichtung, Priorisierung, Eskalation – aktuell im Aufbau; wir versprechen an dieser Stelle bewusst keine konkrete Reaktionszeit und führen keine Hall of Fame, solange es dafür noch keinen belastbaren, laufenden Prozess gibt. Der Kontaktweg selbst ist damit real und erreichbar, ohne dass wir mehr behaupten, als heute tatsächlich dahintersteht.
Der nginx-Stolperstein: wenn Hardening die eigene security.txt blockiert
Beim Testen ist ein Problem aufgetaucht, das BSI-Empfehlung 5 fast wortwörtlich beschreibt: Ein verbreitetes nginx-Härtungs-Snippet blockiert pauschal alle Pfade, die mit einem Punkt beginnen – gedacht als Schutz vor Zugriffen auf versteckte Dateien wie .git oder .env. Genau diese Regel trifft aber auch /.well-known/, weil der Pfad selbst mit einem Punkt-Segment beginnt:
# Verbreitetes Hardening-Snippet: blockiert alle "versteckten" Pfade
location ~ /\. {
deny all;
}
# Trifft ungewollt auch /.well-known/security.txt – Crawler und
# Prüfwerkzeuge wie findsecuritycontacts.com finden die Datei dann nicht.
# Fix: expliziter Block vor der Regel, der /.well-known/ ausnimmt.
# Der ^~-Präfix gewinnt gegen jede Regex-Location, unabhängig von der
# Reihenfolge in der Datei – die Dotfile-Regel darf danach stehen bleiben.
location ^~ /.well-known/ {
try_files $uri $uri/ /index.php?$args;
}Ohne diese Anpassung wäre die Datei technisch korrekt gebaut gewesen und trotzdem für automatisierte Prüfwerkzeuge unsichtbar geblieben – ein stiller Fehler, der bei einem manuellen Blick in den Browser nicht auffällt, weil ein direkter Aufruf über HTTPS in vielen Konfigurationen trotzdem funktioniert, während gezielt gegen Bot- oder Scanner-User-Agents gerichtete Regeln greifen. Wer eine eigene security.txt einführt, sollte deshalb nicht nur die Datei selbst, sondern auch bestehende Firewall-, WAF- und nginx-Regeln gezielt gegen /.well-known/ testen – am einfachsten mit einem Werkzeug wie findsecuritycontacts.com oder internet.nl, das die Datei genauso abruft wie ein externer Scanner.
Warum das mehr ist als ein Compliance-Häkchen
Der eigentliche Nutzen von security.txt liegt nicht in der Datei selbst, sondern in der Zeit, die sie zwischen Fund und Fix einspart. Ohne klaren Kontakt landen Schwachstellenmeldungen im schlechtesten Fall gar nicht bei der Organisation, verzögern sich über allgemeine Support-Kanäle um Tage oder Wochen – oder Findende entscheiden sich mangels Reaktion für eine öffentliche Veröffentlichung, bevor ein Patch überhaupt existiert. Ein eindeutiger, standardisierter Kontaktweg senkt genau dieses Risiko: Er macht es für Sicherheitsforschende einfacher, verantwortungsvoll statt öffentlich zuerst zu melden, und er ist die Voraussetzung dafür, dass ein interner Meldeprozess überhaupt etwas zu bearbeiten bekommt. Für regulierte Organisationen mit eigenen Melde- und Nachweispflichten ist das zusätzlich ein Baustein, der sich sauber mit einem dokumentierten Schwachstellenmanagement verbinden lässt – etwa über CSAF-Advisories oder ein Coordinated-Disclosure-Verfahren, wie sie das BSI in BSI-CS 149 ergänzend nennt.
Quellen
- BSI-CS 149: Sicherheitskontakte mit Hilfe einer security.txt nach RFC 9116 angeben, Version 1.0 vom 9. April 2024 – Aufbau, Pflichtfelder und die sieben BSI-Empfehlungen zur Umsetzung.
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure – die zugrunde liegende IETF-Spezifikation vom April 2022.
- RFC 8615: Well-Known Uniform Resource Identifiers (URIs) – Definition und Registrierung des
/.well-known/-Pfadpräfixes. - BSI-CS 019: Handhabung von Schwachstellen – ergänzende BSI-Empfehlung zum internen Umgang mit eingehenden Schwachstellenmeldungen.
Quellen abgerufen am 7. August 2026. Empfehlungen und Werkzeuge können sich weiterentwickeln; dieser Beitrag ersetzt keine eigene Prüfung der jeweils aktuellen Dokumentation und keine Rechtsberatung für den Einzelfall.
