security-txt.de

security.txt erstellen, in zwei Minuten und gültig

Domain eintragen, der Generator schreibt die Datei nach RFC 9116, auf Wunsch nach der strengeren BSI TR-03183-3: mit gültigem Ablaufdatum, den vorgesehenen Kommentaren und einem Hinweis zu allem, was noch fehlt.

Nur die Domain müssen Sie eintippen. Leere Pflichtfelder füllt der Generator mit üblichen Adressen und zeigt sie grau im Feld. Diese Postfächer und Seiten müssen Sie dann einrichten oder durch Ihre eigenen ersetzen.

Pflicht muss in der Datei stehen Soll empfohlen optional nur wenn vorhanden. Das neben einem Feld erklärt es genauer.

Umfang

Der Internet-Standard mit den Mindestfeldern Contact und Expires. Schnell erledigt, reicht für den Anfang.Die strengere Fassung des BSI mit zwei Postfächern, Meldeseite, Richtlinie und Schlüsseln. Empfohlen für Hersteller unter dem Cyber Resilience Act, wenn diese Adressen schon stehen.

Die Adresse, unter der die Datei liegen wird, zum Beispiel www.firma.de. Daraus leitet der Generator alle leeren Felder ab.

Funktionspostfach für Meldungen zu Ihren Produkten. Leer bleibt:

Funktionspostfach für Lücken in Webseite, Shop und Servern. Leer bleibt:

Webseite, über die man auch ohne E-Mail und anonym melden kann. Leer bleibt: Leer lassen, wenn es keine gibt.

Seite mit Ihren Regeln für Meldende. Einen Entwurf erzeugt dieses Werkzeug weiter unten. Leer bleibt:

Öffentlicher Schlüssel, damit Meldende verschlüsselt schreiben können. Leer bleibt: Leer lassen, wenn es keinen gibt.

Schlüssel des IT-Postfachs. Leer bleibt:

Vorgeschlagen ist knapp ein Jahr. Danach gilt die Datei als abgelaufen.

Sprachen
Weitere Sprachen

In welchen Sprachen Sie Meldungen annehmen. Mindestens eine Sprache. Englisch ist Pflicht.

Weitere Felder: Danksagungen, CSAF, Bug-Bounty, Stellenangebote

Seite, auf der Sie Meldenden danken. Leer lassen, wenn es keine gibt.

Nur wenn Sie Sicherheitshinweise maschinenlesbar im Format CSAF veröffentlichen.

Ob Sie Meldende über ein Bug-Bounty-Programm bezahlen.

Stellenanzeigen für Sicherheitsfachleute. Nicht Teil der TR.

Ihre security.txt


      

    Entwurf der CVD-Richtlinie

    Auf die Richtlinie zeigt das Feld Policy. Der Entwurf enthält die Mindestinhalte nach Abschnitt 4.4 der TR-03183-3 und übernimmt Ihre Adressen. Er ist ein Ausgangspunkt, kein fertiger Text: Prüfen Sie jede Zusage darauf, ob Sie sie mit Vertretung einhalten können.

    optional

    Leer bleibt ein Platzhalter in eckigen Klammern.

    optional

    Weiterer Meldeweg. Erscheint nur in der Richtlinie, nicht in der security.txt.

    Sprache des Entwurfs

    Nach dem Erzeugen: signieren, veröffentlichen, prüfen

    Die Datei ist in Minuten geschrieben. Damit Werkzeuge und Meldende sie finden und ihr trauen, folgen drei Schritte.

    1. Signieren

      RFC 9116 empfiehlt eine OpenPGP-Signatur, die TR verlangt sie (4.2.10). Ein Befehl legt sie um den Text, die Datei bleibt lesbar: gpg --clearsign security.txt

    2. Veröffentlichen

      Die Datei gehört nach /.well-known/security.txt, über HTTPS als text/plain, ohne Weiterleitung. Firewall und Bot-Schutz dürfen Prüfdienste nicht aussperren (TR 4.2.11).

    3. Prüfen und pflegen

      Der Check ruft die Datei ab und prüft Aufbau, Verweise, Schlüssel und Signatur. Vor dem Ablaufdatum erneuern, den Inhalt nach der TR vierteljährlich prüfen.

    Alle Felder, die Unterschiede zwischen RFC 9116 und TR-03183-3 und die häufigsten Fehler erklärt die Anleitung. Fertige Dateien zum Vergleichen zeigen die Beispiele.