security.txt: Eine kleine Datei mit großer Wirkung

Ein Sicherheitsexperte findet eine offene Schwachstelle in Ihrem Onlineshop. Er will sie melden, bevor jemand sie ausnutzt. Nur: an wen? Das Kontaktformular landet im allgemeinen Vertriebspostfach, die info@-Adresse liest niemand mit dem richtigen Blick, und einen Sicherheitskontakt gibt es nirgends. Am Ende passiert das Wahrscheinlichste: Er lässt es. Die Lücke bleibt offen, und Sie erfahren nichts davon.

Genau dieses Loch schließt eine unscheinbare Textdatei. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat Anfang August 2026 gemessen, wie verbreitet sie in Deutschland ist: Gerade einmal 1,8 Prozent der Webseitenbetreiber stellen eine security.txt bereit. Der Aufwand ist gering, der Nutzen erheblich.

Was in der Datei steht

security.txt ist ein festgelegtes Dateiformat, das Sicherheitsforschern einen klaren Meldeweg für Schwachstellen zeigt. Definiert wird es seit April 2022 durch RFC 9116, einen offiziellen Internet-Standard der IETF. Die Datei liegt an einer festen Adresse: https://ihre-domain.de/.well-known/security.txt. Dieser Pfad ist keine Empfehlung, sondern vorgeschrieben, damit jeder und jeder automatische Scanner sie am selben Ort findet. Sie wird über HTTPS ausgeliefert und ist reiner Text.

Der Inhalt besteht aus Feldern nach dem Muster Name: Wert. Zwei davon sind Pflicht:

• Contact nennt den Meldeweg für Schwachstellen, eine E-Mail-Adresse (mailto:security@ihre-domain.de), eine Telefonnummer oder eine Webseite mit Kontaktinformationen. Mehrere Angaben sind erlaubt, die erste gilt als bevorzugt.
• Expires ist ein Ablaufdatum. Es sagt Forschern, bis wann die Angaben in der Datei als gültig gelten. Der Standard empfiehlt, es auf weniger als ein Jahr in die Zukunft zu setzen.

Alle weiteren Felder sind optional:

• Policy verlinkt Ihre Richtlinie zur Schwachstellenmeldung. Dort steht, was ein Sicherheitsexperte darf und wie Sie mit Meldungen umgehen.
• Encryption verweist auf einen Verschlüsselungsschlüssel, mit dem sich heikle Hinweise vertraulich übermitteln lassen.
• Canonical gibt die eigentliche Adresse der Datei an und schützt so vor untergeschobenen Fälschungen.
• Dazu kommen kleinere Felder wie Preferred-Languages für die bevorzugte Sprache oder Acknowledgments für eine Dankesseite an Melder.

Ein vollständiges Beispiel:

Contact: mailto:security@ihre-domain.de
Expires: 2027-06-30T23:59:00.000Z
Policy: https://ihre-domain.de/sicherheit/meldung
Preferred-Languages: de, en

Mehr braucht es für den Anfang nicht.

Warum es die Datei braucht

Warum nicht eine security@-Adresse ins Impressum? Der Unterschied liegt in der Auffindbarkeit. Ein Mensch liest Ihr Impressum, ein automatischer Sicherheitsscanner nicht. security.txt ist maschinenlesbar und liegt immer am selben Ort. Wer eine Schwachstelle findet, ob Sicherheitsexperte oder ein automatisierter Scan, weiß sofort, wohin die Meldung geht, ohne zu suchen.

Fehlt dieser Weg, gehen Hinweise auf Sicherheitslücken laut BSI häufig verzögert, an der falschen Stelle oder gar nicht ein. Das ist keine theoretische Sorge. Der Meldende hat keinerlei Verpflichtung, sich Mühe zu geben. Findet er in dreißig Sekunden keinen Kontakt, ist die Meldung für ihn erledigt und Sie tragen das Risiko weiter, ohne es zu kennen.

Dahinter steht ein etabliertes Prinzip, die koordinierte Schwachstellenmeldung (englisch coordinated vulnerability disclosure). Die Idee: Wer eine Lücke findet, meldet sie zuerst vertraulich dem Betreiber und gibt ihm Zeit, sie zu schließen, bevor Details öffentlich werden. Dieses Verfahren funktioniert nur, wenn der erste Schritt den Website-Betreiber überhaupt erreicht.

Und es gibt eine zweite Ebene, die oft unterschätzt wird: Eine gepflegte security.txt zeigt Geschäftspartnern, Kunden und Prüfern, dass ein Unternehmen Sicherheit ernst nimmt und einen geordneten Prozess dafür hat. In Lieferketten, in denen große Auftraggeber zunehmend nach der IT-Sicherheit ihrer Zulieferer fragen, ist das ein einfacher, sichtbarer Beleg von Reife.

security.txt kostet fast nichts und signalisiert viel: einen Betreiber, der weiß, dass Schwachstellen zum Betrieb gehören und der einen Weg bereithält, damit umzugehen.

Aus Kür wird Pflicht

Bislang war eine security.txt freiwillig. Das ändert sich gerade. Der Cyber Resilience Act (CRA), die EU-Verordnung für die Sicherheit vernetzter Produkte, stellt verbindliche Anforderungen an den Umgang mit Schwachstellenmeldungen. Ab dem 11. September 2026 gelten Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle, ab Dezember 2027 ist der CRA vollständig verpflichtend. Kern der neuen Regeln ist ein erreichbarer Anlaufpunkt für Schwachstellenmeldungen, also genau das, was security.txt bereitstellt.

Auch die NIS2-Richtlinie zieht in dieselbe Richtung. Zu den zehn Risikomanagement-Bereichen, die betroffene Unternehmen nach Paragraf 30 des BSI-Gesetzes umsetzen müssen, gehört der Umgang mit Schwachstellen. Ein definierter Meldeweg ist dafür die Grundlage. Wer sich mit den technischen NIS2-Pflichten ohnehin beschäftigen muss, findet in security.txt den kleinsten und billigsten Baustein davon.

Das BSI und die Allianz für Cyber-Sicherheit rufen Betreiber ausdrücklich zur Umsetzung auf. Die Datei zählt zu den niedrigschwelligsten IT-Sicherheitsmaßnahmen überhaupt. Für Unternehmen heißt das: Wer heute einrichtet, was in Minuten geht, reagiert frühzeitig auf eine Regulierung, die ohnehin kommt.

In wenigen Schritten eingerichtet

Sie brauchen weder Spezialsoftware noch ein Sicherheitsbudget.

1. Einen Kontakt festlegen, der auch gelesen wird. Richten Sie eine Adresse wie security@ihre-domain.de ein und leiten Sie sie an die Person oder den Dienstleister weiter, der Meldungen tatsächlich bearbeiten kann. Ein toter Briefkasten ist schlimmer als keiner.
2. Die Datei erzeugen. Der kostenlose Generator auf securitytxt.org fragt die Felder ab und gibt Ihnen einen fertigen, formal korrekten Text aus. Sie füllen Contact und Expires aus, ergänzen bei Bedarf Policy und Sprache, und übernehmen das Ergebnis.
3. Die Datei an die richtige Stelle legen. Sie muss unter /.well-known/security.txt erreichbar sein. Auf den meisten Servern legen Sie dafür im Web-Wurzelverzeichnis einen Ordner .well-known an und speichern die Datei darin. In WordPress geht das über den Dateizugriff per FTP oder über ein kleines Plugin, das den Pfad bereitstellt; wichtig ist nur, dass am Ende https://ihre-domain.de/.well-known/security.txt im Browser den reinen Text zeigt.
4. Prüfen. Rufen Sie die Adresse auf und kontrollieren Sie, dass die Datei über HTTPS lädt und als Text erscheint, nicht als Downloadangebot oder Fehlerseite.

Wer es genauer nimmt, kann die Datei zusätzlich mit einem OpenPGP-Schlüssel digital signieren. Der Standard empfiehlt das, weil es Fälschungen erschwert. Für den ersten Schritt ist es nicht nötig – eine unsignierte, korrekt platzierte Datei ist unendlich viel besser als gar keine.

In unserer Arbeit als Betreiber von Websites und Onlineshops gehört die Datei zum Standard, den wir mit ausrollen, inklusive gepflegtem Ablaufdatum und einem Kontakt, der auch bei uns aufläuft. Unser Prüfsystem, das wir über den KI-Agenten Conny Config automatisieren, kontrolliert dieselben Signale, an denen es bei security.txt hängt: fehlende Sicherheits-Header, abgelaufene Angaben, Konfigurationen, die aus dem Soll gelaufen sind.

Und im Nachweis-Register unserer SafeGuard-Module lässt sich festhalten, dass die Maßnahme existiert, wann sie zuletzt geprüft wurde und wann das nächste Ablaufdatum ansteht. Damit sorgen wir dafür, dass Ihre Dokumentation, auch Anforderungen wie NIS2 und der CRA künftig gerecht werden.