Cyber Resilience Act Response Center Demo anfragen

security.txt Generator nach RFC 9116 und BSI TR-03183-3

Tragen Sie Domain und Adressen ein, der Generator schreibt die Datei: mit den Kommentaren und der Reihenfolge, die die Technische Richtlinie des BSI vorsieht, einem gültigen Ablaufdatum und Hinweisen, was noch fehlt. Dazu auf Wunsch der Entwurf einer Richtlinie zur koordinierten Offenlegung.

Kostenlos, ohne Anmeldung. Die Datei entsteht in Ihrem Browser. Wir zeichnen auf, wie das Werkzeug genutzt wird, und speichern beim Kopieren oder Laden die eingetragene Domain, aber keine E-Mail-Adressen und keine weiteren Inhalte (Datenschutz). Grundlage: RFC 9116, BSI TR-03183-3 Version 1.0.0, Verordnung (EU) 2024/2847. Keine Rechtsberatung.

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 CRA, 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, Stellenangebote

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

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

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.
    
        
    
        
    
          
        
    
      
    
      
    
    
    
  
    

    


    
  
    
    
    Nach dem Erzeugen: veröffentlichen, signieren, prüfen
    
    
    Die Datei ist in Minuten geschrieben. Damit Werkzeuge und Behörden sie finden und ihr trauen, folgen drei Schritte.
    
  
    
  
    
    
    
      
    1. Signieren
    
      
    Die TR-03183-3 verlangt in Abschnitt 4.2.10 eine OpenPGP-Signatur nach RFC 9580, möglichst mit einem eigenen Schlüssel, der höchstens fünf Jahre gilt. RFC 9116 empfiehlt sie. Mit GnuPG genügt ein Befehl; er legt die Signatur um den Text, die Datei bleibt lesbar:
    
      
    gpg --clearsign --local-user psirt@ihre-domain.de security.txt
mv security.txt.asc security.txt
    
      
    Den öffentlichen Schlüssel als .asc-Datei unter der Adresse ablegen, die im Feld Encryption steht, und den Fingerabdruck auf der Meldeseite nennen (TR Abschnitt 4.3.2).
    
      
    2. Veröffentlichen
    
      
    Die Datei gehört nach /.well-known/security.txt, ausgeliefert über HTTPS als text/plain, ohne Weiterleitung. Firewall und DDoS-Schutz dürfen Prüfdienste nicht aussperren (TR Abschnitt 4.2.11).
    
    
    
    
    
      
    3. Prüfen
    
      
    Der Abruf muss Status 200 liefern: curl -sI https://ihre-domain.de/.well-known/security.txt. Die Signatur prüfen Sie mit gpg --verify security.txt. Die TR nennt findsecuritycontacts.com und internet.nl als Prüfdienste, die die Datei lesen können müssen. Alles auf einmal, samt Signatur, Schlüsseln und den Regeln der TR, prüft unser security.txt Check.
    
      
    4. Pflegen
    
      
    Das Ablaufdatum soll höchstens ein Jahr in der Zukunft liegen, den Inhalt verlangt die TR mindestens vierteljährlich zu prüfen (Abschnitt 4.2.9). Tragen Sie den nächsten Prüftermin gleich in den Kalender ein.
    
      
    Und dahinter?
    
      
    Eine security.txt ist nur so gut wie das Postfach dahinter. Erstantwort binnen 5 Werktagen, Detailantwort binnen 10 Werktagen (TR Abschnitt 4.4.8), und bei einer aktiv ausgenutzten Schwachstelle die Meldung nach Artikel 14 binnen 24 Stunden. Wer die Adressen liest und wer bewertet, beschreibt der Leitfaden PSIRT im Mittelstand.
    
    
    
  
    
  
    Alle Felder, die Unterschiede zwischen RFC 9116 und TR-03183-3 und die häufigsten Fehler erklärt die Anleitung zur security.txt. Was in die Richtlinie gehört, steht im Leitfaden CVD-Richtlinie. Die TR ist freiwillig; die Verordnung verlangt eine Kontaktadresse (Anhang I Teil II Nummer 6), aber kein Format.
    

    


    
  
    
    
    
      
    Die Datei steht. Wer liest das Postfach?
    
      
    CRA Response Center nimmt Meldungen an Ihrer Adresse an, prüft jede auf Hinweise für die Meldepflicht und weckt Ihre Rufkette, auch nachts und am Wochenende. Sie entscheiden, wir halten den Ablauf und den Nachweis.
    
    
    
    Demo anfragen