security.txt: Warum Schwachstellenmeldungen jetzt ein GRC-Thema sind

Das BSI hat am 6. August 2026 darauf hingewiesen, dass nur 1,8 Prozent der Webseitenbetreiber in Deutschland bislang eine security.txt bereitstellen. Grundlage sind Messungen des BSI im Rahmen des Cyberdome-Projekts. Die security.txt nach RFC 9116 soll Sicherheitsforschern, CERTs und anderen Hinweisgebern einen klar auffindbaren Kontakt geben, um entdeckte Schwachstellen sicher und schnell zu melden.

Was auf den ersten Blick wie eine kleine technische Datei wirkt, ist in Wahrheit ein wichtiges Governance-Signal. Denn wer keinen klaren Meldekanal für Schwachstellen bereitstellt, riskiert, dass Hinweise verzögert, an die falsche Stelle oder gar nicht ankommen. In Zeiten von NIS2, CRA, DORA und steigenden Anforderungen an Vulnerability Management wird daraus ein echtes GRC-Thema.

Das Wichtigste in Kürze

Das BSI meldet, dass nur 1,8 Prozent der Webseitenbetreiber in Deutschland bislang eine security.txt bereitstellen. Die Datei ist in RFC 9116 beschrieben und dient dazu, Organisationen einen einheitlichen, maschinenlesbaren Kontaktweg für Schwachstellenmeldungen zu geben. Typischerweise wird sie unter /.well-known/security.txt veröffentlicht.

security.txt ist keine vollständige Vulnerability-Management-Strategie. Sie ist ein Einstiegspunkt in einen geregelten Coordinated-Vulnerability-Disclosure-Prozess. Für GRC-Teams ist deshalb nicht nur entscheidend, ob eine Datei existiert, sondern ob dahinter ein belastbarer Prozess für Eingang, Bewertung, Eskalation, Behebung und Dokumentation von Schwachstellenmeldungen steht.

Was ist security.txt?

security.txt ist eine einfache Textdatei, die auf einer Website veröffentlicht wird und Sicherheitskontakte sowie weitere Informationen zur Schwachstellenmeldung enthält. RFC 9116 beschreibt security.txt als maschinenlesbares Format, mit dem Organisationen ihre Vulnerability-Disclosure-Praktiken offenlegen können, damit Forscher Sicherheitslücken einfacher melden können.

Die Datei kann zum Beispiel eine Kontaktadresse, einen Link zur Vulnerability-Disclosure-Policy, Verschlüsselungsinformationen, bevorzugte Sprachen und ein Ablaufdatum der Angaben enthalten. Der wichtigste Punkt ist jedoch nicht die Datei selbst, sondern was dahintersteht: ein erreichbarer, verantwortlicher und handlungsfähiger Prozess.

Warum das BSI-Signal so wichtig ist

Die BSI-Zahl von 1,8 Prozent zeigt eine grosse Lücke zwischen technischer Möglichkeit und organisatorischer Umsetzung. security.txt ist technisch leicht bereitzustellen. Trotzdem fehlt sie bei der grossen Mehrheit der Webseitenbetreiber in Deutschland.

Das Problem ist nicht nur fehlende Sichtbarkeit. Es ist fehlende Prozessklarheit. Wenn ein externer Forscher eine kritische Schwachstelle findet, braucht er schnell einen verlässlichen Kontakt. Wenn er stattdessen über allgemeine Kontaktformulare, zentrale Telefonnummern oder unklare E-Mail-Adressen gehen muss, verstreicht wertvolle Zeit.

Das Schweizer BACS beschreibt genau dieses Problem: Sicherheitskontakte sind oft kaum auffindbar oder gar nicht publiziert. Dadurch muss sich die meldende Person zur richtigen Ansprechperson durchfragen, das Problem mehrfach erklären und riskiert, dass Hinweise nicht weitergeleitet oder ignoriert werden.

Für Unternehmen ist das ein klares Risiko. Eine Schwachstelle, die intern nicht rechtzeitig ankommt, kann später zum Incident, Datenschutzvorfall, Kundenproblem oder regulatorischen Finding werden.

security.txt ist kein IT-Gimmick, sondern Governance

Viele Unternehmen betrachten security.txt als technische Aufgabe für Website-Administratoren. Das greift zu kurz. Die eigentliche Frage lautet nicht, ob eine Textdatei auf dem Webserver abgelegt werden kann. Die eigentliche Frage lautet, ob das Unternehmen Schwachstellenmeldungen zuverlässig entgegennehmen, bewerten, eskalieren und nachverfolgen kann.

Dazu braucht es klare Zuständigkeiten. Jemand muss eingehende Meldungen prüfen, die Kritikalität bewerten, technische Analyse anstossen, Legal oder Datenschutz einbinden, Produktteams informieren und Massnahmen dokumentieren. Wenn diese Schritte nicht definiert sind, hilft auch die beste Kontaktadresse wenig.

Damit wird security.txt zu einem Einstiegspunkt in Governance, Risk und Compliance. Sie macht sichtbar, ob das Unternehmen in der Lage ist, externe Schwachstellenhinweise kontrolliert zu verarbeiten.

Der Zusammenhang mit Coordinated Vulnerability Disclosure

Coordinated Vulnerability Disclosure beschreibt den geregelten Umgang mit gemeldeten Sicherheitslücken. Ziel ist, dass Forscher, Hersteller und Betreiber so zusammenarbeiten, dass Schwachstellen verantwortungsvoll gemeldet, bewertet, behoben und kommuniziert werden.

security.txt kann diesen Prozess unterstützen, ersetzt ihn aber nicht. Ohne dahinterliegenden CVD-Prozess bleibt die Datei nur ein Kontaktverzeichnis. Ein funktionierender Prozess braucht definierte Eingangskanäle, Verantwortliche, Triage, Risikobewertung, technische Analyse, Eskalationswege, Kommunikation mit dem Finder und eine dokumentierte Nachverfolgung der Behebung.

Für GRC-Teams ist das besonders relevant, weil CVD mehrere Disziplinen verbindet: Cybersecurity, Legal, Compliance, Datenschutz, Produktmanagement, IT-Betrieb, Vendor Risk und Incident Management.

Warum das Thema durch CRA, NIS2 und DORA wichtiger wird

security.txt ist nicht automatisch eine gesetzliche Pflicht. Unternehmen sollten daher nicht behaupten, dass der CRA oder NIS2 direkt eine security.txt verlangen. Entscheidend ist der grössere regulatorische Kontext: Schwachstellenmanagement, Meldeprozesse und Cyberresilienz werden verbindlicher.

Der Cyber Resilience Act bringt Anforderungen an Produkte mit digitalen Elementen. Dazu gehören unter anderem Schwachstellenmanagement, Sicherheitsupdates, Produktdokumentation und Meldepflichten. Die ersten CRA-Meldepflichten greifen ab dem 11. September 2026, die vollständige Anwendung folgt ab dem 11. Dezember 2027.

NIS2 stärkt den Fokus auf Risikomanagement, Incident Handling und Meldeprozesse. DORA verpflichtet Finanzunternehmen zu robustem ICT-Risikomanagement, Incident Reporting, Resilienztests und Third-Party-Risk-Steuerung.

All diese Regelwerke haben einen gemeinsamen Nenner: Unternehmen müssen Sicherheitsinformationen schneller erkennen, bewerten, eskalieren und nachweisen können. security.txt ist dafür ein kleiner, aber sichtbarer Baustein.

Was in eine gute security.txt gehört

RFC 9116 beschreibt verschiedene Felder. Besonders wichtig sind Contact und Expires. Das Contact-Feld gibt an, wie Schwachstellen gemeldet werden können. Das Expires-Feld zeigt, bis wann die Informationen als aktuell gelten. RFC 9116 betont, dass veraltete oder falsche Informationen dazu führen können, dass Sicherheitsberichte nicht ankommen oder an falsche Kontakte gesendet werden.

In der Praxis sollte eine security.txt mindestens einen verlässlichen Kontaktweg enthalten. Sinnvoll sind ausserdem ein Link zur Disclosure Policy, Verschlüsselungsinformationen, bevorzugte Sprachen, eine eindeutige kanonische URL und ein Ablaufdatum. Wichtig ist, dass diese Angaben gepflegt werden. Eine veraltete security.txt kann mehr Schaden verursachen als Nutzen.

Die häufigsten Fehler bei security.txt

In der Praxis scheitert security.txt selten an der Technik. Häufiger scheitert sie an Organisation und Pflege. Eine Kontaktadresse existiert, aber niemand prüft das Postfach regelmässig. Meldungen landen bei einem allgemeinen Support-Team, das keine Security-Triage durchführen kann. Oder es gibt zwar eine Policy, aber keine klaren internen Eskalationswege.

Ein weiteres Risiko entsteht, wenn externe Dienstleister nicht eingebunden sind. Viele Schwachstellen betreffen Hosting, SaaS-Anwendungen, externe Entwickler, Open-Source-Komponenten oder Cloud-Infrastruktur. Wenn nicht klar ist, wer in solchen Fällen eingebunden werden muss, bleiben Meldungen liegen oder werden unvollständig bearbeitet.

Das Ergebnis ist problematisch: Das Unternehmen wirkt nach aussen erreichbar, kann die eingehenden Informationen aber intern nicht kontrolliert verarbeiten. Genau hier entsteht GRC-Risiko.

Was GRC-Leader jetzt prüfen sollten

GRC-Verantwortliche sollten security.txt nicht isoliert betrachten. Sinnvoll ist ein kurzer, aber strukturierter Check des gesamten Vulnerability-Disclosure-Prozesses.

Unternehmen sollten prüfen, ob sie auf allen relevanten Domains eine aktuelle security.txt bereitstellen und ob diese korrekt unter /.well-known/security.txt erreichbar ist. Ebenso wichtig ist die Frage, ob die angegebene Kontaktadresse überwacht wird, ob eine Disclosure Policy existiert und ob Eingang, Bewertung, Eskalation und Behebung dokumentiert sind.

Darüber hinaus sollten Verantwortlichkeiten über Security, Legal, Datenschutz, Produktmanagement und externe Dienstleister hinweg geklärt werden. Entscheidend ist am Ende nicht nur, dass eine Meldung eingeht, sondern dass sie nachvollziehbar bewertet, priorisiert und geschlossen wird.

Warum Excel und Mailboxen nicht ausreichen

Viele Unternehmen starten mit einer E-Mail-Adresse wie security@example.com und einer Excel-Liste für Schwachstellen. Das kann für den Anfang funktionieren. Es skaliert aber schlecht, sobald mehrere Produkte, Standorte, Dienstleister, Systeme und regulatorische Anforderungen betroffen sind.

Das Problem liegt in der Verknüpfung. Eine Meldung betrifft häufig ein konkretes Asset oder Produkt. Dieses Produkt hat einen Owner, eine Kritikalität, technische Abhängigkeiten und möglicherweise regulatorische Relevanz. Daraus entstehen Massnahmen, Fristen, Eskalationen, Dienstleisteraufgaben und Nachweise.

Wenn diese Informationen in E-Mails, Tickets, Excel-Dateien und Dokumentenablagen getrennt liegen, entsteht Unsicherheit. Im Ernstfall ist unklar, was wann entschieden wurde, wer verantwortlich war und ob die Massnahmen wirksam waren.

Fazit: security.txt ist klein, aber strategisch wichtig

Die BSI-Zahl von 1,8 Prozent zeigt, dass viele Unternehmen bei einem einfachen, aber wichtigen Baustein des Schwachstellenmanagements noch Nachholbedarf haben. security.txt ist technisch leicht umzusetzen. Die eigentliche Herausforderung liegt jedoch in der Organisation dahinter.

Ein klarer Meldekanal ist nur dann wirksam, wenn Meldungen bewertet, eskaliert, behoben und dokumentiert werden. Genau hier wird security.txt zum GRC-Thema.

Unternehmen sollten jetzt prüfen, ob sie Sicherheitsforschern und CERTs einen verlässlichen Kontakt bieten und ob dahinter ein belastbarer CVD-Prozess steht. Wer das strukturiert angeht, verbessert nicht nur die Reaktionsfähigkeit auf Schwachstellen, sondern stärkt auch CRA-, NIS2-, DORA- und ISO-27001-Readiness.

Zazoon unterstützt Unternehmen dabei, Schwachstellenmeldungen, Risiken, Kontrollen, Verantwortlichkeiten und Nachweise zentral zu verbinden. So wird aus einer einfachen Datei ein wirksamer Bestandteil moderner Cyber-Governance.

FAQ

Was ist security.txt?

security.txt ist eine Textdatei, die auf einer Website veröffentlicht wird und Sicherheitskontakte sowie Informationen zur Schwachstellenmeldung enthält. Sie ist in RFC 9116 beschrieben.

Wo wird security.txt abgelegt?

Für webbasierte Dienste sieht RFC 9116 den Pfad /.well-known/security.txt vor. Alternativ kann aus Kompatibilitätsgründen auch eine Datei im Stammverzeichnis bestehen, entscheidend ist jedoch der Well-Known-Pfad.

Ist security.txt gesetzlich vorgeschrieben?

Nein, security.txt ist nicht pauschal gesetzlich vorgeschrieben. Sie ist aber ein sinnvoller Baustein für Coordinated Vulnerability Disclosure und ein sichtbares Element eines reifen Schwachstellenmanagements.

Warum ist security.txt für GRC relevant?

Weil Schwachstellenmeldungen klare Prozesse, Verantwortlichkeiten, Risikobewertungen, Eskalationen, Massnahmen und Nachweise brauchen. Damit betrifft security.txt Governance, Risk und Compliance.

Was hat das BSI gemeldet?

Das BSI hat am 6. August 2026 gemeldet, dass nur 1,8 Prozent der Webseitenbetreiber in Deutschland bislang eine security.txt bereitstellen.

Reicht eine security.txt für gutes Vulnerability Management aus?

Nein. security.txt ist nur der Eingangskanal. Unternehmen brauchen zusätzlich Triage, Bewertung, Eskalation, Behebung, Kommunikation und Dokumentation.

Wie unterstützt Zazoon bei Schwachstellenmanagement?

Zazoon hilft, Schwachstellenmeldungen, Risiken, Massnahmen, Verantwortlichkeiten, regulatorische Anforderungen und Nachweise zentral zu steuern. Dadurch wird Vulnerability Disclosure nachvollziehbar, effizient und auditfähig.