Security.txt: Schwachstellen verantwortungsvoll melden

Security.txt ist eine standardisierte Textdatei, die Webseitenbetreiber und Organisationen auf ihren Servern veröffentlichen, um Sicherheitsforschern einen klar definierten Meldeweg für entdeckte Schwachstellen bereitzustellen. Der Standard wurde im Mai 2022 als RFC 9116 von der Internet Engineering Task Force (IETF) verabschiedet und schafft damit eine verlässliche, maschinenlesbare Methode zur Kontaktaufnahme im Bereich der Schwachstellenmeldung.

Das Grundprinzip ist denkbar einfach: Ein Sicherheitsforscher, der eine Schwachstelle auf einer fremden Webseite oder Plattform entdeckt, muss bisher oft mühsam nach einem geeigneten Ansprechpartner suchen. Allgemeine Kontaktformulare, Vertriebspostfächer oder gar keine öffentlich erreichbare Adresse erschweren die Kommunikation erheblich. Security.txt löst dieses Problem durch eine zentral abgelegte Datei mit klaren Angaben zu Kontaktperson, Ablaufdatum und Melderichtlinien.

RFC 9116 - Der Standard im Überblick

RFC 9116 definiert das Format und die Platzierung der security.txt-Datei verbindlich. Der Standard legt fest:

Die Datei muss unter /.well-known/security.txt erreichbar sein (bevorzugter Pfad) oder alternativ unter /security.txt im Stammverzeichnis
Die Datei muss per HTTPS ausgeliefert werden - ein unverschlüsselter HTTP-Abruf ist nicht zulässig
Mindestens zwei Felder sind Pflicht: Contact und Expires
Alle weiteren Felder sind optional, werden aber empfohlen

Die Standardisierung über einen RFC ist bewusst gewählt: Sicherheitswerkzeuge, Scanner und automatisierte Systeme können die Datei maschinell auswerten und den Meldeweg ohne menschliches Zutun identifizieren. Damit wird Security.txt Teil einer größeren Infrastruktur für automatisierte Schwachstellenoffenlegung.

Aufbau der Datei

Eine vollständige security.txt-Datei besteht aus mehreren definierten Feldern. Kommentarzeilen beginnen mit #. Die Felder werden als Schlüssel-Wert-Paare angegeben.

# Security.txt für Beispiel GmbH
# Generiert gemäß RFC 9116

Contact: mailto:security@beispiel.de
Contact: https://beispiel.de/schwachstelle-melden/
Expires: 2027-01-01T00:00:00.000Z
Encryption: https://beispiel.de/pgp-key.asc
Preferred-Languages: de, en
Policy: https://beispiel.de/responsible-disclosure/
Acknowledgments: https://beispiel.de/hall-of-fame/
Canonical: https://beispiel.de/.well-known/security.txt

Contact

Das Contact-Feld ist Pflicht und gibt an, wie Sicherheitsmeldungen eingereicht werden sollen. Es sind mehrere Contact-Einträge erlaubt - zum Beispiel eine E-Mail-Adresse und zusätzlich ein Web-Formular. Wichtig ist, dass die angegebene Adresse von einem technisch versierten Team betreut wird, das Schwachstellenmeldungen fachgerecht bewerten kann.

Empfohlene Praxis: Eine dedizierte E-Mail-Adresse wie security@ oder psirt@ (Product Security Incident Response Team) anlegen, die nicht am allgemeinen Helpdesk-Postfach hängt.

Expires

Das Expires-Feld ist ebenfalls Pflicht und enthält das Datum, ab dem die Datei als veraltet gilt. Es wird im ISO-8601-Format angegeben. Das Ablaufdatum dient dazu, veraltete Kontaktinformationen zu erkennen - ein Sicherheitsforscher soll nicht versehentlich eine nicht mehr betreute Adresse kontaktieren. Die IETF empfiehlt, das Ablaufdatum maximal ein Jahr in der Zukunft zu setzen und die Datei regelmäßig zu erneuern.

Encryption

Das Encryption-Feld verweist auf einen öffentlichen PGP-Schlüssel, mit dem Sicherheitsmeldungen verschlüsselt übermittelt werden können. Gerade bei kritischen Schwachstellen ist die verschlüsselte Übertragung wichtig, da Details einer ungepatchten Lücke nicht im Klartext durch E-Mail-Postfächer laufen sollten. Der Verweis kann auf eine eigene URL oder einen Keyserver zeigen.

Preferred-Languages

Dieses optionale Feld gibt an, in welchen Sprachen Meldungen entgegengenommen werden. Für deutsche Unternehmen empfiehlt sich der Eintrag de, en, um sowohl deutschsprachige als auch internationale Sicherheitsforscher anzusprechen.

Policy

Das Policy-Feld verlinkt auf die Responsible-Disclosure-Richtlinie des Unternehmens. Dort sollte beschrieben sein, welche Systeme im Scope sind, wie lange das Unternehmen für das Patchen Zeit bekommt (typischerweise 90 Tage), ob eine Safe-Harbor-Zusage für Sicherheitsforscher gilt und ob eine Belohnung ausgelobt wird.

Acknowledgments

Über dieses Feld kann auf eine öffentliche Hall-of-Fame-Seite verwiesen werden, auf der gemeldete Forscher mit ihrer Zustimmung namentlich gelistet werden. Das hat zwei Effekte: Es motiviert Sicherheitsforscher, Schwachstellen zu melden statt zu verkaufen, und es signalisiert der Community, dass das Unternehmen professionell mit Meldungen umgeht.

Canonical

Das Canonical-Feld gibt die autoritative URL der Datei an. Wenn die Datei unter mehreren URLs erreichbar ist (z.B. sowohl unter security.txt als auch unter /.well-known/security.txt), verhindert dieses Feld Verwirrung über die maßgebliche Version.

Einrichtung unter /.well-known/security.txt

Der Pfad /.well-known/ ist ein standardisierter Verzeichnispfad für Metadaten-Ressourcen einer Domain (definiert in RFC 5785). Dort liegen unter anderem auch /.well-known/acme-challenge/ für Let's-Encrypt-Zertifikate oder /.well-known/openid-configuration für OpenID Connect.

Die Einrichtung der security.txt ist technisch unkompliziert:

Apache (.htaccess oder Konfigurationsdatei):

<Files "security.txt">
    Header set Content-Type "text/plain; charset=utf-8"
</Files>

Nginx:

location /.well-known/security.txt {
    default_type text/plain;
    alias /var/www/html/.well-known/security.txt;
}

Statische Webseiten (z.B. mit Astro, Next.js oder Hugo): Die Datei wird direkt im public-Verzeichnis unter public/.well-known/security.txt abgelegt und bei der Build-Ausgabe automatisch unter dem richtigen Pfad ausgeliefert.

Ein kostenloser Online-Generator auf securitytxt.org erstellt die Datei mit korrektem Format - inklusive optionaler PGP-Signatur der gesamten Datei. Die digitale Signatur verhindert, dass Angreifer die Datei manipulieren und einen gefälschten Kontaktpfad einschleusen.

Vorteile für Unternehmen

Direkter Meldeweg reduziert Reaktionszeit

Sicherheitsforscher, die Schwachstellen in Produktionssystemen entdecken, stehen vor der Frage: An wen melden? Ohne security.txt enden Meldungen häufig bei allgemeinen Vertriebspostfächern, sozialen Medien oder werden gar nicht abgeschickt. Die resultierende Lücke bleibt ungepacht. Security.txt schließt diese Informationslücke und verkürzt den Weg von der Entdeckung zur Behebung erheblich.

Schutz vor Missverständnissen und rechtlichen Risiken

Es kommt regelmäßig vor, dass Unternehmen Sicherheitsforschern mit rechtlichen Schritten drohen, obwohl diese in gutem Glauben gehandelt haben. Eine klare Responsible-Disclosure-Richtlinie in Verbindung mit einer security.txt schafft die rechtliche Grundlage für eine Safe-Harbor-Regelung: Das Unternehmen erklärt verbindlich, dass gutgläubige Forscher, die den beschriebenen Prozess einhalten, keine Strafanzeige zu erwarten haben.

Compliance und Reifegrad

Die DSGVO verpflichtet Unternehmen zwar nicht explizit zur Einrichtung einer security.txt, doch Datenschutzbehörden und Auditoren werten einen strukturierten Schwachstellen-Meldeprozess als positives Signal bei der Bewertung des Informationssicherheits-Reifegrads. Im Kontext einer ISO-27001-Zertifizierung ist ein funktionierender Vulnerability-Disclosure-Prozess (Anhang A.12.6 / A.8.8 in ISO 27001:2022) eine Anforderung, die eine security.txt direkt unterstützt.

Vertrauenssignal gegenüber Kunden und Partnern

Unternehmen, die eine security.txt betreiben, signalisieren öffentlich: "Wir nehmen Sicherheitsmeldungen ernst und haben einen Prozess, um damit umzugehen." Das ist ein messbares Vertrauenssignal gegenüber Kunden, Partnern und potenziellen Mitarbeitern aus dem Sicherheitsumfeld.

Verbreitung und Adoption

Eine Auswertung der Tranco-Liste - einer wissenschaftlichen Rangliste populärer Webseiten - zeigt den Stand der Verbreitung:

Bei einer Analyse von über einer Million Domains hatten lediglich 4.903 Domains (0,49 Prozent) eine gültige security.txt. Im deutschsprachigen Bereich lagen die Zahlen etwas besser: Von 25.708 analysierten .de-Domains hatten 458 (1,78 Prozent) eine security.txt eingerichtet. Deutschland belegt damit in der TLD-Rangliste den zweiten Platz hinter .com in absoluten Zahlen, was jedoch weniger an einer besonders hohen Verbreitung als an der schieren Anzahl deutscher Domains liegt.

Prozentual betrachtet führt Schweden: 6,92 Prozent aller .se-Domains boten eine security.txt an. Dies hängt vermutlich mit der hohen Sensibilisierung für IT-Sicherheit in nordischen Ländern zusammen sowie mit der Aktivität von Behörden wie dem schwedischen NCSC.

Das Fazit der Messung ist klar: Die Verbreitung von security.txt ist auch mehrere Jahre nach der RFC-Verabschiedung niedrig. Der Aufwand der Einrichtung - eine Textdatei an der richtigen Stelle ablegen - steht in keinem Verhältnis zur geringen Adoption. Viele Unternehmen kennen den Standard schlicht nicht.

Responsible Disclosure vs. Full Disclosure

Die Art, wie Sicherheitslücken nach der Entdeckung behandelt werden, hat erhebliche Auswirkungen auf die Sicherheit aller Beteiligten. Security.txt ist ein Werkzeug im Kontext von Responsible Disclosure - es lohnt sich, dieses Konzept vom entgegengesetzten Ansatz abzugrenzen.

Responsible Disclosure (Koordinierte Offenlegung)

Bei Responsible Disclosure (auch Coordinated Vulnerability Disclosure, CVD) informiert der Entdecker zunächst den Betreiber und gibt ihm eine angemessene Frist zur Behebung der Schwachstelle, bevor Details öffentlich gemacht werden. Die übliche Frist beträgt 90 Tage - ein von Google Project Zero etablierter Standard, dem sich auch andere Forscher und Organisationen angeschlossen haben.

Der Ablauf im Idealfall:

Entdecker meldet die Schwachstelle vertraulich an den Betreiber (über security.txt)
Betreiber bestätigt den Eingang und startet die Analyse
Innerhalb von 90 Tagen wird ein Patch entwickelt und ausgerollt
Entdecker und Betreiber koordinieren die öffentliche Bekanntmachung
CVE-Nummer wird beantragt, Betreiber bedankt sich öffentlich (optional: Hall of Fame)

Responsible Disclosure ist die breit akzeptierte Norm in der Sicherheitsgemeinschaft. Sie schützt Nutzer, weil Schwachstellen gepatcht werden bevor Angreifer sie ausnutzen können. Sie schützt Forscher, weil der koordinierte Prozess einer rechtlichen Grauzone entgegenwirkt.

Full Disclosure

Full Disclosure bedeutet, alle Details einer Schwachstelle sofort und ohne vorherige Benachrichtigung des Betreibers zu veröffentlichen. Die Befürworter argumentieren, dass dies maximalen öffentlichen Druck erzeugt und Betreiber zwingt, schnell zu patchen. Kritiker weisen darauf hin, dass Full Disclosure ein Zeitfenster öffnet, in dem Angreifer die bekannte Lücke ausnutzen können, bevor ein Patch verfügbar ist.

Full Disclosure ist heute die Ausnahme und wird meist nur dann gewählt, wenn ein Betreiber monatelang keine Reaktion zeigt oder einen Patch trotz Kenntnis der Schwachstelle verweigert. In Deutschland ist Full Disclosure rechtlich riskant: Die Veröffentlichung technischer Details einer ungepatchten Schwachstelle kann als Beihilfe zur Computersabotage gewertet werden.

Bug-Bounty-Programme als Erweiterung

Neben Responsible Disclosure gibt es Bug-Bounty-Programme, bei denen Unternehmen finanzielle Belohnungen für gemeldete Schwachstellen ausloben. Plattformen wie HackerOne, Bugcrowd oder Intigriti vermitteln zwischen Unternehmen und Sicherheitsforschern. Security.txt kann auf ein solches Programm verweisen, wenn das Unternehmen einen formalisierten Prozess mit Belohnungsstruktur betreibt.

Praktische Checkliste

Einrichtung security.txt:

□ Datei erstellt mit gültigem Format (RFC 9116)?
□ Pfad /.well-known/security.txt erreichbar per HTTPS?
□ Contact-Feld: dediziertes security@-Postfach, kein allgemeines Info-Postfach?
□ Expires-Feld: gesetzt und maximal 1 Jahr in der Zukunft?
□ Encryption-Feld: PGP-Schlüssel veröffentlicht und gepflegt?
□ Policy-Feld: Responsible-Disclosure-Richtlinie mit Safe-Harbor-Klausel vorhanden?
□ Datei digital signiert (empfohlen)?
□ Interner Prozess definiert: Wer bearbeitet eingehende Meldungen? In welcher Frist?
□ Datei in Kalender eingetragen: Erneuerung vor dem Expires-Datum?