security.txt und Meldeseite im Sicherheitsprofil: der günstigste Nachweis

Inhalt in Kürze

• Sicherheitsfragebögen fragen fast immer nach einem Prozess für gemeldete Schwachstellen. Eine öffentliche Meldeseite plus security.txt beantwortet das in einer halben Stunde.
• RFC 9116 beschreibt die Datei unter /.well-known/security.txt. Sie ist eine Konvention, keine Rechtspflicht.
• Für Hersteller kommt die Pflicht aus dem Cyber Resilience Act: Anhang I Teil II Nr. 5 der Verordnung (EU) 2024/2847 verlangt eine Strategie zur koordinierten Offenlegung von Schwachstellen.
• Wer kein Hersteller ist, hat keine Pflicht — aber denselben Nutzen im Einkaufsprozess.

Block sieben in fast jedem Lieferantenfragebogen heißt sinngemäß: „Beschreiben Sie Ihren Prozess für den Umgang mit gemeldeten Sicherheitslücken.” Die meisten Zulieferer schreiben dort einen Satz über ihr Ticketsystem hin. Das ist nicht falsch, aber es ist auch nicht prüfbar.

Es gibt eine Antwort, die sich in dreißig Minuten herstellen lässt und die der Prüfende selbst nachsehen kann: eine öffentliche Meldeseite und eine security.txt.

Was security.txt ist — und was nicht

RFC 9116 beschreibt eine Textdatei unter /.well-known/security.txt, die menschen- und maschinenlesbar sagt, wohin die Meldung einer Schwachstelle geht. Sicherheitsforscher und automatisierte Scanner sehen dort zuerst nach.

Contact: mailto:security@ihre-domain.de
Contact: https://app.fraghugo.de/cvd/ihr-unternehmen
Contact: tel:+49-40-0000000
Expires: 2027-09-05T23:59:59.000Z
Preferred-Languages: de, en
Policy: https://app.fraghugo.de/cvd/ihr-unternehmen
Canonical: https://www.ihre-domain.de/.well-known/security.txt

Die Felder im Einzelnen:

Zwei Punkte, an denen es in der Praxis hakt. Die Datei gehört unter /.well-known/, nicht ins Wurzelverzeichnis — dort findet sie kein Werkzeug. Und Expires ist eine Pflichtangabe, die tatsächlich abläuft: Eine abgelaufene Datei ist schlechter als gar keine, weil sie Aktualität vortäuscht.

Woher die Pflicht kommt, wenn sie kommt

Für Hersteller von Produkten mit digitalen Elementen gibt es eine Rechtsgrundlage. Der Cyber Resilience Act, Verordnung (EU) 2024/2847, verlangt in Anhang I Teil II Nr. 5, eine Strategie für die koordinierte Offenlegung von Schwachstellen „aufzustellen und umzusetzen”. Nummer 6 desselben Anhangs verlangt eine Kontaktadresse für die Meldung entdeckter Schwachstellen.

Der Begriff security.txt kommt dort nicht vor. Die Verordnung beschreibt das Ziel, nicht das Format. Welche Fristen dabei gelten und was die Strategie im Einzelnen enthalten muss, steht ausführlich im Beitrag CVD-Policy und security.txt in 30 Minuten.

Und wenn Sie kein Hersteller sind? Dann folgt aus dem Cyber Resilience Act für Sie nichts. Der Nutzen bleibt trotzdem — nur die Begründung ändert sich: nicht Pflicht, sondern Nachweis gegenüber Ihren Auftraggebern.

Warum das im Sicherheitsprofil so gut funktioniert

Ein öffentliches Sicherheitsprofil hat ein Grundproblem: Vieles, was Auftraggeber interessiert, darf gar nicht öffentlich stehen. Systemversionen, Netzstruktur, offene Befunde — all das gehört hinter eine Vertraulichkeitsvereinbarung. Welche Angaben öffentlich unbedenklich sind, klärt der Beitrag zum Trust Center für KMU.

Der Meldeweg für Schwachstellen ist die Ausnahme. Er ist vollständig öffentlich beantwortbar, weil er nichts über Ihre Systeme verrät — nur darüber, wie Sie mit einer Meldung umgehen. Genau deshalb ist er der wirksamste Block auf der Seite:

• Er ist überprüfbar. Der Prüfende ruft die Adresse auf und sieht, ob es die Seite gibt. Kein Nachweis-Anhang nötig.
• Er ist datiert. Das Expires-Feld sagt, ob sich jemand darum kümmert.
• Er kostet nichts. Keine Zertifizierung, kein Werkzeug, kein Prüfer.
• Er wirkt sofort. Ab dem Tag der Veröffentlichung ist er der Kanal, über den Sie von einem Problem erfahren, bevor es jemand anderes tut.

Aus der Praxis

Unsere interessanteste Datenpanne war ein Dienstleister mit nur 15 Mitarbeitern, bei dem der Geschäftsführer eine E-Mail von einem Geschäftspartner bekam. Die E-Mail kam wirklich von diesem Geschäftspartner – trotzdem war es ein Angriff.

Nils OehmichenDatenschutzberater bei frag.hugo

Die unangenehme Nachricht kommt selten aus dem eigenen Haus. Sie kommt von außen — von einem Kunden, einem Partner, einem Forscher. Wer keinen offensichtlichen Meldeweg anbietet, erfährt es entsprechend spät.

Die häufigste Lücke ist kein Format, sondern ein Postfach

Wir sehen regelmäßig Betriebe mit ordentlicher security.txt, hinter der eine Verteileradresse mit vier Empfängern liegt, von denen sich niemand zuständig fühlt. Das ist die teuerste Variante: Die Meldung liegt vor, niemand bearbeitet sie — und im Nachhinein ist dokumentiert, dass sie an Tag null bekannt war.

In dreißig Minuten erledigt

1. Postfach anlegen und zuweisen (10 Min.). Eine Adresse wie security@ihre-domain.de, mit benannter Person und Vertretung.
2. Meldeseite veröffentlichen (10 Min.). Geltungsbereich, Meldewege, Reaktionszeiten, Umgang mit gutgläubig Meldenden, Veröffentlichungspraxis. Eine Seite reicht.
3. security.txt ablegen (5 Min.). Unter /.well-known/security.txt, mit Expires und einem Policy-Verweis auf die Meldeseite.
4. Ins Sicherheitsprofil aufnehmen (5 Min.). Ein Satz im Notfall-Block, der auf beide Adressen verlinkt. Damit ist Block sieben jedes Fragebogens beantwortet.

Danach eine Wiedervorlage: Expires erneuern, bevor es abläuft, und einmal im Jahr prüfen, ob die genannten Zeiten noch stimmen.

Ihr nächster Schritt

Wenn Sie heute nur eine Sache aus diesem Beitrag umsetzen: das Postfach mit benannter Zuständigkeit. Die Datei und die Seite sind danach eine Formsache — ohne die Zuständigkeit sind sie Kosmetik.

Wie Sie den Rest des Fragebogens angehen, steht im Leitfaden für Zulieferer. Welche Forderungen Ihres Auftraggebers eine Grundlage haben und welche nicht, klärt der Beitrag Was Auftraggeber nach NIS2 von Lieferanten verlangen.

Häufige Fragen (FAQ)

Was ist eine security.txt?

Eine Textdatei unter /.well-known/security.txt, deren Aufbau RFC 9116 beschreibt. Sie sagt menschen- und maschinenlesbar, wohin die Meldung einer Schwachstelle geht. Pflichtangaben sind mindestens ein Contact-Feld und ein Expires-Feld mit Ablaufdatum; Policy, Preferred-Languages und Canonical sind üblich.

Ist eine security.txt gesetzlich vorgeschrieben?

Nein. Der Begriff kommt in keinem Rechtsakt vor. Für Hersteller von Produkten mit digitalen Elementen verlangt der Cyber Resilience Act (Verordnung (EU) 2024/2847) in Anhang I Teil II Nr. 5 eine Strategie zur koordinierten Offenlegung von Schwachstellen. Eine security.txt ist ein bewährter Weg, die dazugehörige Erreichbarkeit herzustellen — mehr nicht.

Brauche ich das, wenn ich gar kein Hersteller bin?

Aus dem Cyber Resilience Act folgt dann keine Pflicht. Der Nutzen bleibt: Sicherheitsfragebögen von Auftraggebern fragen regelmäßig nach einem Prozess für gemeldete Schwachstellen, und eine öffentliche Meldeseite ist die kürzeste belastbare Antwort darauf.

Was gehört auf eine Meldeseite für Schwachstellen?

Geltungsbereich, mindestens ein Meldeweg, an dessen Ende ein Mensch antwortet, eine Zusage zur Eingangsbestätigung, der Umgang mit gutgläubig Meldenden und die Praxis bei der Veröffentlichung. Dazu ein Stand-Datum. Wenn Sie kein Bug-Bounty-Programm anbieten, schreiben Sie das hin.

Warum ist das Expires-Feld wichtig?

RFC 9116 sieht es als Pflichtangabe vor. Eine abgelaufene security.txt ist schlechter als keine, weil sie Aktualität vortäuscht und die genannten Kontaktwege möglicherweise nicht mehr besetzt sind. Setzen Sie das Datum auf zwölf Monate und legen Sie eine Wiedervorlage an.

Wie hängt das mit dem Sicherheitsprofil zusammen?

Ein öffentliches Sicherheitsprofil beantwortet wiederkehrende Fragen aus Lieferantenfragebögen. Der Meldeweg für Schwachstellen ist einer dieser Blöcke — und einer der wenigen, die sich vollständig öffentlich beantworten lassen, ohne interne Details preiszugeben.