security.txt ist kein Sicherheitsprogramm
Warum eine Kontaktdatei allein keine Schwachstellen löst – und welche Prozesse nötig sind, damit Sicherheitsmeldungen wirklich ankommen, bewertet und behoben werden.
Jemand findet eine Sicherheitslücke auf Ihrer Website. Die Person möchte sie verantwortungsvoll melden – findet aber nur ein allgemeines Kontaktformular, eine Vertriebsadresse oder gar keinen passenden Ansprechpartner.
Vielleicht landet die Nachricht im Spam. Vielleicht hält der Support sie für Werbung. Vielleicht wird sie an eine Agentur weitergeleitet, die das Projekt seit Monaten nicht mehr betreut. Die Schwachstelle existiert währenddessen weiter.
Eine security.txt-Datei kann dieses erste Problem lösen: Sie zeigt automatisiert und menschenlesbar, wie Sicherheitsfunde gemeldet werden sollen. Aber sie löst nicht das zweite, viel größere Problem: Was passiert nach dem Eingang?
Der Mythos: „Wir haben security.txt, also sind wir vorbereitet“
RFC 9116 definiert security.txt als maschinenlesbares Format für Informationen zur Schwachstellenmeldung. Die Datei gehört bei Webdiensten unter /.well-known/security.txt, wird über HTTPS ausgeliefert und enthält mindestens einen Kontakt sowie ein Ablaufdatum.
Das ist sinnvoll. Es schafft einen eindeutigen Eingangskanal und reduziert die Wahrscheinlichkeit, dass gut gemeinte Hinweise irgendwo im Unternehmen verschwinden.
Der RFC stellt jedoch ebenfalls klar: Die Datei ergänzt einen Disclosure-Prozess. Sie ersetzt ihn nicht.
Eine perfekte Kontaktdatei hilft wenig, wenn:
- das Postfach niemand überwacht,
- die hinterlegte Person das Unternehmen verlassen hat,
- Meldungen nicht bestätigt werden,
- niemand technische Verantwortung übernimmt,
- es keine Priorisierung oder Frist gibt,
- externe Dienstleister nicht erreichbar sind,
- nach der Behebung keine Rückmeldung erfolgt.
Dann ist security.txt nur ein gut ausgeschilderter Briefkasten, der nie geleert wird.
Was eine korrekte security.txt mindestens leisten sollte
1. Der richtige Pfad
Die maßgebliche Datei sollte unter https://ihre-domain.de/.well-known/security.txt erreichbar sein. Eine alte Datei unter /security.txt kann aus Kompatibilitätsgründen weiterleiten, sollte aber nicht zur parallelen, widersprüchlichen Quelle werden.
2. Ein funktionierender Kontakt
Das Feld Contact muss auf einen tatsächlich betreuten Kanal zeigen, zum Beispiel eine dedizierte E-Mail-Adresse oder ein sicheres Meldeformular.
Testen Sie den Kanal regelmäßig von außen. Eine Adresse ist nicht funktionsfähig, nur weil sie im DNS oder Mail-System existiert.
3. Ein aktuelles Ablaufdatum
Expires ist verpflichtend. Es signalisiert, wann die Angaben als veraltet gelten. RFC 9116 empfiehlt, das Datum weniger als ein Jahr in die Zukunft zu setzen.
Das zwingt zu einer einfachen, aber wichtigen Wartungsfrage: Stimmen Ansprechpartner, Policy und Schlüssel noch?
4. Ein klarer Geltungsbereich
Über Policy kann eine Seite verlinkt werden, die erklärt, welche Systeme umfasst sind, welche Tests akzeptiert werden und wie der Prozess abläuft. Die Datei selbst gilt grundsätzlich für den Host, unter dem sie abgerufen wurde – nicht automatisch für jede Subdomain.
5. Sichere Kommunikationsmöglichkeiten
Für sensible Details kann Encryption auf einen geeigneten Schlüssel oder sicheren Kanal verweisen. Eine Verschlüsselungsmöglichkeit ist jedoch nur nützlich, wenn der Schlüssel aktuell ist und intern jemand die Nachricht entschlüsseln kann.
6. Eine kanonische Adresse
Das Feld Canonical hilft dabei, den vorgesehenen Speicherort der Datei zu bestätigen. Wird es verwendet, muss die abgerufene Adresse dort korrekt enthalten sein.
Sieben operative Fragen, die wichtiger sind als die Datei
NIST beschreibt Vulnerability Disclosure als einen Rahmen zum Annehmen, Bewerten, Verwalten und Kommunizieren von Schwachstellenmeldungen. Genau diese Prozesskette sollte hinter dem Kontakt stehen.
1. Wer liest neue Meldungen?
Es braucht eine betreute Queue, nicht nur ein persönliches Postfach. Vertretung bei Urlaub, Krankheit und Personalwechsel gehört dazu.
2. Wie schnell wird der Eingang bestätigt?
Eine kurze Bestätigung zeigt der meldenden Person, dass der Bericht angekommen ist und nicht erneut über andere Kanäle eskaliert werden muss.
3. Wer prüft die technische Reproduzierbarkeit?
Nicht jede Meldung ist vollständig oder korrekt. Es muss klar sein, wer betroffene Systeme identifiziert, Schritte reproduziert und zusätzliche Informationen sicher anfordert.
4. Wie wird Schwere und Dringlichkeit bewertet?
Ein kosmetischer Header-Hinweis braucht einen anderen Ablauf als eine öffentlich ausnutzbare Authentifizierungsumgehung. Priorisierung sollte Exposition, Ausnutzbarkeit, Datenwirkung und vorhandene Schutzmaßnahmen berücksichtigen.
5. Wer darf Änderungen auslösen?
Bei extern betreuten Websites muss geklärt sein, ob das Unternehmen, die Agentur, der Hosting-Anbieter oder ein SaaS-Dienst reagieren muss. Fehlende Zuständigkeit ist häufig der eigentliche Zeitverlust.
6. Wie wird sicher kommuniziert?
Berichte können Exploit-Schritte, Screenshots, Kontodaten oder andere sensible Details enthalten. Sie gehören nicht unkontrolliert in normale Tickets, offene Chatkanäle oder weitergeleitete E-Mail-Ketten.
7. Wie wird der Fall abgeschlossen?
Nach einer Korrektur sollten Reproduktion, Deployment, Regressionstest und Rückmeldung dokumentiert werden. CERT/CC betont bei koordinierter Offenlegung die Zusammenarbeit zwischen meldender und betroffener Seite mit dem Ziel, Risiken zu reduzieren und Abhilfen bereitzustellen.
Red Flags bei bestehenden Dateien
Prüfen Sie Ihre security.txt einmal wie eine externe Person:
- Der Pfad liefert eine HTML-Fehlerseite statt Klartext.
- Der Server antwortet mit 200, aber der Inhalt ist eine generische Homepage.
- Das Ablaufdatum liegt in der Vergangenheit.
- Die Kontaktadresse erzeugt einen Bounce.
- Die Policy verweist auf eine gelöschte oder private Seite.
- Ein alter Agenturkontakt ist weiterhin eingetragen.
- Hauptdomain und Subdomains liefern widersprüchliche Angaben.
- Eine Weiterleitung endet auf einer fremden Domain.
- Der PGP-Schlüssel ist nicht mehr verfügbar oder niemand kann ihn nutzen.
- Es existiert kein internes Ticket-, Eskalations- oder Verantwortungsmodell.
Besonders tückisch ist eine formal gültige Datei mit organisatorisch falschen Angaben. Automatische Scanner melden dann „vorhanden“, obwohl echte Meldungen weiterhin verloren gehen.
Ein pragmatischer Minimalprozess für kleine Teams
Auch ein kleines Unternehmen braucht kein Security Operations Center, um Meldungen ordentlich zu behandeln. Ein schlanker Ablauf kann so aussehen:
- Dedizierte Adresse oder Formular mit mindestens zwei verantwortlichen Empfängern.
- Automatische Eingangsbestätigung ohne Zusage einer konkreten Behebung.
- Internes Ticket mit vertraulicher Sichtbarkeit und Zeitstempel.
- Erste technische Einordnung innerhalb eines definierten Zeitfensters.
- Benannte verantwortliche Person für Koordination und Kommunikation.
- Sicherer Kanal für zusätzliche Details.
- Dokumentierte Entscheidung zu Priorität, Abhilfe und Veröffentlichung.
- Regressionstest nach dem Fix.
- Abschlussmeldung an die meldende Person, soweit sinnvoll.
- Vierteljährlicher Test von Datei, Postfach, Policy und Eskalationsweg.
Der Prozess muss nicht perfekt sein. Er muss auffindbar, betreut und wiederholbar sein.
Was Website-Pflichtencheck prüfen würde
Ein technischer und operativer Check betrachtet nicht nur, ob /.well-known/security.txt existiert. Geprüft werden können:
- korrekter Pfad, HTTPS, Statuscode und Content-Type,
- Pflichtfelder, Ablaufdatum und kanonische Adresse,
- Erreichbarkeit der Kontaktwege,
- Konsistenz über Hauptdomain und relevante Subdomains,
- Weiterleitungen und externe Abhängigkeiten,
- Aktualität von Policy und Verschlüsselungsangaben,
- Zuständigkeiten nach Agentur- oder Personalwechseln,
- Eingang, Eskalation, Dokumentation und Abschluss eines Testfalls.
Das Ziel ist keine dekorative Best-Practice-Datei. Das Ziel ist ein belastbarer Weg von „Jemand hat etwas gefunden“ zu „Wir haben es verstanden, priorisiert und sauber behoben“.
Eine Sicherheitsmeldung ist nur dann ein Vorteil, wenn Ihre Organisation sie tatsächlich empfangen und verarbeiten kann. security.txt zeigt die Tür. Der Prozess dahinter entscheidet, ob jemand öffnet.