TL;DR: Das Wichtigste
- security.txt ist eine kleine Textdatei, die von der IETF (RFC 9116) standardisiert wurde und jedem, der eine Sicherheitslücke entdeckt, mitteilt, wie und an wen diese gemeldet werden soll. Sie befindet sich stets am selben Ort: /.well-known/security.txt.
- Zwei Felder sind obligatorisch: eine Kontaktmöglichkeit (Contact) und ein Ablaufdatum (Expires). Die übrigen Felder legen die Offenlegungsrichtlinie, die akzeptierten Sprachen oder den zu verwendenden Verschlüsselungsschlüssel fest.
- Die Datei ist lediglich ein Einstiegspunkt. Ohne eine veröffentlichte Offenlegungsrichtlinie und ohne ein Team, das in der Lage ist, die Meldungen zu sichten, verursacht sie mehr Unruhe, als sie Risiken mindert.
- Der regulatorische Kontext verändert die Lage: NIS2 regelt die koordinierte Offenlegung von Sicherheitslücken in Europa, und der Cyber Resilience Act verpflichtet Hersteller digitaler Produkte seit September 2026 dazu, aktiv ausgenutzte Sicherheitslücken zu melden.
- Für einen Entscheidungsträger lautet die richtige Frage nicht: „Verfügen wir über eine security.txt-Datei?“, sondern: „Wird eine heute Abend eingegangene Meldung gelesen, bewertet und bearbeitet?“
Ein Sicherheitsforscher entdeckt eine Sicherheitslücke auf der Website einer Organisation. Er möchte diese melden. Oft beginnt damit ein ungewisser Weg: ein allgemeines Kontaktformular, eine „info@“-Adresse, auf die keine Antwort erfolgt, oder eine LinkedIn-Nachricht an einen zufällig ausgewählten Mitarbeiter. Da es keinen klaren Kommunikationsweg gibt, geht die Meldung verloren, kommt zu spät an oder wird gar nicht erst versendet. Im schlimmsten Fall wird die Sicherheitslücke veröffentlicht, ohne dass die Organisation Zeit hatte, sie zu beheben, oder sie wird schliesslich von jemandem mit weniger guten Absichten ausgenutzt.
Der Standard „security.txt“ löst dieses Problem auf die einfachste Art und Weise: Eine Datei an einem Standardspeicherort, die angibt, wer unter welchen Bedingungen zu kontaktieren ist. Dieser Leitfaden erläutert, was diese Datei enthält, warum sie allein nicht ausreicht, wie sie sich in die europäischen und schweizerischen gesetzlichen Anforderungen einfügt und welche Entscheidungen sie für einen Sicherheitsbeauftragten oder eine Führungskraft mit sich bringt.
security.txt standardisiert die Sicherheitskontaktstelle
„security.txt“ ist eine Textdatei, die auf einer Website unter der Adresse https://exemple.ch/.well-known/security.txtveröffentlicht wird. Sie beschreibt in einem sowohl für Menschen als auch für Maschinen lesbaren Format, wie eine Sicherheitslücke der Organisation gemeldet werden kann. Das Prinzip orientiert sich an der Datei „robots.txt“, die Suchmaschinen seit Jahrzehnten heranziehen, um zu erfahren, welche Seiten sie indexieren sollen.
L'essentiel Cybersécurité, IA & Tech
Rejoignez la communauté. 3 fois par semaine, recevez l'analyse des tendances par Marc Barbezat. Pas de spam, juste de l'info.
Der 2017 vorgeschlagene Standard wurde im April 2022 von der IETF unter der Referenznummer RFC 9116 veröffentlicht. Sie schreibt drei Grundregeln vor: Die Datei muss über HTTPS bereitgestellt werden, sie muss mindestens einen Ansprechpartner und ein Ablaufdatum enthalten und sie muss im standardisierten Verzeichnis abgelegt werden /.well-known/.
Eine minimale Datei sieht wie folgt aus:
Contact: mailto:security@exemple.ch
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: fr, en, de
Policy: https://exemple.ch/divulgation-vulnerabilites
Canonical: https://exemple.ch/.well-known/security.txt
Jedes Feld beantwortet eine bestimmte Frage
Die Norm definiert eine begrenzte Anzahl von Feldern, von denen jedes eine Frage beantwortet, die sich die Person stellt, die eine Sicherheitslücke melden möchte.
| Feld | Status | Eine Frage, die er beantwortet |
|---|---|---|
| Kontakt | Obligatorisch | Wohin soll die Meldung gesendet werden? (E-Mail-Adresse, Online-Formular, Telefonnummer) |
| Läuft ab | Obligatorisch | Sind diese Informationen noch aktuell? |
| Richtlinie | Empfohlen | Wie lauten die Rahmenbedingungen: Bereich, Fristen, gegenseitige Verpflichtungen? |
| Bevorzugte Sprachen | Empfohlen | In welcher Sprache soll der Text verfasst werden? |
| Verschlüsselung | Empfohlen | Welchen Schlüssel sollte man zur Verschlüsselung einer vertraulichen Meldung verwenden? |
| Canonical | Empfohlen | Handelt es sich bei dieser Datei tatsächlich um die offizielle Version? |
| Danksagungen | Optional | Wo bedankt sich die Organisation öffentlich bei den Entdeckern? |
| Stellenangebote | Optional | Stellt die Organisation Mitarbeiter im Sicherheitsbereich ein? |
| CSAF | Optional | Wo finden Sie die im CSAF-Format veröffentlichten Sicherheitshinweise? |
Zwei Bereiche verdienen die besondere Aufmerksamkeit eines Entscheidungsträgers.
„Expires“ verpflichtet die Organisation dazu, ihre Datei regelmässig zu überprüfen. Die Norm empfiehlt eine Gültigkeitsdauer von weniger als einem Jahr. Eine abgelaufene Datei weist auf einen nicht mehr gültigen Kontakt hin, was schlimmer ist als gar keine Datei: Sie vermittelt dem Suchenden eine falsche Sicherheit und offenbart dem aufmerksamen Beobachter einen Mangel an Governance.
„Policy“ verweist auf die Richtlinie zur Offenlegung von Sicherheitslücken. Dieses Dokument verwandelt eine einfache Meldung in einen Prozess.
Der Standard empfiehlt zudem, die Datei mit einem OpenPGP-Schlüssel zu signieren, damit ein Angreifer, der die Website kompromittiert hat, die Kontaktadresse nicht unbemerkt durch seine eigene ersetzen kann.
Die Datei ist nur ein Einstieg; die Offenlegungspolitik erledigt den Rest
Eine security.txt-Datei zu veröffentlichen, ohne dass dahinter etwas steht, ist so, als würde man eine Türklingel installieren, ohne dass jemand da ist, der die Tür öffnet. Die eigentliche Entscheidung betrifft die Richtlinie zur Offenlegung von Sicherheitslücken (VDP, kurz für „Vulnerability Disclosure Policy“), auf die das Feld „Policy“ verweist.
Eine Offenlegungspolitik beantwortet die Fragen, die sich jeder Forscher stellt, bevor er eine Sicherheitslücke meldet:
- Der Bereich: Welche Websites, Anwendungen und Dienste sind betroffen, und welche sind davon ausgenommen;
- die zulässigen Methoden: Was der Forscher testen darf und was verboten ist (Denial-of-Service-Angriffe, Zugriff auf Daten Dritter, Social Engineering);
- die Verpflichtungen der Organisation: Frist für die Empfangsbestätigung, Frist für die Begutachtung, Benachrichtigung des Forschers über die Korrektur;
- der rechtliche Rahmen: die Verpflichtung, keinen Forscher strafrechtlich zu verfolgen, der in gutem Glauben und unter Einhaltung der festgelegten Regeln handelt;
- die Veröffentlichung: die Frist, nach deren Ablauf die Sicherheitslücke veröffentlicht werden darf, sowie die Modalitäten für die Anerkennung des Entdeckers.
Diese Richtlinie darf nicht mit einem Bug-Bounty-Programm verwechselt werden. Eine Offenlegungsrichtlinie schafft einen Kanal und legt Regeln fest, ohne eine Belohnung zu versprechen. Ein Bug-Bounty-Programm sieht eine Vergütung vor, die in der Regel über eine spezialisierte Plattform abgewickelt wird, welche die Meldungen filtert. Die meisten Organisationen beginnen mit der erstgenannten; die zweite setzt eine gewisse Reife und ein Budget voraus, über die nicht alle verfügen.
Ein klarer Kommunikationskanal beschleunigt die Reaktion auf Vorfälle
Die Vorteile von security.txt beschränken sich nicht nur auf die Zusammenarbeit mit unabhängigen Forschern.
Die Reaktionszeit verkürzt sich. Eine Meldung, die direkt beim Sicherheitsteam eingeht, anstatt über den Kundensupport oder die Kommunikationsabteilung weitergeleitet zu werden, spart oft mehrere Tage Zeit. Bei einer kritischen Sicherheitslücke zählen diese Tage.
Gross angelegte Benachrichtigungen erreichen ihr Ziel. Wenn nationale Cybersicherheitszentren, CERTs oder Forscher nach der Veröffentlichung einer Sicherheitslücke Tausende von anfälligen Systemen identifizieren, benötigen sie eine automatisierte Möglichkeit, den richtigen Ansprechpartner zu finden. Eine maschinenlesbare Datei an einem bekannten Speicherort ist genau das, was solche Kampagnen erst möglich macht.
Die Organisation signalisiert damit Reife. Die Bekanntgabe einer Sicherheitskontaktstelle zeigt, dass die Organisation die Möglichkeit von Sicherheitslücken akzeptiert und Vorkehrungen getroffen hat, um diese zu beheben. Für einen Partner, einen Kunden oder einen Prüfer ist dies ein einfacher, von aussen überprüfbarer Indikator.
NIS2, der Cyber Resilience Act und die Behörden verstärken den Druck
„security.txt“ ist nach wie vor ein freiwilliger Standard. Die koordinierte Offenlegung von Sicherheitslücken, die dadurch erleichtert wird, ist jedoch mittlerweile zu einer ausdrücklichen regulatorischen Anforderung geworden.
In den Vereinigten Staaten hat die CISA den Bundesbehörden bereits im Jahr 2020 durch ihre Richtlinie BOD 20-01 vorgeschrieben, eine Richtlinie zur Offenlegung von Sicherheitslücken zu veröffentlichen, wobei security.txt als Mittel zur Angabe der Kontaktstelle genannt wurde.
In der Europäischen Union regelt die NIS2-Richtlinie die koordinierte Offenlegung von Sicherheitslücken auf Ebene der Mitgliedstaaten, indem sie den nationalen CSIRTs eine koordinierende Rolle zwischen denjenigen, die die Schwachstellen entdecken, und denjenigen, die diese beheben müssen, überträgt. Das Management und die Offenlegung von Sicherheitslücken gehören zu den Massnahmen, die von den betroffenen Stellen erwartet werden.
Der Cyber Resilience Act (CRA) stellt für Hersteller von Produkten mit digitalen Komponenten – sowohl Software als auch Hardware – strengere Anforderungen. Seit dem 11. September 2026 sind sie verpflichtet, aktiv ausgenutzte Sicherheitslücken und schwerwiegende Vorfälle über die zentrale Plattform der ENISA zu melden: Frühwarnung innerhalb von 24 Stunden, vollständige Meldung innerhalb von 72 Stunden, Abschlussbericht spätestens 14 Tage nach Bereitstellung eines Patches. Ab Dezember 2027 gelten die übrigen Verpflichtungen der Verordnung, darunter die Einführung einer koordinierten Offenlegungspolitik und einer Anlaufstelle für die Entgegennahme von Meldungen. Eine Organisation kann nicht melden, was sie nicht erkennt: Ein funktionierender Meldekanal wird zu einer praktischen Voraussetzung für die Einhaltung der Vorschriften. Schweizer Unternehmen, die digitale Produkte auf dem europäischen Markt vertreiben, sind davon unmittelbar betroffen.
In der Schweiz empfiehlt das Bundesamt für Cybersicherheit (BACS) Unternehmen und Organisationen, eine security.txt-Datei zu veröffentlichen, und die Bundesverwaltung wendet dies auf ihre eigenen Websites an.
Die Fallstricke, die die Datei zu einer Belastung machen
Eine unsachgemäss verwaltete „security.txt“-Datei kann mehr Risiken mit sich bringen, als sie schützt. Fünf Situationen treten regelmässig auf.
Eine E-Mail-Adresse, die niemand liest. Ein „security@“-Postfach, das nicht überwacht oder an eine allgemeine Adresse weitergeleitet wird, führt dazu, dass Meldungen verloren gehen, während gleichzeitig der Eindruck eines offenen Kommunikationskanals erweckt wird. Die Kontaktaufnahme muss zu einem bestimmten Team führen, das über eine festgelegte Antwortfrist verfügt.
Eine abgelaufene Datei. Das Ablaufdatum wird nach der ersten Veröffentlichung oft vergessen. Eine automatische Erinnerung, die an einen benannten Verantwortlichen gekoppelt ist, reicht aus, um diesen für alle sichtbaren Fehler zu vermeiden.
Das „Bug-Bounty“-Programm. Die Sichtbarmachung des Kontaktformulars zieht zudem automatisierte Nachrichten an: Berichte von Scannern ohne Analyse, Schwachstellen ohne tatsächliche Auswirkungen, beharrliche Forderungen nach einer Belohnung. Eine klare Offenlegungsrichtlinie, in der festgelegt ist, was nicht als Sicherheitslücke gilt und dass keine Vergütung vorgesehen ist, ermöglicht eine schnelle Vorauswahl. Einfache Filter für die typischen Formulierungen dieser Nachrichten runden das System ab.
Nur ein Bereich wird abgedeckt. Die Datei wird häufig nur auf der Hauptwebsite veröffentlicht, während Subdomains, Fachanwendungen und ältere Websites ohne Anknüpfungspunkt bleiben. Der Standard ermöglicht die Weiterleitung zu einer zentralen Datei; dies muss jedoch zuvor vorgesehen worden sein.
Es besteht kein Zusammenhang mit dem Vorfallmanagement. Eine Meldung einer Sicherheitslücke kann auf eine laufende Kompromittierung hindeuten. Der Bearbeitungsprozess muss daher mit dem Vorfallmanagement und – für die betroffenen Organisationen – mit den Meldepflichten gegenüber den Behörden verknüpft sein.
Einführung von security.txt in sechs Schritten
Die technische Umsetzung dauert einige Minuten. Die damit verbundene organisatorische Gestaltung erfordert jedoch mehr Überlegung.
- Ernennen Sie eine verantwortliche Person für die Kontaktstelle und die Aktualisierung der Datei.
- Wählen Sie den Kanal: eigene Adresse, gesichertes Formular oder Meldestelle, wobei die Antwortfrist im Hinblick auf die verfügbaren Ressourcen realistisch sein sollte.
- Erstellung der Offenlegungsrichtlinie: Bereich, zulässige Methoden, Verpflichtungen, rechtlicher Rahmen, Modalitäten der Veröffentlichung.
- Veröffentlichen Sie die Datei auf jeder exponierten Domain über HTTPS, idealerweise signiert und mit einer Gültigkeitsdauer von weniger als einem Jahr.
- Den Prozess mit dem Schwachstellen- und Vorfallmanagement sowie mit den geltenden Meldepflichten (NIS2, CRA, nationale Vorschriften) verknüpfen.
- Die Datei, die Richtlinien und die Statistiken zu den eingegangenen Meldungen jährlich zu überprüfen.
Häufig gestellte Fragen zu security.txt
Was ist eine „security.txt“-Datei?
Es handelt sich um eine von der IETF standardisierte Textdatei (RFC 9116), die unter der Adresse /.well-known/security.txt einer Website veröffentlicht wurde. Sie enthält Angaben dazu, wie eine Sicherheitslücke der Organisation gemeldet werden kann: Kontaktdaten, Offenlegungsrichtlinie, akzeptierte Sprachen, Verschlüsselungsschlüssel. Sie ist sowohl für Menschen als auch für automatisierte Tools lesbar.
Welche Felder sind in der Datei „security.txt“ Pflichtfelder?
Nur zwei Felder sind Pflichtfelder: „Kontakt“, in dem angegeben wird, wohin eine Meldung zu senden ist, und „Ablaufdatum“, in dem das Datum festgelegt wird, ab dem die Informationen nicht mehr als zuverlässig gelten dürfen. Der Standard empfiehlt eine Gültigkeitsdauer von weniger als einem Jahr.
Ist „security.txt“ obligatorisch?
Nein, security.txt bleibt ein freiwilliger Standard. Die koordinierte Offenlegung von Sicherheitslücken, die dadurch erleichtert wird, wird jedoch mittlerweile von mehreren Rahmenwerken erwartet: NIS2 in der Europäischen Union, der Cyber Resilience Act für Hersteller digitaler Produkte sowie die Empfehlungen des BACS in der Schweiz.
Was ist der Unterschied zwischen „security.txt“, einer Offenlegungsrichtlinie und einem Bug-Bounty-Programm?
In der Datei „security.txt“ ist angegeben, wohin eine Sicherheitslücke gemeldet werden soll. Die Offenlegungsrichtlinie legt die Regeln fest: Bereich, zulässige Methoden, Fristen sowie der rechtliche Schutz des gutgläubigen Forschers. Ein Bug-Bounty-Programm sieht zusätzlich eine finanzielle Belohnung vor, die in der Regel über eine spezialisierte Plattform abgewickelt wird. Alle drei Elemente ergänzen sich gegenseitig, und das erste hat ohne das zweite nur geringen Wert.
Wie kann man vermeiden, von irrelevanten Meldungen überschwemmt zu werden?
Durch die Veröffentlichung einer Offenlegungsrichtlinie, in der klargestellt wird, was nicht als Sicherheitslücke gilt und dass ausserhalb eines speziellen Programms keine Belohnung vorgesehen ist. Filter für automatisierte Meldungen und – für besonders gefährdete Organisationen – die Nutzung einer Meldungsplattform, die eine erste Vorauswahl gewährleistet, runden das System ab.
Welcher Zusammenhang besteht zwischen „security.txt“ und dem Cyber Resilience Act?
Seit dem 11. September 2026 verpflichtet die CRA Hersteller digitaler Produkte, aktiv ausgenutzte Sicherheitslücken der ENISA zu melden. Ab Dezember 2027 verlangt sie zudem eine koordinierte Offenlegungspolitik sowie eine Anlaufstelle für Meldungen. security.txt ist das Standardverfahren, um diese Anlaufstelle sichtbar und nutzbar zu machen.
Sollte die Datei „security.txt“ auf allen Subdomains veröffentlicht werden?
Im Idealfall sollte jede veröffentlichte Domain und Subdomain die Zuordnung zu einem Ansprechpartner ermöglichen. Der Standard erlaubt eine zentrale Datei, auf die die anderen Websites weiterleiten, was die Wartung vereinfacht und verwaiste Dateien verhindert.
Weitere Informationen zu diesem Thema
sécurité.txt
Une norme proposée qui permet aux sites web de définir des politiques de sécurité. Lire la suite
Security.txt – Enregistrez un contact de sécurité sur votre site Internet
En cas de problème de cybersécurité au sein d'une entreprise ou d'une organisation, il est crucial d'en informer aussitôt le responsable de la sécurité. Or, il est généralement difficile, voire impossible, de retrouver ce dernier sur les sites Internet. La… Lire la suite
RFC 9116 : Un format de fichier pour faciliter la divulgation des vulnérabilités de sécurité | Éditeur RFC
Lorsque des failles de sécurité sont découvertes par des chercheurs, les canaux de signalement appropriés font souvent défaut. De ce fait, certaines failles peuvent ne pas être signalées. Ce document définit un format lisible par machine (« security.txt ») afin d’aider les… Lire la suite
BOD 20-01 : Élaborer et publier une politique de divulgation des vulnérabilités | CISA
Cette page contient une version adaptée au Web de la directive opérationnelle contraignante 20-01 de l'Agence de cybersécurité et de sécurité des infrastructures, intitulée « Élaborer et publier un Lire la suite
Loi sur la cyber-résilience – Obligations de déclaration
À compter du 11 septembre 2026, les fabricants sont tenus de signaler les vulnérabilités exploitées et les incidents graves affectant la sécurité des produits comportant des éléments numériques. Conformément à l'article 71, paragraphe 2, de la loi sur les produits… Lire la suite
Cette veille vous a fait gagner du temps ?
Aidez DCOD à payer ses serveurs et à rester 100% gratuit et indépendant.
