security.txt und Vulnerability Disclosure einrichten 2026

Was security.txt ist und welches Problem RFC 9116 löst

security.txt ist eine maschinen- und menschenlesbare Textdatei, die an einem standardisierten Ort liegt: `1 Sie beantwortet eine einzige, aber entscheidende Frage: Wie meldet ein externer Finder eine Sicherheitslücke, ohne raten zu müssen? Vor RFC 9116 mussten Forschende den richtigen Ansprechpartner über Kontaktformulare, LinkedIn oder allgemeine info@-Adressen suchen — ein Reibungspunkt, der dazu führt, dass Meldungen im Spam landen oder gar nicht erst abgeschickt werden.

Der Standard wurde 2022 als RFC 9116 von der IETF verabschiedet (IETF 2022). Er definiert ein einfaches Schlüssel-Wert-Format: Jede Zeile besteht aus einem Feldnamen, einem Doppelpunkt und einem Wert. Die Datei muss über HTTPS ausgeliefert werden und am kanonischen Pfad /.well-known/security.txt liegen — ein zusätzlicher Fallback im Web-Root (/security.txt) ist zulässig, aber /.well-known/ ist der vorgesehene Ort. Damit ist die Information genau dort, wo automatisierte Scanner und Forschende sie zuerst suchen.

Der Nutzen ist asymmetrisch: Der Aufwand für die Veröffentlichung liegt bei Minuten, der Nutzen im Ernstfall bei Stunden oder Tagen gesparter Reaktionszeit. Ein Forscher, der einen Meldekanal findet, meldet eher koordiniert — statt die Lücke aus Frust öffentlich zu machen. 2024 sorgte ein prominenter Fall für Aufsehen, bei dem ein Forscher nach erfolgloser Kontaktaufnahme öffentlich mit der koordinierten Offenlegung brach (DARKNAVY 2024). Ein klarer Kanal senkt genau diese Reibung.

Wichtig ist die realistische Einordnung: security.txt ersetzt kein Sicherheitsprogramm. Die Datei erklärt nicht, wie sicher Ihre Website ist, sondern nur, wie man Sie im Schadensfall erreicht. Sie ist damit eine organisatorische Maßnahme, kein technischer Schutz. Ihr Wert entsteht erst im Zusammenspiel mit einem gepflegten Postfach, einer hinterlegten Richtlinie und einem Prozess, der eingehende Meldungen tatsächlich bearbeitet. Eine Datei ohne dahinterliegenden Ablauf erzeugt Erwartungen, die im Ernstfall enttäuscht werden — und kann das Vertrauen meldender Forschender beschädigen.

Die Felder von security.txt: Pflicht, optional und sinnvoll

RFC 9116 unterscheidet zwischen wenigen Pflichtfeldern und einer Reihe optionaler Felder. Zwingend erforderlich sind nur zwei: Contact (ein- oder mehrfach) und Expires (genau einmal). Alle weiteren Felder erhöhen den Nutzen, sind aber nicht vorgeschrieben (IETF 2022). Die folgende Übersicht zeigt die wichtigsten Felder und ihren Zweck.

Contact: mailto:security@ihre-domain.de
Contact: 1
Expires: 2026-12-31T23:59:00.000Z
Encryption: 2
Policy: 3
Acknowledgments: 4
Preferred-Languages: de, en
Canonical: 5

RFC 9116 empfiehlt zusätzlich, die Datei mit einem PGP-Schlüssel zu signieren (-----BEGIN PGP SIGNATURE-----), damit ihre Echtheit überprüfbar ist. Das BSI nennt in seiner CVD-Leitlinie genau diese Kombination — security.txt mit Kontaktadresse, PGP-Schlüssel und Melde-URL — als empfohlene Praxis (BSI). Die Signatur ist kein Pflichtfeld, aber bei hohem Schutzbedarf sinnvoll, weil sie eine manipulierte Datei erkennbar macht.

Coordinated Vulnerability Disclosure: Der Prozess hinter der Datei

security.txt ist nur die Eingangstür. Dahinter steht der eigentliche Prozess: Coordinated Vulnerability Disclosure (CVD). CVD beschreibt, wie eine gemeldete Schwachstelle zwischen Finder und Betreiber koordiniert behoben wird, bevor Details öffentlich werden. Das BSI hat dafür eine eigene CVD-Leitlinie veröffentlicht und betreibt eine zentrale Meldestelle (BSI). Auf EU-Ebene fordert der Cyber Resilience Act von Herstellern digitaler Produkte ausdrücklich eine Coordinated-Vulnerability-Disclosure-Richtlinie (CRA, EU).

Ein belastbarer CVD-Prozess umfasst mehr als eine E-Mail-Adresse. Er regelt, wie Eingänge bestätigt werden, in welcher Frist eine erste Rückmeldung erfolgt, wie der Status kommuniziert wird und unter welchen Bedingungen ein sogenannter Safe Harbor gilt — also die Zusage, dass gutgemeinte Forschung nicht rechtlich verfolgt wird. Die OWASP Vulnerability Disclosure Cheat Sheet beschreibt diese Bausteine als Mindeststandard für Betreiber (OWASP).

Der Unterschied zwischen CVD und der früher verbreiteten Full Disclosure liegt im Zeitpunkt der Veröffentlichung. Bei der koordinierten Offenlegung erhält der Betreiber eine angemessene Frist, die Lücke zu schließen, bevor Details bekannt werden — typischerweise in einem Rahmen von Wochen bis wenigen Monaten, abhängig von Schweregrad und Komplexität. Bleibt die Reaktion aus, behalten sich viele Forschende die Veröffentlichung dennoch vor, um Nutzer zu schützen. Genau deshalb ist eine verlässliche Erstantwort so wichtig: Sie hält den Prozess koordiniert und verhindert, dass aus Frustration eine unkontrollierte Offenlegung wird (DARKNAVY 2024).

Wie weit die Verbreitung wirklich ist — und woran es hakt

Die Adoptionszahlen sind ernüchternd, aber im Aufwärtstrend. Unter den Top-1-Mio.-Domains stieg der Anteil mit security.txt von 0,7 % (6.816 Domains) im April 2024 auf 1,25 % (12.510 Domains) im Jahr 2025 (URIports 2025) — fast eine Verdopplung, aber weiterhin ein einstelliger Promillebereich über das gesamte Domain-Universum hinweg. Selbst bei großen IT-Unternehmen ist die Lücke groß: In einer Stichprobe lieferten 39 von 50 untersuchten IT-Konzernen (78 %) keine RFC-9116-konforme security.txt aus (Hartwork Blog 2025).

Noch wichtiger als die Existenz ist die Qualität. Von den Domains, die überhaupt eine security.txt veröffentlichen, erfüllen nur 44 % die RFC-Vorgaben (URIports 2025). Die häufigsten Fehlerquellen: ein abgelaufenes oder fehlendes Expires-Feld, fehlende HTTPS-Auslieferung, ein falscher Pfad außerhalb von /.well-known/ oder eine Datei mit falschem Content-Type. Eine formal vorhandene, aber fehlerhafte Datei vermittelt trügerische Sicherheit. Hinzu kommt, dass ein Teil der gemessenen Verbreitung gar nicht auf bewusste Sicherheitsentscheidungen zurückgeht, sondern auf Plattform-Automatik bei Hostern und CMS — sie sagt also wenig über die Pflege im Einzelfall aus (URIports 2025).

Cyber Resilience Act und NIS2: Warum CVD zur Pflicht wird

Der regulatorische Rückenwind ist erheblich. Der EU Cyber Resilience Act (CRA) verlangt von Herstellern von Produkten mit digitalen Elementen eine Coordinated-Vulnerability-Disclosure-Richtlinie samt klarem Meldekanal — die vollständige Anwendung der Anforderungen gilt ab dem 11. Dezember 2027 (CRA, EU). Die CVD-Richtlinie ist dabei eine von acht Vulnerability-Handling-Anforderungen, die bis dahin umgesetzt sein müssen (CRA, Article 14).

Der CRA empfiehlt ausdrücklich, Sicherheitsrichtlinien auch in maschinenlesbarer Form zu veröffentlichen — und genau dafür ist security.txt das etablierte Format. Parallel hat die EU 2025 die European Vulnerability Database (EUVD) der ENISA gestartet, um Informationen zu Schwachstellen im EU-Markt zu bündeln (ENISA). Laut ENISA waren Anfang 2025 zudem 21,3 % der Sicherheitsvorfälle in Europa auf die Ausnutzung von Schwachstellen zurückzuführen (ENISA) — ein direkter Beleg, warum ein funktionierender Meldeweg zählt.

Auch national wird der Rahmen konkreter: Die NIS2-Richtlinie und ihre Umsetzung erhöhen die Anforderungen an das Schwachstellen-Handling vieler Unternehmen. Das BSI empfiehlt security.txt mit Kontaktadresse, PGP-Schlüssel und Melde-URL als ersten Schritt — auch für kleinere Organisationen ohne großes Budget (BSI). Ein reward-freies CVD-Programm oder eine simple security.txt ist damit ein günstiger Weg, sich auf kommende EU-Regeln auszurichten.

security.txt einrichten: Schritt für Schritt

Die Einrichtung dauert in der Regel weniger als 15 Minuten. Die folgende Reihenfolge hat sich bewährt — von der Datei über den Prozess bis zur dauerhaften Überwachung.

1. Postfach anlegen — eine überwachte Adresse wie security@ihre-domain.de einrichten, idealerweise mit Auto-Reply als Empfangsbestätigung
2. Pflichtfelder setzen — mindestens Contact und Expires; das Ablaufdatum weniger als ein Jahr in die Zukunft (IETF 2022)
3. Datei platzieren — unter /.well-known/security.txt, ausgeliefert über HTTPS mit Content-Type text/plain
4. Optionale Felder ergänzen — Policy (Richtlinie verlinken), Encryption (PGP-Schlüssel), Preferred-Languages, Canonical
5. Signieren — die Datei mit PGP signieren, wie vom BSI empfohlen (BSI), um Manipulation erkennbar zu machen
6. Disclosure-Policy schreiben — Scope, erlaubte Tests, Reaktionsfristen und Safe Harbor festlegen (OWASP)
7. Pro Host prüfen — jede öffentliche Subdomain braucht eine eigene erreichbare Datei
8. Überwachen — Präsenz, RFC-Konformität und Ablaufdatum automatisiert kontrollieren, damit die Datei nicht still verfällt

Präsenz und Ablauf überwachen: Wo der Security-Scan ansetzt

Eine security.txt ist kein Set-and-Forget. Sie verschwindet bei Relaunches, Server-Migrationen oder CMS-Updates, und ihr Ablaufdatum läuft unweigerlich ab. Ohne Überwachung fällt das erst auf, wenn ein Forscher keinen Kontakt findet — also genau im falschen Moment. Der XICTRAQ Security-Scan prüft die Präsenz der Datei unter /.well-known/security.txt, validiert die Pflichtfelder und überwacht das Expires-Datum, sodass Sie vor Ablauf gewarnt werden.

security.txt ist dabei ein Baustein eines breiteren Security-Headers- und Compliance-Checks. Verschwindet die Datei, fällt das Ablaufdatum oder ändert sich der Inhalt unerwartet, erhalten Sie eine Benachrichtigung per E-Mail, Slack, Discord oder Telegram — bevor daraus ein Reibungspunkt im Ernstfall wird. So bleibt der Meldeweg dauerhaft auffindbar.

Der Meldekanal greift in eine durchgängige Kontrollkette ein: security.txt sagt Forschenden, wie sie melden — die übrigen Sicherheits-Header und Skript-Kontrollen schließen die Lücken, über die Angriffe überhaupt erst laufen. Wie diese Schichten zusammenspielen, vertiefen die folgenden Beiträge.

Wer seine Schnittstellen ebenfalls absichert, findet weiterführende Hinweise im Beitrag zum GraphQL-API-Monitoring sowie zum DNS-Propagation-Monitoring mit mehreren Resolvern. Zusammen mit einem gepflegten Meldekanal und einer soliden DSGVO-Compliance entsteht eine nachweisbare, mehrschichtige Schutzbasis.

Den Meldeweg dauerhaft auffindbar halten

security.txt ist eines der wenigen Sicherheits-Features mit einem nahezu unschlagbaren Aufwand-Nutzen-Verhältnis: Minuten Einrichtung gegen potenziell Stunden gesparter Reaktionszeit im Ernstfall. Mit dem Cyber Resilience Act wird der dahinterliegende CVD-Prozess ab Dezember 2027 ohnehin zur Pflicht für viele Hersteller (CRA, EU) — wer jetzt beginnt, baut Routine auf, bevor die Frist drückt.

Die eigentliche Herausforderung ist nicht das Anlegen, sondern das Aktuellhalten. Ein abgelaufenes Expires, eine beim Relaunch verlorene Datei oder eine nur auf der Hauptdomain, aber nicht auf Subdomains hinterlegte security.txt machen den Meldeweg unsichtbar — und niemand bemerkt es, bis es zu spät ist. Genau hier setzt automatisiertes Monitoring an: Es prüft Präsenz, Konformität und Ablauf kontinuierlich und meldet jede Abweichung, bevor sie zum Problem wird.

In Kombination mit der Überwachung Ihrer Security-Header, Skript-Integrität und API-Endpunkte entsteht so eine lückenlose Kontrolle über die Sicherheitsschicht Ihrer Online-Präsenz — von der Eingangstür für Forschende bis zur technischen Absicherung dahinter.

Praktisch heißt das: Setzen Sie die Datei einmal sauber auf, dokumentieren Sie den dahinterliegenden Prozess und überlassen Sie die Pflege nicht dem Zufall. Eine jährliche manuelle Erinnerung an die Verlängerung des Expires-Datums funktioniert in Theorie, scheitert in der Praxis aber regelmäßig an Personalwechseln, Relaunches oder schlicht vergessenen Terminen. Eine automatisierte Prüfung nimmt Ihnen diesen Schritt ab und stellt sicher, dass Ihr Meldeweg genau dann auffindbar ist, wenn er gebraucht wird — im Moment einer gemeldeten Schwachstelle.

Häufig gestellte Fragen zu security.txt und Vulnerability Disclosure