security.txt nach RFC 9116: Vulnerability-Disclosure-Policy praktisch umsetzen

1. Das Problem: fehlender Meldeweg für gefundene Schwachstellen

Sicherheitsforscher, die im Rahmen eines Audits, eines Bug-Bounty-Programms oder auch nur zufällig beim Surfen auf eine Schwachstelle stossen, brauchen einen klaren, schnellen Weg, um diese verantwortungsvoll zu melden. Fehlt dieser Weg, bleiben meist nur schlechte Alternativen: eine E-Mail an eine generische info@-Adresse, die im Marketing-Postfach verschwindet, ein Ticket im öffentlichen Support-System, das jeder mitlesen kann, oder im schlimmsten Fall ein Tweet mit Details zur Schwachstelle, weil kein anderer Kanal reagiert hat.

Diese Unsicherheit kostet auf beiden Seiten Zeit und Vertrauen. Betreiber erfahren von kritischen Lücken oft zu spät oder gar nicht auf offiziellem Weg, während gutwillige Melder frustriert aufgeben oder aus Mangel an Alternativen den öffentlichen Weg wählen. Genau diese Lücke schließt RFC 9116 mit einer Konvention, die so simpel ist, dass sie sich in wenigen Minuten umsetzen lässt, aber in der Praxis einen spürbaren Unterschied macht, wie schnell ein Unternehmen von einer Schwachstelle erfährt.

# /.well-known/security.txt -- Minimalbeispiel nach RFC 9116
Contact: mailto:security@beispiel-shop.de
Contact: https://beispiel-shop.de/security-melden
Expires: 2026-12-31T23:59:59.000Z
Encryption: https://beispiel-shop.de/.well-known/pgp-key.txt
Preferred-Languages: de, en
Canonical: https://beispiel-shop.de/.well-known/security.txt
Policy: https://beispiel-shop.de/security-policy
Acknowledgments: https://beispiel-shop.de/security-hall-of-fame

2. Die Grundidee von RFC 9116 in Kürze

RFC 9116 wurde im April 2022 von der IETF als offizieller Standard veröffentlicht und löst den vorherigen Entwurfsstatus ab, unter dem die Konvention bereits seit Jahren informell genutzt wurde. Der Kern der Idee ist denkbar simpel: Eine Webanwendung stellt unter dem festen, gut auffindbaren Pfad /.well-known/security.txt eine reine Textdatei bereit, die in einem klar definierten Feld-Wert-Format die wichtigsten Informationen für Sicherheitsmelder bündelt.

Der Pfad /.well-known/ ist selbst durch RFC 8615 standardisiert und dient als generischer Namensraum für maschinenlesbare Metadaten von Webseiten, in dem neben security.txt auch andere Well-Known-Ressourcen wie ACME-Challenges oder OAuth-Metadaten liegen. Automatisierte Tools, Sicherheitsscanner und auch menschliche Forscher prüfen diesen Pfad inzwischen routinemässig als ersten Schritt, bevor sie überhaupt eine Schwachstelle melden, weil er als verlässliche, standardisierte Quelle gilt.

3. Pflichtfelder: Contact und Expires im Detail

RFC 9116 verlangt zwingend mindestens ein Contact-Feld und genau ein Expires-Feld, alle anderen Felder sind optional. Das Contact-Feld gibt an, wie Melder ein Unternehmen erreichen können, wobei mehrere Contact-Zeilen erlaubt sind und nach Priorität sortiert aufgelistet werden sollten. Zulässig sind E-Mail-Adressen im mailto:-Schema, Telefonnummern im tel:-Schema sowie beliebige HTTPS-URLs, etwa zu einem dedizierten Meldeformular oder einem Bug-Bounty-Programm auf einer Plattform wie HackerOne oder Intigriti.

Das Expires-Feld gibt im ISO-8601-Format an, bis wann die Datei als gültig betrachtet werden soll, und zwingt Betreiber dazu, die Angaben regelmässig zu überprüfen und zu erneuern. Eine abgelaufene security.txt-Datei signalisiert Werkzeugen und Forschern, dass die enthaltenen Kontaktdaten möglicherweise veraltet sind, was in der Praxis ein wirksamer Mechanismus gegen verwaiste, jahrelang nicht gepflegte Angaben ist. Ein sinnvoller Rhythmus ist ein Ablaufdatum von sechs bis zwölf Monaten in der Zukunft, kombiniert mit einem wiederkehrenden Kalendereintrag zur Erneuerung.

4. Optionale Felder für eine vollständige Policy

Neben den beiden Pflichtfeldern definiert RFC 9116 mehrere optionale Felder, die eine security.txt-Datei deutlich nützlicher machen. Das Feld Policy verweist auf eine ausführliche Vulnerability-Disclosure-Policy, in der Umfang, erlaubte Testmethoden, Ausschlusskriterien und der Umgang mit gefundenen Daten geregelt sind. Das Feld Acknowledgments verlinkt eine Seite, auf der Melder nach erfolgreicher, verantwortungsvoller Offenlegung öffentlich gewürdigt werden, was als nicht-monetärer Anreiz für viele Sicherheitsforscher durchaus relevant ist.

Das Feld Preferred-Languages gibt an, in welchen Sprachen Meldungen bevorzugt entgegengenommen werden, das Feld Canonical benennt die autoritative URL der Datei selbst und schützt vor manipulierten Kopien auf Spiegelservern, und das Feld Hiring kann auf offene Stellen im Security-Team verweisen. Alle Felder lassen sich mehrfach angeben, sodass etwa mehrere Kontaktwege oder mehrere Policy-Dokumente für unterschiedliche Produktbereiche nebeneinander existieren können.

5. Signierung mit PGP: Integrität der Angaben absichern

Ohne zusätzlichen Schutz könnte ein Angreifer mit Zugriff auf den Webserver eine gefälschte security.txt-Datei platzieren, um Meldungen echter Schwachstellen abzufangen oder Forscher auf eine falsche Fährte zu locken. RFC 9116 sieht deshalb vor, die Datei optional als OpenPGP-Cleartext-Signatur zu signieren, sodass jede Manipulation am Inhalt sofort erkennbar wird, sobald jemand die Signatur gegen den öffentlichen Schlüssel prüft.

In der Praxis wird der öffentliche PGP-Schlüssel selbst über das Encryption-Feld referenziert und ebenfalls unter einem Well-Known-Pfad bereitgestellt, sodass Forscher sowohl die Signatur der security.txt-Datei prüfen als auch verschlüsselt mit dem Sicherheitsteam kommunizieren können. Diese Kombination aus Signierung und Verschlüsselung stellt sicher, dass sensible Schwachstellendetails nicht im Klartext über unsichere Kanäle wandern und dass die Kontaktangaben selbst vertrauenswürdig bleiben.

6. Häufige Fehler bei der praktischen Umsetzung

Der häufigste Fehler ist eine security.txt-Datei, die zwar einmalig angelegt, danach aber nie wieder gepflegt wird, bis das Expires-Datum lange in der Vergangenheit liegt und Kontaktadressen nicht mehr funktionieren. Ein zweiter häufiger Fehler ist die falsche Platzierung der Datei außerhalb von /.well-known/, etwa direkt im Root-Verzeichnis, was zwar von manchen Tools noch als Fallback akzeptiert wird, aber dem RFC-Standard widerspricht und von automatisierten Scannern häufig nicht mehr gefunden wird.

Ein dritter Fehler ist eine security.txt-Datei ohne erkennbare Verbindung zur tatsächlichen Disclosure-Policy, sodass Melder zwar eine Kontaktadresse finden, aber im Unklaren bleiben, welche Testmethoden erlaubt sind und wie lange eine Reaktion dauert. Ohne begleitende Policy bleibt die Datei ein reiner Formalismus statt eines funktionierenden Meldewegs, und Sicherheitsforscher zögern eher, überhaupt einen ersten Kontakt herzustellen.

7. Den internen Reaktionsprozess auf eine Meldung definieren

Eine security.txt-Datei ist nur so wirksam wie der interne Prozess, der auf eine eingehende Meldung folgt. Sinnvoll ist ein definierter Ablauf mit klaren Fristen: eine automatische Eingangsbestätigung innerhalb weniger Stunden, eine erste fachliche Einschätzung innerhalb weniger Werktage und eine transparente Kommunikation über den weiteren Zeitplan bis zur Behebung. Diese Fristen sollten idealerweise direkt in der verlinkten Policy stehen, damit Melder eine realistische Erwartungshaltung haben.

Ebenso wichtig ist eine klare interne Verantwortlichkeit: Wer liest die eingehenden Meldungen, wer bewertet den Schweregrad, und wer entscheidet über Priorität und Zeitrahmen der Behebung? Ohne definierte Zuständigkeiten landen Meldungen leicht zwischen mehreren Teams und werden verzögert bearbeitet, was das Vertrauen der meldenden Person in den gesamten Prozess untergräbt und künftige, freiwillige Meldungen unwahrscheinlicher macht.

8. Automatisierte Pflege statt manüller Einmalpflege

Da das Expires-Feld regelmässige Erneuerung verlangt, lohnt sich eine automatisierte Lösung statt manüller Pflege in einem Kalender. In vielen Projekten wird die security.txt-Datei deshalb aus einer zentralen Konfigurationsquelle generiert, etwa als Teil des Deployment-Prozesses, wobei das Ablaufdatum automatisch auf einen festen Abstand in der Zukunft gesetzt wird und die Signatur bei jedem Build neu erzeugt wird, sofern sich Inhalte geändert haben.

Für Teams mit mehreren Domains oder Subdomains empfiehlt sich zusätzlich ein zentrales Monitoring, das regelmässig prüft, ob die Datei unter allen relevanten Hosts erreichbar, syntaktisch korrekt und nicht abgelaufen ist. Ein einfacher automatisierter Check, der täglich per Cron-Job das Expires-Datum gegen das aktülle Datum prüft und bei Unterschreitung einer Vorlaufzeit eine interne Warnung auslöst, verhindert zuverlässig, dass die Datei unbemerkt veraltet.

9. Fazit: kleiner Aufwand mit spürbarem Sicherheitsgewinn

security.txt nach RFC 9116 ist eine der Maßnahmen im Security-Bereich mit dem besten Verhältnis von Aufwand zu Wirkung. Eine einzige Textdatei, in wenigen Minuten angelegt, gibt Sicherheitsforschern einen klaren, verlässlichen Weg, gefundene Schwachstellen verantwortungsvoll zu melden, statt sie mangels Alternative öffentlich zu machen oder ganz zu verschweigen.

Der eigentliche Wert entsteht jedoch erst durch die begleitenden Prozesse: eine klare Policy, definierte Reaktionsfristen, eine verantwortliche interne Stelle und eine automatisierte Pflege des Ablaufdatums. Wer diese Bausteine zusammen umsetzt, senkt spürbar die Wahrscheinlichkeit, dass eine gefundene Schwachstelle den falschen Weg an die Öffentlichkeit findet, bevor eine Behebung überhaupt möglich war.

10. Zusammenfassung

11. FAQ: security.txt nach RFC 9116: Das Wichtigste auf einen Blick