Provetry
ENFRFrühen Zugang anfragen
Kostenloser Check
Frühen Zugang anfragen

Provetry startet im November 2026. Der kostenlose CRA-Check, die Werkzeuge und die Leitfäden sind schon jetzt verfügbar.

security.txt und die CRA-Kontaktstelle für Schwachstellen

6 Min. Lesezeit

Auf dieser Seite
  1. Was der CRA verlangt
  2. Der Standard: RFC 9116
  3. Ein Beispiel
  4. Worauf es ankommt
  5. Wie Provetry hilft
  6. Quellen

Eine Forscherin findet eine Schwachstelle in Ihrem Produkt. Wohin schreibt sie? Allzu oft ist die Antwort ein allgemeines Kontaktformular, eine Vertriebsadresse oder gar nichts, und die Meldung geht verloren oder wird ohne Vorwarnung veröffentlicht. Eine security.txt-Datei behebt das mit einer kleinen Textdatei an einer vorhersehbaren Adresse, die jedem sagt, wen er wie kontaktieren soll.

Was der CRA verlangt

Die Cyberresilienz-Verordnung macht eine erreichbare Kontaktstelle für jeden Hersteller zur Pflicht:

  • Anhang I Teil II Nummer 6 verlangt von Herstellern, den Austausch von Informationen über mögliche Schwachstellen zu erleichtern, unter anderem durch eine Kontaktadresse für deren Meldung.
  • Artikel 13 Absatz 17 verlangt, eine zentrale Anlaufstelle zu benennen, über die Nutzer Schwachstellen melden können, und sie leicht auffindbar zu machen.
  • Anhang II Nummer 2 führt diese Anlaufstelle unter den Informationen auf, die dem Produkt beiliegen müssen.

Die Verordnung nennt security.txt nicht. Aber es ist der Internetstandard genau für diesen Zweck, Forschende und Scanner suchen zuerst danach, und es kostet nichts.

Der Standard: RFC 9116

security.txt wurde von der IETF im April 2022 als RFC 9116 veröffentlicht. Die Datei liegt unter:

https://example.com/.well-known/security.txt

Sie muss über HTTPS als reiner Text (text/plain; charset=utf-8) ausgeliefert werden. Jede Zeile ist ein Feld mit einem Wert:

Feld Pflicht Was es angibt
Contact Ja, mindestens eines Wohin gemeldet wird: eine mailto:-, https://- oder tel:-Adresse. Mehrere Zeilen erlaubt, nach Vorrang geordnet
Expires Ja, genau eines Das Datum, nach dem der Datei nicht mehr vertraut werden darf. Weniger als ein Jahr in der Zukunft halten
Encryption Nein Wo Ihr OpenPGP-Schlüssel liegt, damit Meldungen verschlüsselt werden können
Policy Nein Die Adresse Ihrer Strategie für die koordinierte Offenlegung von Schwachstellen
Acknowledgments Nein Eine Seite, die den meldenden Forschenden dankt
Preferred-Languages Nein Sprachen, in denen Sie Meldungen lesen, etwa de, en
Canonical Nein Die Adresse(n), unter der diese Datei liegen soll, um Kopien zu erkennen
Hiring Nein Stellen im Sicherheitsbereich, wenn Sie sie erwähnen wollen

Maschinenlesbare Sicherheitshinweise fügen ein weiteres hinzu: Das Feld CSAF, definiert vom Standard OASIS CSAF 2.0, verweist auf Ihre provider-metadata.json, damit Werkzeuge Ihre Hinweise finden.

Ein Beispiel

Contact: mailto:security@acme.example
Contact: https://acme.example/security/report
Expires: 2027-10-31T23:00:00.000Z
Encryption: https://acme.example/.well-known/openpgp-key.asc
Policy: https://acme.example/security/disclosure-policy
Acknowledgments: https://acme.example/security/thanks
Preferred-Languages: de, en
Canonical: https://acme.example/.well-known/security.txt
CSAF: https://acme.example/.well-known/csaf/provider-metadata.json

Mit unserem kostenlosen security.txt-Generator und -Prüfer können Sie Ihre eigene erstellen und prüfen.

Worauf es ankommt

  • Lassen Sie sie nicht ablaufen. Das Feld Expires ist genau dafür Pflicht, damit veraltete Dateien ignoriert werden. Eine Datei, die im letzten Frühjahr abgelaufen ist, sagt Forschenden, dass niemand mitliest. Tragen Sie sich einen Monat vor dem Datum eine Erinnerung ein und schreiben Sie die Datei jedes Jahr neu.
  • Nutzen Sie eine Adresse, die ein Mensch liest. Ein gemeinsames security@-Postfach, das mehr als eine Person überwacht, mit automatischer Eingangsbestätigung, ist die übliche Wahl. Nach dem CRA kann eine Meldung über eine ausgenutzte Schwachstelle eine 24-Stunden-Uhr starten: Sie darf nicht über einen Feiertag ungelesen liegen.
  • Verlinken Sie Ihre Offenlegungsstrategie. Das Feld Policy sollte auf eine veröffentlichte Strategie für die koordinierte Offenlegung von Schwachstellen zeigen, die der CRA ebenfalls verlangt.
  • Signieren Sie sie, wenn Sie können. RFC 9116 empfiehlt eine OpenPGP-Klartextsignatur um die Datei, damit Leser prüfen können, dass sie nicht manipuliert wurde.
  • Eine Datei pro Domain. Legen Sie sie auf jede Domain, die ein Produkt oder seine Dienste hostet, oder leiten Sie diese auf die Hauptdomain um.
  • Erwähnen Sie sie in Ihrer Produktdokumentation, damit die zentrale Anlaufstelle des CRA auch dort steht, wo Nutzer suchen: in der Gebrauchsanleitung, auf der Support-Seite, im „Über“-Bildschirm der App.

Wie Provetry hilft

In den kostenpflichtigen Tarifen erstellt Provetry Ihre Offenlegungsstrategie und eine security.txt aus wenigen Antworten, listet Ihre Produkte und deren Unterstützungszeiträume auf und fügt die CSAF-Zeile hinzu, sobald Sie eine öffentliche Seite für Hinweise eröffnen und Ihre Antworten erneut speichern. Die Datei muss vor ihrem Ablauf neu erstellt werden; die Seite Offenlegungsstrategie warnt Sie im Monat davor.

Quellen