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.<\/p>\n\n\n\n
Was auf den ersten Blick wie eine kleine technische Datei wirkt, ist in Wahrheit ein wichtiges Governance-Signal. Denn wer keinen klaren Meldekanal f\u00fcr Schwachstellen bereitstellt, riskiert, dass Hinweise verz\u00f6gert, 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.<\/p>\n\n\n\n
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\u00fcr Schwachstellenmeldungen zu geben. Typischerweise wird sie unter security.txt ist keine vollst\u00e4ndige Vulnerability-Management-Strategie. Sie ist ein Einstiegspunkt in einen geregelten Coordinated-Vulnerability-Disclosure-Prozess. F\u00fcr GRC-Teams ist deshalb nicht nur entscheidend, ob eine Datei existiert, sondern ob dahinter ein belastbarer Prozess f\u00fcr Eingang, Bewertung, Eskalation, Behebung und Dokumentation von Schwachstellenmeldungen steht.<\/p>\n\n\n\n security.txt ist eine einfache Textdatei, die auf einer Website ver\u00f6ffentlicht wird und Sicherheitskontakte sowie weitere Informationen zur Schwachstellenmeldung enth\u00e4lt. RFC 9116 beschreibt security.txt als maschinenlesbares Format, mit dem Organisationen ihre Vulnerability-Disclosure-Praktiken offenlegen k\u00f6nnen, damit Forscher Sicherheitsl\u00fccken einfacher melden k\u00f6nnen. <\/p>\n\n\n\n Die Datei kann zum Beispiel eine Kontaktadresse, einen Link zur Vulnerability-Disclosure-Policy, Verschl\u00fcsselungsinformationen, 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\u00e4higer Prozess.<\/p>\n\n\n\n Die BSI-Zahl von 1,8 Prozent zeigt eine grosse L\u00fccke zwischen technischer M\u00f6glichkeit und organisatorischer Umsetzung. security.txt ist technisch leicht bereitzustellen. Trotzdem fehlt sie bei der grossen Mehrheit der Webseitenbetreiber in Deutschland.<\/p>\n\n\n\n Das Problem ist nicht nur fehlende Sichtbarkeit. Es ist fehlende Prozessklarheit. Wenn ein externer Forscher eine kritische Schwachstelle findet, braucht er schnell einen verl\u00e4sslichen Kontakt. Wenn er stattdessen \u00fcber allgemeine Kontaktformulare, zentrale Telefonnummern oder unklare E-Mail-Adressen gehen muss, verstreicht wertvolle Zeit.<\/p>\n\n\n\n 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\u00e4ren und riskiert, dass Hinweise nicht weitergeleitet oder ignoriert werden. <\/p>\n\n\n\n F\u00fcr Unternehmen ist das ein klares Risiko. Eine Schwachstelle, die intern nicht rechtzeitig ankommt, kann sp\u00e4ter zum Incident, Datenschutzvorfall, Kundenproblem oder regulatorischen Finding werden.<\/p>\n\n\n\n Viele Unternehmen betrachten security.txt als technische Aufgabe f\u00fcr 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\u00e4ssig entgegennehmen, bewerten, eskalieren und nachverfolgen kann.<\/p>\n\n\n\n Dazu braucht es klare Zust\u00e4ndigkeiten. Jemand muss eingehende Meldungen pr\u00fcfen, die Kritikalit\u00e4t 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Coordinated Vulnerability Disclosure beschreibt den geregelten Umgang mit gemeldeten Sicherheitsl\u00fccken. Ziel ist, dass Forscher, Hersteller und Betreiber so zusammenarbeiten, dass Schwachstellen verantwortungsvoll gemeldet, bewertet, behoben und kommuniziert werden.<\/p>\n\n\n\n security.txt kann diesen Prozess unterst\u00fctzen, ersetzt ihn aber nicht. Ohne dahinterliegenden CVD-Prozess bleibt die Datei nur ein Kontaktverzeichnis. Ein funktionierender Prozess braucht definierte Eingangskan\u00e4le, Verantwortliche, Triage, Risikobewertung, technische Analyse, Eskalationswege, Kommunikation mit dem Finder und eine dokumentierte Nachverfolgung der Behebung.<\/p>\n\n\n\n F\u00fcr GRC-Teams ist das besonders relevant, weil CVD mehrere Disziplinen verbindet: Cybersecurity, Legal, Compliance, Datenschutz, Produktmanagement, IT-Betrieb, Vendor Risk und Incident Management.<\/p>\n\n\n\n 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\u00f6ssere regulatorische Kontext: Schwachstellenmanagement, Meldeprozesse und Cyberresilienz werden verbindlicher.<\/p>\n\n\n\n Der Cyber Resilience Act bringt Anforderungen an Produkte mit digitalen Elementen. Dazu geh\u00f6ren unter anderem Schwachstellenmanagement, Sicherheitsupdates, Produktdokumentation und Meldepflichten. Die ersten CRA-Meldepflichten greifen ab dem 11. September 2026, die vollst\u00e4ndige Anwendung folgt ab dem 11. Dezember 2027.<\/p>\n\n\n\n NIS2 st\u00e4rkt den Fokus auf Risikomanagement, Incident Handling und Meldeprozesse. DORA verpflichtet Finanzunternehmen zu robustem ICT-Risikomanagement, Incident Reporting, Resilienztests und Third-Party-Risk-Steuerung.<\/p>\n\n\n\n All diese Regelwerke haben einen gemeinsamen Nenner: Unternehmen m\u00fcssen Sicherheitsinformationen schneller erkennen, bewerten, eskalieren und nachweisen k\u00f6nnen. security.txt ist daf\u00fcr ein kleiner, aber sichtbarer Baustein.<\/p>\n\n\n\n RFC 9116 beschreibt verschiedene Felder. Besonders wichtig sind Contact und Expires. Das Contact-Feld gibt an, wie Schwachstellen gemeldet werden k\u00f6nnen. Das Expires-Feld zeigt, bis wann die Informationen als aktuell gelten. RFC 9116 betont, dass veraltete oder falsche Informationen dazu f\u00fchren k\u00f6nnen, dass Sicherheitsberichte nicht ankommen oder an falsche Kontakte gesendet werden.<\/p>\n\n\n\n In der Praxis sollte eine security.txt mindestens einen verl\u00e4sslichen Kontaktweg enthalten. Sinnvoll sind ausserdem ein Link zur Disclosure Policy, Verschl\u00fcsselungsinformationen, 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.<\/p>\n\n\n\n In der Praxis scheitert security.txt selten an der Technik. H\u00e4ufiger scheitert sie an Organisation und Pflege. Eine Kontaktadresse existiert, aber niemand pr\u00fcft das Postfach regelm\u00e4ssig. Meldungen landen bei einem allgemeinen Support-Team, das keine Security-Triage durchf\u00fchren kann. Oder es gibt zwar eine Policy, aber keine klaren internen Eskalationswege.<\/p>\n\n\n\n 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\u00e4llen eingebunden werden muss, bleiben Meldungen liegen oder werden unvollst\u00e4ndig bearbeitet.<\/p>\n\n\n\n Das Ergebnis ist problematisch: Das Unternehmen wirkt nach aussen erreichbar, kann die eingehenden Informationen aber intern nicht kontrolliert verarbeiten. Genau hier entsteht GRC-Risiko.<\/p>\n\n\n\n GRC-Verantwortliche sollten security.txt nicht isoliert betrachten. Sinnvoll ist ein kurzer, aber strukturierter Check des gesamten Vulnerability-Disclosure-Prozesses.<\/p>\n\n\n\n Unternehmen sollten pr\u00fcfen, ob sie auf allen relevanten Domains eine aktuelle security.txt bereitstellen und ob diese korrekt unter Dar\u00fcber hinaus sollten Verantwortlichkeiten \u00fcber Security, Legal, Datenschutz, Produktmanagement und externe Dienstleister hinweg gekl\u00e4rt werden. Entscheidend ist am Ende nicht nur, dass eine Meldung eingeht, sondern dass sie nachvollziehbar bewertet, priorisiert und geschlossen wird.<\/p>\n\n\n\n Viele Unternehmen starten mit einer E-Mail-Adresse wie security@example.com<\/a> und einer Excel-Liste f\u00fcr Schwachstellen. Das kann f\u00fcr den Anfang funktionieren. Es skaliert aber schlecht, sobald mehrere Produkte, Standorte, Dienstleister, Systeme und regulatorische Anforderungen betroffen sind.<\/p>\n\n\n\n Das Problem liegt in der Verkn\u00fcpfung. Eine Meldung betrifft h\u00e4ufig ein konkretes Asset oder Produkt. Dieses Produkt hat einen Owner, eine Kritikalit\u00e4t, technische Abh\u00e4ngigkeiten und m\u00f6glicherweise regulatorische Relevanz. Daraus entstehen Massnahmen, Fristen, Eskalationen, Dienstleisteraufgaben und Nachweise.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Ein klarer Meldekanal ist nur dann wirksam, wenn Meldungen bewertet, eskaliert, behoben und dokumentiert werden. Genau hier wird security.txt zum GRC-Thema.<\/p>\n\n\n\n Unternehmen sollten jetzt pr\u00fcfen, ob sie Sicherheitsforschern und CERTs einen verl\u00e4sslichen Kontakt bieten und ob dahinter ein belastbarer CVD-Prozess steht. Wer das strukturiert angeht, verbessert nicht nur die Reaktionsf\u00e4higkeit auf Schwachstellen, sondern st\u00e4rkt auch CRA-, NIS2-, DORA- und ISO-27001-Readiness.<\/p>\n\n\n\n Zazoon unterst\u00fctzt Unternehmen dabei, Schwachstellenmeldungen, Risiken, Kontrollen, Verantwortlichkeiten und Nachweise zentral zu verbinden. So wird aus einer einfachen Datei ein wirksamer Bestandteil moderner Cyber-Governance.<\/p>\n\n\n\n security.txt ist eine Textdatei, die auf einer Website ver\u00f6ffentlicht wird und Sicherheitskontakte sowie Informationen zur Schwachstellenmeldung enth\u00e4lt. Sie ist in RFC 9116 beschrieben.<\/p>\n\n\n\n F\u00fcr webbasierte Dienste sieht RFC 9116 den Pfad Nein, security.txt ist nicht pauschal gesetzlich vorgeschrieben. Sie ist aber ein sinnvoller Baustein f\u00fcr Coordinated Vulnerability Disclosure und ein sichtbares Element eines reifen Schwachstellenmanagements.<\/p>\n\n\n\n Weil Schwachstellenmeldungen klare Prozesse, Verantwortlichkeiten, Risikobewertungen, Eskalationen, Massnahmen und Nachweise brauchen. Damit betrifft security.txt Governance, Risk und Compliance.<\/p>\n\n\n\n Das BSI hat am 6. August 2026 gemeldet, dass nur 1,8 Prozent der Webseitenbetreiber in Deutschland bislang eine security.txt bereitstellen.<\/p>\n\n\n\n Nein. security.txt ist nur der Eingangskanal. Unternehmen brauchen zus\u00e4tzlich Triage, Bewertung, Eskalation, Behebung, Kommunikation und Dokumentation.<\/p>\n\n\n\n Zazoon hilft, Schwachstellenmeldungen, Risiken, Massnahmen, Verantwortlichkeiten, regulatorische Anforderungen und Nachweise zentral zu steuern. Dadurch wird Vulnerability Disclosure nachvollziehbar, effizient und auditf\u00e4hig.<\/p>\n","protected":false},"excerpt":{"rendered":" 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. WasContinue reading „security.txt: Warum Schwachstellenmeldungen jetzt ein GRC-Thema sind“<\/span><\/a><\/p>\n","protected":false},"author":5,"featured_media":7105,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_seopress_titles_title":"security.txt: Warum Schwachstellenmeldungen ein GRC-Thema sind","_seopress_titles_desc":"Das BSI meldet: Nur 1,8 Prozent der Webseitenbetreiber nutzen security.txt. Warum Vulnerability Disclosure jetzt Governance, Risiko und Nachweise braucht.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","content-type":"","footnotes":""},"categories":[30],"tags":[],"class_list":["post-7104","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-beste-praktiken"],"acf":[],"_links":{"self":[{"href":"https:\/\/zazoon.com\/de\/wp-json\/wp\/v2\/posts\/7104","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zazoon.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zazoon.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zazoon.com\/de\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/zazoon.com\/de\/wp-json\/wp\/v2\/comments?post=7104"}],"version-history":[{"count":1,"href":"https:\/\/zazoon.com\/de\/wp-json\/wp\/v2\/posts\/7104\/revisions"}],"predecessor-version":[{"id":7111,"href":"https:\/\/zazoon.com\/de\/wp-json\/wp\/v2\/posts\/7104\/revisions\/7111"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/zazoon.com\/de\/wp-json\/wp\/v2\/media\/7105"}],"wp:attachment":[{"href":"https:\/\/zazoon.com\/de\/wp-json\/wp\/v2\/media?parent=7104"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zazoon.com\/de\/wp-json\/wp\/v2\/categories?post=7104"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zazoon.com\/de\/wp-json\/wp\/v2\/tags?post=7104"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\/.well-known\/security.txt<\/code> ver\u00f6ffentlicht.<\/p>\n\n\n\nWas ist security.txt?<\/h2>\n\n\n\n
Warum das BSI-Signal so wichtig ist<\/h2>\n\n\n\n
security.txt ist kein IT-Gimmick, sondern Governance<\/h2>\n\n\n\n
Der Zusammenhang mit Coordinated Vulnerability Disclosure<\/h2>\n\n\n\n
Warum das Thema durch CRA, NIS2 und DORA wichtiger wird<\/h2>\n\n\n\n
Was in eine gute security.txt geh\u00f6rt<\/h2>\n\n\n\n
Die h\u00e4ufigsten Fehler bei security.txt<\/h2>\n\n\n\n
Was GRC-Leader jetzt pr\u00fcfen sollten<\/h2>\n\n\n\n
\/.well-known\/security.txt<\/code> erreichbar ist. Ebenso wichtig ist die Frage, ob die angegebene Kontaktadresse \u00fcberwacht wird, ob eine Disclosure Policy existiert und ob Eingang, Bewertung, Eskalation und Behebung dokumentiert sind.<\/p>\n\n\n\nWarum Excel und Mailboxen nicht ausreichen<\/h2>\n\n\n\n
Fazit: security.txt ist klein, aber strategisch wichtig<\/h2>\n\n\n\n
FAQ<\/h2>\n\n\n\n
Was ist security.txt?<\/h3>\n\n\n\n
Wo wird security.txt abgelegt?<\/h3>\n\n\n\n
\/.well-known\/security.txt<\/code> vor. Alternativ kann aus Kompatibilit\u00e4tsgr\u00fcnden auch eine Datei im Stammverzeichnis bestehen, entscheidend ist jedoch der Well-Known-Pfad.<\/p>\n\n\n\nIst security.txt gesetzlich vorgeschrieben?<\/h3>\n\n\n\n
Warum ist security.txt f\u00fcr GRC relevant?<\/h3>\n\n\n\n
Was hat das BSI gemeldet?<\/h3>\n\n\n\n
Reicht eine security.txt f\u00fcr gutes Vulnerability Management aus?<\/h3>\n\n\n\n
Wie unterst\u00fctzt Zazoon bei Schwachstellenmanagement?<\/h3>\n\n\n\n