Vorhaben besprechen

TOOLBOX · SECURITY-CHECK

SECURITY.TXTPRÜFEN UNDERSTELLEN.

Finden Sicherheitsforschende auf Ihrer Website den richtigen Kontakt? Prüfen Sie Ihre security.txt nach RFC 9116 oder erstellen Sie direkt eine neue.

Art der Prüfung

Die Bot-Prüfung schützt die Toolbox vor automatisiertem Missbrauch.

Wir rufen /.well-known/security.txt einmal ab wie ein Browser, falls nötig zusätzlich /security.txt. Ergebnisse speichern wir nicht dauerhaft.

Noch keine security.txt? Direkt hier erstellen

GENERATOR

security.txt
erstellen.

Felder ausfüllen, Vorschau prüfen, Datei herunterladen. Alles passiert in Ihrem Browser, wir sehen Ihre Angaben nicht.

Ergibt das Feld Canonical. Jede Domain und Subdomain braucht eine eigene Datei.

Contact Pflicht

Der erste Eintrag ist der bevorzugte Weg. E-Mail-Adressen und Telefonnummern werden automatisch zu mailto: und tel:.

Vorgabe: heute in einem Jahr minus einen Tag. RFC 9116 empfiehlt weniger als ein Jahr.

Sprachen, in denen Sie Meldungen annehmen. Ohne Angabe gehen Meldende von Englisch aus.

Richtlinie für Meldungen

Öffentlicher OpenPGP-Schlüssel

Danksagungen an Meldende

Stellen im Security-Bereich

Vorschau

# security.txt nach RFC 9116
# Vor dem Ablaufdatum (Expires) prüfen und erneuern.
Preferred-Languages: de, en
  • PflichtContact: Meldeweg. Mindestens einen Kontaktweg angeben: E-Mail mit mailto:, Telefon mit tel: oder eine Seite mit https://. Die erste Angabe ist der bevorzugte Weg.
  • PflichtExpires: Ablaufdatum. Ein Datum weniger als ein Jahr in der Zukunft setzen und rechtzeitig vor Ablauf erneuern.
  • EmpfohlenCanonical: eigene Adresse. Die eigene Adresse der Datei als Canonical eintragen.
  • EmpfohlenPolicy: Regeln für Meldungen. Eine Seite mit den Regeln für Meldungen veröffentlichen und verlinken.
  • Datei unter /.well-known/security.txt ablegen, als text/plain; charset=utf-8 und nur über HTTPS.
  • Jede Domain und Subdomain braucht eine eigene Datei. Sie gilt nur für die Adresse, unter der sie liegt.
  • Vor dem Ablaufdatum Angaben prüfen und Expires erneuern. Eine abgelaufene Datei sollen Meldende nicht mehr verwenden.
  • Optional signieren: gpg --clearsign security.txt erzeugt eine signierte Fassung, die Sie statt der unsignierten veröffentlichen.

WAS HINEINGEHÖRT

Zwei Pflichtfelder.
Ein klarer Meldeweg.

RFC 9116 hält die Datei bewusst klein. Contact und Expires sind Pflicht, alles andere hilft Meldenden, Ihnen richtig und sicher zu schreiben.

  • Pflicht

    Contact

    Wohin Meldungen gehen: E-Mail mit mailto:, Telefon mit tel: oder eine Seite mit https://. Der erste Eintrag ist der bevorzugte Weg.

  • Pflicht

    Expires

    Bis wann die Angaben gelten, als Datum mit Uhrzeit nach RFC 3339. Genau einmal, empfohlen weniger als ein Jahr in der Zukunft.

  • Empfohlen

    Canonical

    Die Adresse, unter der die Datei gelten soll. Weicht der Abrufort davon ab, sollen Meldende dem Inhalt nicht vertrauen.

  • Empfohlen

    Policy

    Link zu Ihren Regeln für Meldungen: Umfang, Ablauf und was erlaubt ist. Die Datei allein ist keine Erlaubnis für Tests.

  • Optional

    Encryption

    Link zu Ihrem öffentlichen Schlüssel, damit Details zu einer Lücke nicht im Klartext per E-Mail reisen.

  • Optional

    Preferred-Languages

    Sprachen, in denen Sie Meldungen annehmen, etwa „de, en“. Ohne Angabe gehen Meldende von Englisch aus.

Dazu kommen Acknowledgments (Danksagungen) und Hiring (Stellenangebote). Quellen: RFC 9116 (Abschnitte 2 bis 5), IANA-Registry der Felder, Richtlinie (EU) 2022/2555 (Art. 12 und 21), BSI-CS 149 und BSI TR-03183-3.

FRAGEN

Gut zu wissen.

Was ist eine security.txt?

Eine kleine Textdatei, die unter /.well-known/security.txt auf Ihrer Website liegt. Sie sagt Sicherheitsforschenden, wie sie eine gefundene Schwachstelle an Sie melden können. Das Format legt RFC 9116 der IETF fest, veröffentlicht im April 2022. Pflicht sind nur zwei Felder: Contact und Expires.

Ist eine security.txt für NIS2 vorgeschrieben?

Nein, die NIS2-Richtlinie (EU) 2022/2555 nennt die Datei nicht. Sie verlangt von wesentlichen und wichtigen Einrichtungen aber Risikomanagementmaßnahmen, die ausdrücklich „Management und Offenlegung von Schwachstellen“ umfassen (Art. 21 Abs. 2 lit. e). Eine security.txt ist ein einfacher, einheitlich beschriebener Baustein dafür: Meldungen von außen kommen an der richtigen Stelle an. Das deutsche BSI empfiehlt die Datei in seiner Cyber-Sicherheitsempfehlung BSI-CS 149 und macht sie in der Technischen Richtlinie TR-03183-3 für Hersteller zur Muss-Anforderung. Was Ihr nationales Umsetzungsgesetz im Einzelnen verlangt, klären wir gerne mit Ihnen.

Warum braucht die Datei ein Ablaufdatum?

Veraltete Kontaktdaten sind gefährlich: Meldungen landen ins Leere oder bei Dritten. RFC 9116 macht Expires deshalb zur Pflicht und empfiehlt ein Datum weniger als ein Jahr in der Zukunft. Ist es überschritten, sollen Meldende die Datei nicht mehr verwenden. Der Generator setzt heute in einem Jahr minus einen Tag; tragen Sie sich die Erneuerung in den Kalender ein.

Muss ich die Datei signieren?

Nein, aber RFC 9116 empfiehlt eine OpenPGP-Klartextsignatur, zusammen mit dem Feld Canonical. So können Meldende prüfen, dass Inhalt und Ort wirklich von Ihnen stammen. Unser Check erkennt den Aufbau einer Signatur, prüft sie aber nicht kryptografisch. Dafür braucht es Ihren öffentlichen Schlüssel, etwa mit gpg --verify.

Was passiert mit meinen Eingaben?

Der Generator und der Modus „Text einfügen“ laufen vollständig in Ihrem Browser; die Angaben verlassen Ihr Gerät nicht. Bei der Prüfung per Domain ruft unser Server die Datei einmal ab wie ein Browser. Das Ergebnis liegt fünf Minuten im Arbeitsspeicher, damit wiederholte Abrufe die Website nicht erneut belasten, und wird nicht dauerhaft gespeichert.

TOOLBOX

Weitere
Werkzeuge.

IHR NÄCHSTER SCHRITT

Ergebnis da.
Und jetzt?

Wir ordnen Befunde ein, priorisieren nach Risiko und setzen auf Wunsch um: einmalig mit EXPERTS oder laufend im Betrieb mit GRID.

Ergebnis besprechen