security.txt nach RFC 9116: Pflichtfelder und Beispiel

Der CRA verlangt von Herstellern einen öffentlich erreichbaren Kontaktpunkt, über den Forscher und Kunden Schwachstellen melden können. Der Standard dafür ist RFC 9116, eine Textdatei namens security.txt, gehostet unter /.well-known/security.txt. Zwei Pflichtfelder, einige empfohlene Felder und etwa 10 Minuten Arbeit.

Diese Anleitung behandelt die Felder, das Hosting, häufige Fehler und was Sie in Ihrer technischen Datei referenzieren müssen.

Was ist security.txt?

security.txt ist ein RFC-Standard (RFC 9116), der eine maschinen- und menschenlesbare Möglichkeit bietet, Sicherheitskontaktinformationen zu veröffentlichen.

Der CRA verlangt von Herstellern, einen Kontaktpunkt für Schwachstellenmeldungen zu veröffentlichen. security.txt ist die branchenübliche Methode dafür. Automatisierte Scan-Tools und Sicherheitsforscher prüfen standardmäßig auf diese Datei. Wer sie eingerichtet hat, sendet Regulierungsbehörden ein konkretes Signal: Die Offenlegungskanäle sind vorhanden und funktionieren.

Die minimale security.txt

Hier ist die einfachste konforme Datei:

Contact: mailto:security@yourcompany.com
Expires: 2027-12-31T23:59:59.000Z

Das war's. Zwei Zeilen. Sie sind technisch konform.

Aber lassen Sie uns es besser machen.

Die empfohlene security.txt

Eine vollständige security.txt:

# Security Contact Information for [Your Company]
# https://www.yourcompany.com/.well-known/security.txt

Contact: mailto:security@yourcompany.com
Contact: https://yourcompany.com/security/report
Expires: 2027-01-01T00:00:00.000Z
Encryption: https://yourcompany.com/.well-known/pgp-key.txt
Preferred-Languages: en, de, fr
Canonical: https://yourcompany.com/.well-known/security.txt
Policy: https://yourcompany.com/security/disclosure-policy
Hiring: https://yourcompany.com/careers/security
Acknowledgments: https://yourcompany.com/security/thanks

Feld-für-Feld-Erklärung

Contact (Erforderlich)

Wie Forscher Sie erreichen sollten.

Contact: mailto:security@yourcompany.com
Contact: https://yourcompany.com/security/report

Verwenden Sie einen Team-Alias, keine persönliche E-Mail-Adresse. Geben Sie sowohl eine E-Mail-Adresse als auch ein Webformular an, falls vorhanden. Mehrere Contact-Zeilen sind erlaubt, und das Formular ermöglicht eine strukturierte Erfassung.

Expires (Erforderlich)

Ab wann diese Datei als veraltet gilt.

Expires: 2027-01-01T00:00:00.000Z

Setzen Sie das Datum 6 bis 12 Monate in der Zukunft, im ISO 8601-Format mit Zeitzone. Legen Sie eine Kalendererinnerung an, bevor es abläuft. Eine veraltete Datei zeigt Forschern, dass Sie sie nicht pflegen.

Encryption (Empfohlen)

PGP-Schlüssel für verschlüsselte Meldungen.

Encryption: https://yourcompany.com/.well-known/pgp-key.txt

Verwenden Sie einen Team-Schlüssel statt eines individuellen Schlüssels und bewahren Sie den privaten Schlüssel nach Möglichkeit in einem HSM auf. Fügen Sie den Fingerabdruck in den Kommentaren ein, damit Forscher ihn unabhängig verifizieren können.

Preferred-Languages (Empfohlen)

Sprachen, in denen Ihr Team Meldungen bearbeiten kann.

Preferred-Languages: en, de, fr

Listen Sie nur Sprachen auf, in denen Ihr Sicherheitsteam tatsächlich antworten kann. Sortieren Sie nach Präferenz. Wenn Sie Deutsch angeben, aber niemand im Team Deutsch liest, erhalten Sie Meldungen, die Sie nicht triagen können.

Canonical (Empfohlen)

Der autoritative Speicherort dieser Datei.

Canonical: https://yourcompany.com/.well-known/security.txt

Verhindert Spoofing und klärt, ob die Datei gespiegelt wird. Forscher können die Canonical-URL mit dem abgerufenen Inhalt abgleichen, um die Authentizität zu bestätigen.

Policy (Empfohlen)

Link zu Ihrer vollständigen Schwachstellen-Offenlegungsrichtlinie.

Policy: https://yourcompany.com/security/disclosure-policy

Stellen Sie sicher, dass die Seite existiert und ohne Authentifizierung ladbar ist. Ein toter Policy-Link bei einer Sicherheitsprüfung hinterlässt keinen guten Eindruck.

Acknowledgments (Optional)

Link zu Ihrer Sicherheits-Hall-of-Fame.

Acknowledgments: https://yourcompany.com/security/thanks

Forscher, die Schwachstellen finden, sind oft gute Kandidaten für Ihr Sicherheitsteam. Anerkennung fördert außerdem weitere Meldungen. Die meisten Forscher priorisieren Organisationen, die ihre Arbeit würdigen.

Hiring (Optional)

Link zu Stellenausschreibungen im Sicherheitsbereich.

Hiring: https://yourcompany.com/careers/security

Lohnt sich, wenn Sie offene Stellen im Sicherheitsbereich haben. Forscher, die aktiv nach Arbeit suchen, schauen sich diese Links an.

Schritt-für-Schritt-Einrichtung

Schritt 1: Datei erstellen

Erstellen Sie eine Textdatei mit Ihren Informationen:

# Create the file
cat > security.txt << 'EOF'
# Security Contact Information for YourCompany
# Last Updated: 2026-01-15

Contact: mailto:security@yourcompany.com
Contact: https://yourcompany.com/security/report
Expires: 2027-01-15T00:00:00.000Z
Preferred-Languages: en
Canonical: https://yourcompany.com/.well-known/security.txt
Policy: https://yourcompany.com/security/policy
EOF

Schritt 2: Hosting-Ort wählen

Die Datei muss unter /.well-known/security.txt liegen.

Für Websites:

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

Für Produkte mit Web-Interfaces:

https://product.local/.well-known/security.txt
https://192.168.1.1/.well-known/security.txt

Schritt 3: Webserver konfigurieren

Nginx:

location /.well-known/security.txt {
    alias /var/www/security.txt;
    default_type text/plain;
}

Apache:

Alias /.well-known/security.txt /var/www/security.txt
<Files "security.txt">
    ForceType text/plain
</Files>

Express.js:

const express = require('express');
const app = express();

app.get('/.well-known/security.txt', (req, res) => {
    res.type('text/plain');
    res.sendFile(__dirname + '/security.txt');
});

Statisches Hosting (S3, GitHub Pages, etc.): Platzieren Sie die Datei einfach im .well-known-Verzeichnis.

Schritt 4: Überprüfen

Prüfen Sie, ob Ihre Datei erreichbar ist:

curl https://yourcompany.com/.well-known/security.txt

Verwenden Sie einen Online-Validator:

• https://securitytxt.org/

Schritt 5: Signieren (Optional, aber empfohlen)

Signieren Sie Ihre security.txt digital für mehr Authentizität:

# Sign with GPG
gpg --clearsign security.txt

# This creates security.txt.asc
# Rename and deploy
mv security.txt.asc security.txt

Eine signierte Datei sieht so aus:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Contact: mailto:security@yourcompany.com
Expires: 2027-01-01T00:00:00.000Z
...

-----BEGIN PGP SIGNATURE-----
[signature data]
-----END PGP SIGNATURE-----

Für Produkte ohne Web-Interfaces

Nicht alle Produkte haben Webserver. So gehen Sie mit security.txt um:

Eingebettete Geräte

Option 1: Falls das Gerät irgendein Web-Interface hat (Konfigurationsseite, Statusseite):

• security.txt auf diesem Interface hosten
• http://device-ip/.well-known/security.txt

Option 2: Falls kein Web-Interface vorhanden ist:

• URL in Produktdokumentation aufnehmen
• Auf Ihre Unternehmens-security.txt verweisen
• Zur Schnellstartanleitung hinzufügen: „Sicherheitsprobleme melden unter: https://company.com/security“

Desktop-Software

• Sicherheitskontakt in Hilfe > Über aufnehmen
• Zu README/Dokumentation hinzufügen
• Unternehmens-security.txt-URL referenzieren

Mobile Apps

• In App-Einstellungen > Über > Sicherheit aufnehmen
• Zur Unternehmens-security.txt verlinken
• In App-Store-Beschreibung aufnehmen

Dokumentationsverweis

Fügen Sie Folgendes Ihrer Produktdokumentation hinzu:

## Security Vulnerability Reporting

To report security vulnerabilities in this product:

- Email: security@yourcompany.com
- Web: https://yourcompany.com/security/report
- Policy: https://yourcompany.com/security/policy

Our security.txt file: https://yourcompany.com/.well-known/security.txt

Häufige Fehler

Abgelaufene Datei

Problem: Das Expires-Datum liegt in der Vergangenheit.

Expires: 2024-01-01T00:00:00.000Z  # EXPIRED!

Lösung: Zukünftiges Datum setzen. Kalendererinnerung anlegen.

Falscher Speicherort

Problem: Datei unter falschem Pfad.

/security.txt           # Wrong
/security/security.txt  # Wrong
/.well-known/security.txt  # Correct

Lösung: Standardspeicherort verwenden.

Ungültiges Format

Problem: Falsches Datumsformat, fehlende Felder.

Expires: January 1, 2027  # Wrong format
Contact: security team    # Not a valid URI

Lösung: ISO 8601-Datumsformat verwenden, mailto:- oder https:-URIs angeben.

Tote Links

Problem: Policy- oder Acknowledgments-URLs geben 404 zurück.

Lösung: Alle Links prüfen. Nach Deployments erneut prüfen.

Persönliche E-Mail

Problem: Individuelle E-Mail-Adresse statt Team-Alias.

Contact: mailto:john.smith@yourcompany.com  # Bad

Lösung: Team-Alias verwenden, der Personalwechsel überlebt.

Kein HTTPS

Problem: HTTP statt HTTPS für Canonical- und Policy-Links.

Lösung: Für sicherheitsrelevante URLs immer HTTPS verwenden.

Validierungs-Checkliste

SECURITY.TXT VALIDATION CHECKLIST

REQUIRED FIELDS:
[ ] Contact field present (mailto: or https:)
[ ] Expires field present (future date, ISO 8601)

RECOMMENDED FIELDS:
[ ] Preferred-Languages included
[ ] Canonical URL matches actual location
[ ] Policy link works and points to CVD policy
[ ] Encryption key link works (if included)

HOSTING:
[ ] File at /.well-known/security.txt
[ ] HTTPS accessible
[ ] Content-Type: text/plain
[ ] No authentication required

VERIFICATION:
[ ] curl test successful
[ ] Online validator passes
[ ] Links all resolve (no 404s)
[ ] PGP signature valid (if signed)

MAINTENANCE:
[ ] Calendar reminder set for before Expires date
[ ] Update process documented
[ ] Monitoring for accessibility

Wartungsplan

Was in Ihre technische Datei gehört

Der CRA verlangt von Herstellern, eine technische Datei (Annex VII) zu führen, die den Prozess zur Schwachstellenbehandlung dokumentiert. Ihre security.txt-Datei und die darin verlinkte CVD-Richtlinie sind direkte Eingaben in diese Dokumentation.

Konkret sollte Ihre technische Datei Folgendes referenzieren:

• Die security.txt-URL und welche Kontaktmethoden sie exponiert
• Die URL der Offenlegungsrichtlinie, auf die sie verlinkt
• Die Reaktions-SLAs, zu denen Sie sich in dieser Richtlinie verpflichtet haben

Regulierungsbehörden, die Ihre technische Datei prüfen, suchen nach Belegen dafür, dass ein funktionierender Prozess zur Schwachstellenerfassung existiert. Eine aktive, nicht abgelaufene security.txt mit einem funktionierenden Policy-Link ist ein konkretes Signal. Eine abgelaufene Datei oder tote Links wirken sich negativ aus.

Fügen Sie diesen Block Ihrer Dokumentation zur Schwachstellenbehandlung hinzu:

Vulnerability Reporting Contact Points:
- security.txt: https://company.com/.well-known/security.txt
- Email: security@company.com
- Web Form: https://company.com/security/report
- Policy: https://company.com/security/policy

Vollständiges Beispiel

Hier ist eine produktionsreife security.txt:

# ============================================================
# SECURITY.TXT for AcmeTech Products
# https://acmetech.eu/.well-known/security.txt
# ============================================================
#
# If you've found a security vulnerability in any AcmeTech
# product, please report it using the contact methods below.
#
# We appreciate responsible disclosure and will acknowledge
# your contribution if desired.
#
# ============================================================

# Primary contact methods (preferred order)
Contact: https://acmetech.eu/security/report
Contact: mailto:security@acmetech.eu

# This file expires (update before this date)
Expires: 2027-06-01T00:00:00.000Z

# For encrypted communications
Encryption: https://acmetech.eu/.well-known/pgp-key.txt

# Languages our security team handles
Preferred-Languages: en, de, es

# Authoritative location of this file
Canonical: https://acmetech.eu/.well-known/security.txt

# Our vulnerability disclosure policy
Policy: https://acmetech.eu/security/disclosure-policy

# Security researchers who've helped us
Acknowledgments: https://acmetech.eu/security/hall-of-fame

# Join our security team
Hiring: https://acmetech.eu/careers#security

# ============================================================
# Last Updated: 2026-01-15
# Contact security@acmetech.eu with questions about this file
# ============================================================

Wie CRA Evidence hilft

security.txt ist ein Baustein im Bereich Schwachstellenbehandlung. Der schwierigere Teil ist der vollständige Prozess dahinter: Richtlinie, Triage-SLAs, ENISA-Meldung und die Dokumentation in Ihrer technischen Datei. Genau dafür ist CRA Evidence da.

Starten Sie unter craevidence.com.

Dieser Artikel dient nur zu Informationszwecken und stellt keine Rechtsberatung dar. Für spezifische Compliance-Hinweise wenden Sie sich an qualifizierte Rechtsberater.