Security.txt Verbreitung auf der DENOG17: Wo steht Ihr Unternehmen?

Veröffentlicht am 10.11.2025

Security.txt Verbreitung auf der DENOG17: Wo steht Ihr Unternehmen?

Auf der DENOG17 stellte Sascha Heinemann unsere Erkenntnisse zur Einführung von security.txt in der deutschen Netzwerkbetreiber-Community vor. Was mit einer einfachen Frage begann: „Wer hält sich noch an die offiziellen Empfehlungen?" entwickelte sich zu einer Analyse, die sowohl Fortschritte als auch den Verbesserungsbedarf in der Branche aufzeigt.

Testen Sie Ihre Security.txt

Prüfen Sie, ob Domains eine gültige security.txt nach RFC 9116 implementiert haben. Nutzen Sie unseren kostenlosen Checker:

Bedeutung der Recherche

EdgeOps entwickelt unter anderem Whitelabel-Rechenzentrumsportale mit digitalisierten Prozessen für Zugangsanfragen und Cross-Connect-Bestellungen. Unsere Entwicklung ist Community-getrieben und wird durch echtes Feedback von Netzbetreibern wie denen bei DENOG geprägt. Als wir beschlossen, security.txt gemäß den offiziellen Empfehlungen zu implementieren, hat uns unsere Neugierde dazu veranlasst, zu untersuchen, wie viele Organisationen in unserer Branche dasselbe getan haben.

Was ist Security.txt?

Security.txt (RFC 9116) ist eine standardisierte Methode für Unternehmen, um Kontaktinformationen zum Thema Sicherheit zu veröffentlichen. Man könnte es als klaren Kommunikationskanal für Sicherheitsforscher und verantwortungsbewusste Offenlegung bezeichnen.

Der Standard definiert vier Hauptrichtlinien:

  1. Ein einziger Ansprechpartner für Berichte über Sicherheitslücken
  2. Verschlüsselung zur Gewährleistung der Authentizität durch PGP-Signaturen
  3. Ablaufdaten, um sicherzustellen, dass die Informationen aktuell bleiben (maximal ein Jahr)
  4. Klare Richtlinien, die Erwartungen an Sicherheitsforscher festlegen

Die Umsetzung ist unkompliziert: eine einfache Textdatei unter /.well-known/security.txt mit definierten Feldern wie „Kontakt" und „Ablaufdatum", die maschinenlesbar formatiert ist. Sowohl die US-amerikanische CISA (2019) als auch das deutsche BSI (2024) empfehlen diesen Standard offiziell.

Unsere Erkenntnisse

Wir haben 239 Organisationen aus verschiedenen Branchen analysiert, die auf der DENOG17 vertreten waren. Das sind unsere Ergebnisse:

  • Nur 25 % (60 Organisationen) haben security.txt überhaupt implementiert.
  • Von diesen 60 haben nur 25 % (15 Organisationen) eine gültige security.txt.
  • Betrachtet man die Implementierung, einschließlich PGP-Signaturen und korrekter Ablaufdaten, erfüllen nur 7 Organisationen alle Kriterien.

Von 239 Organisationen setzen also nur 7 diese Sicherheits-Best-Practice korrekt um.

Aufschlüsselung nach Branchen

Die Akzeptanzraten variieren erheblich zwischen den einzelnen Branchen:

Branche Anzahl Mit security.txt in % valide Implementierung in %
Behörden 3 2 67% 0 0%
Bildung und Forschung 20 8 40% 3 15%
Internet Exchanges 7 3 43% 0 0%
Hosting & Cloud 42 13 31% 2 5%
Rechenzentren & Colocation 16 4 25% 0 0%
Consulting & Dienstleistungen 70 15 21% 5 7%
Carrier 48 8 17% 4 8%
Hardware 18 3 17% 0 0%
Sonstige 15 4 27% 1 7%

Besonders waren wir überrascht, wie wenig Hardware-Hersteller und Händler die Richtlinie implementiert haben. Eine standardisierte Methode zur Meldung von Sicherheitslücken ist für alle Beteiligten von Vorteil. Mit einer Implementierungsrate von nur 17 % gibt es noch viel Raum für Verbesserungen.

Erwähnenswertes

Unsere Untersuchung hat einige interessante Sonderfälle aufgezeigt:

Heise.de: www.heise.de verfügt über eine security.txt, heise.de (ohne www) jedoch nicht. Die Lösung? Automatische Weiterlung an eine URL, um einen konsistenten Zugriff auf Sicherheitsinformationen zu gewährleisten.

BSI: Die security.txt des Bundesamtes für Sicherheit in der Informationstechnik läuft 2099 ab, das bedeutet, dass sie 74 Jahre lang gültig bleibt, länger als das BSI existiert! Das ist zwar kreativ, verstößt aber gegen die RFC-Anforderung, dass die Gültigkeit innerhalb eines Jahres ablaufen muss.

DE-CIX: Beweist, dass security.txt nicht langweilig sein muss. Leider führt die Verwendung von Sonderzeichen dazu, dass der Test zur Maschinenlesbarkeit fehlschlägt.

Warum Security.txt für Netzwerkbetreiber wichtig ist

Wir interpretieren den Umfang von security.txt nicht nur als „wir haben eine Schwachstelle auf Ihrer Website gefunden", sondern als zentrale Anlaufstelle für alle Sicherheitsfragen im Zusammenhang mit den Diensten eines Anbieters.

Ein Netzbetreiber ohne klaren Ansprechpartner für Sicherheitsfragen ist wie ein Gebäude ohne Notausgang.

Wenn Sicherheitsforscher Schwachstellen entdecken, benötigen sie eine zuverlässige, standardisierte Methode, um diese zu melden. Security.txt bietet genau das: eine maschinenlesbare, leicht auffindbare Kontaktmethode, die im gesamten Internet funktioniert.

Testen Sie Ihre eigene Security.txt

Nutzen Sie unseren interaktiven Checker, um Ihre eigene security.txt-Implementierung zu überprüfen:

Ausblick

Unsere Recherche gibt einen Überblick über die Community bei DENOG17. Wir würden dieses Thema gerne nächstes Jahr erneut aufgreifen, um zu sehen, ob die Akzeptanz zugenommen hat. Wir hoffen, dass wir durch die Hervorhebung sowohl der Vorreiter als auch der Lücken eine breitere Akzeptanz dieses einfachen, aber entscheidenden Sicherheitsstandards fördern können.

Besonderer Dank gilt der DENOG-Community für die Inspiration und allen Organisationen, die security.txt bereits implementieren

security.txt Checker

Enter your domain to validate its security.txt setup. The checker follows RFC 9116 and only requests /.well-known/security.txt over HTTPS/HTTP