security.txt für CRA-Compliance einrichten: Eine 10-Minuten-Anleitung

Der CRA erfordert einen öffentlich verfügbaren Kontaktpunkt für Schwachstellenmeldungen. Der einfachste Weg zur Compliance? Eine security.txt-Datei.

Diese 10-Minuten-Anleitung bringt Sie von null zu konform.

Was ist security.txt?

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

Warum es für CRA wichtig ist:

• CRA erfordert Schwachstellenmelde-Kontaktpunkte
• security.txt ist die Branchenstandard-Methode
• Automatisierte Tools und Forscher suchen danach
• Zeigt Regulierungsbehörden, dass Sie ordnungsgemäße Offenlegungskanäle implementiert haben

Die minimale security.txt

Hier ist die einfachste konforme Datei:

Contact: mailto:security@ihrfirma.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, professionelle security.txt:

# Sicherheitskontaktinformationen für [Ihre Firma]
# https://www.ihrfirma.com/.well-known/security.txt

Contact: mailto:security@ihrfirma.com
Contact: https://ihrfirma.com/security/melden
Expires: 2027-01-01T00:00:00.000Z
Encryption: https://ihrfirma.com/.well-known/pgp-key.txt
Preferred-Languages: de, en, fr
Canonical: https://ihrfirma.com/.well-known/security.txt
Policy: https://ihrfirma.com/security/offenlegungsrichtlinie
Hiring: https://ihrfirma.com/karriere/sicherheit
Acknowledgments: https://ihrfirma.com/security/danke

Feld-für-Feld-Erklärung

Contact (Erforderlich)

Wie Forscher Sie erreichen sollten.

Contact: mailto:security@ihrfirma.com
Contact: https://ihrfirma.com/security/melden

Best Practices:

• Sowohl E-Mail ALS AUCH Webformular einschließen
• Team-Alias verwenden, nicht persönliche E-Mail
• Webformulare bieten strukturierte Erfassung
• Mehrere Contact-Zeilen sind erlaubt

Expires (Erforderlich)

Wann diese Datei als veraltet gelten sollte.

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

Best Practices:

• 6-12 Monate in der Zukunft setzen
• ISO 8601-Format mit Zeitzone verwenden
• Kalendererinnerung zum Aktualisieren vor Ablauf setzen
• Veraltete Dateien lassen Sie ungepflegt erscheinen

Encryption (Empfohlen)

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

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

Best Practices:

• Ihren öffentlichen Schlüssel unter der angegebenen URL hosten
• Team-Schlüssel verwenden, nicht individuellen Schlüssel
• Schlüssel-Fingerprint in Kommentaren einfügen
• Privaten Schlüssel sicher aufbewahren (HSM falls möglich)

Preferred-Languages (Empfohlen)

Sprachen, in denen Ihr Team Meldungen bearbeiten kann.

Preferred-Languages: de, en, fr

Best Practices:

• Sprachen auflisten, die Ihr Sicherheitsteam tatsächlich spricht
• Englisch sollte normalerweise enthalten sein
• Nach Präferenz sortieren
• Keine Sprachen auflisten, in denen Sie nicht wirklich antworten können

Canonical (Empfohlen)

Der autoritative Ort dieser Datei.

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

Warum es wichtig ist:

• Verhindert Spoofing
• Klärt, ob Datei gespiegelt ist
• Hilft Forschern bei der Authentizitätsprüfung

Policy (Empfohlen)

Link zu Ihrer vollständigen Schwachstellen-Offenlegungsrichtlinie.

Policy: https://ihrfirma.com/security/offenlegungsrichtlinie

Best Practices:

• Zu Ihrer vollständigen CVD-Richtlinie verlinken
• Sicherstellen, dass die Seite existiert und zugänglich ist
• Richtlinie und security.txt synchron halten

Acknowledgments (Optional)

Link zu Ihrer Sicherheits-Hall-of-Fame.

Acknowledgments: https://ihrfirma.com/security/danke

Warum es einschließen:

• Zeigt, dass Sie Forscher wertschätzen
• Ermutigt zu Meldungen (Anerkennung motiviert)
• Zeigt ausgereiftes Sicherheitsprogramm

Hiring (Optional)

Link zu Sicherheits-Stellenausschreibungen.

Hiring: https://ihrfirma.com/karriere/sicherheit

Warum es einschließen:

• Forscher sind oft gute Kandidaten
• Zeigt Investition in Sicherheit
• Gute Community-Beziehungen

Schritt-für-Schritt-Einrichtung

Schritt 1: Datei erstellen

Erstellen Sie eine Textdatei mit Ihren Informationen:

# Datei erstellen
cat > security.txt << 'EOF'
# Sicherheitskontaktinformationen für IhreFirma
# Zuletzt aktualisiert: 2026-01-15

Contact: mailto:security@ihrfirma.com
Contact: https://ihrfirma.com/security/melden
Expires: 2027-01-15T00:00:00.000Z
Preferred-Languages: de, en
Canonical: https://ihrfirma.com/.well-known/security.txt
Policy: https://ihrfirma.com/security/richtlinie
EOF

Schritt 2: Hosting-Ort wählen

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

Für Websites:

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

Für Produkte mit Web-Interfaces:

https://produkt.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 zugänglich ist:

curl https://ihrfirma.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 Authentizität:

# Mit GPG signieren
gpg --clearsign security.txt

# Dies erstellt security.txt.asc
# Umbenennen und deployen
mv security.txt.asc security.txt

Signierte Datei sieht so aus:

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

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

-----BEGIN PGP SIGNATURE-----
[Signaturdaten]
-----END PGP SIGNATURE-----

Für Produkte ohne Web-Interfaces

Nicht alle Produkte haben Webserver. So handhaben Sie security.txt:

Eingebettete Geräte

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

• security.txt auf diesem Interface hosten
• http://gerät-ip/.well-known/security.txt

Option 2: Falls kein Web-Interface:

• URL in Produktdokumentation aufnehmen
• Auf Ihre Unternehmens-security.txt verweisen
• Zur Kurzanleitung hinzufügen: "Sicherheitsprobleme melden unter: https://firma.com/security"

Desktop-Software

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

Mobile Apps

• In App Einstellungen > Über > Sicherheit einfügen
• Zu Unternehmens-security.txt verlinken
• Zur App-Store-Beschreibung hinzufügen

Dokumentationsverweis

Zu Ihrer Produktdokumentation hinzufügen:

## Sicherheits-Schwachstellenmeldung

Um Sicherheitsschwachstellen in diesem Produkt zu melden:

- E-Mail: security@ihrfirma.com
- Web: https://ihrfirma.com/security/melden
- Richtlinie: https://ihrfirma.com/security/richtlinie

Unsere security.txt-Datei: https://ihrfirma.com/.well-known/security.txt

Häufige Fehler

Abgelaufene Datei

Problem: Expires-Datum liegt in der Vergangenheit.

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

Lösung: Zukünftiges Datum setzen. Kalendererinnerung hinzufügen.

Falscher Ort

Problem: Datei unter falschem Pfad.

/security.txt           # Falsch
/security/security.txt  # Falsch
/.well-known/security.txt  # Richtig

Lösung: Standardort verwenden.

Ungültiges Format

Problem: Falsches Datumsformat, fehlende Felder.

Expires: 1. Januar 2027  # Falsches Format
Contact: Sicherheitsteam    # Keine gültige URI

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

Tote Links

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

Lösung: Alle Links prüfen, dass sie funktionieren. Nach Deployments prüfen.

Persönliche E-Mail

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

Contact: mailto:max.mustermann@ihrfirma.com  # Schlecht

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

Kein HTTPS

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

Lösung: Immer HTTPS für sicherheitsrelevante URLs verwenden.

Validierungs-Checkliste

SECURITY.TXT VALIDIERUNGS-CHECKLISTE

ERFORDERLICHE FELDER:
[ ] Contact-Feld vorhanden (mailto: oder https:)
[ ] Expires-Feld vorhanden (zukünftiges Datum, ISO 8601)

EMPFOHLENE FELDER:
[ ] Preferred-Languages enthalten
[ ] Canonical-URL stimmt mit tatsächlichem Ort überein
[ ] Policy-Link funktioniert und zeigt auf CVD-Richtlinie
[ ] Encryption-Schlüssel-Link funktioniert (falls enthalten)

HOSTING:
[ ] Datei unter /.well-known/security.txt
[ ] HTTPS zugänglich
[ ] Content-Type: text/plain
[ ] Keine Authentifizierung erforderlich

VERIFIZIERUNG:
[ ] curl-Test erfolgreich
[ ] Online-Validator bestanden
[ ] Alle Links erreichbar (keine 404s)
[ ] PGP-Signatur gültig (falls signiert)

WARTUNG:
[ ] Kalendererinnerung vor Expires-Datum gesetzt
[ ] Aktualisierungsprozess dokumentiert
[ ] Überwachung der Zugänglichkeit

Wartungsplan

Integration mit CRA-Compliance

Ihre security.txt unterstützt CRA-Compliance durch:

1. Entdeckbaren Kontakt bereitstellen: Regulierungsbehörden und Forscher können Sie finden
2. Prozess demonstrieren: Zeigt, dass Sie Schwachstellenbehandlung haben
3. CVD ermöglichen: Verlinkt zu Ihrer Offenlegungsrichtlinie
4. Dokumentation unterstützen: Verweis in technischer Datei

In Ihrer technischen Dokumentation aufnehmen:

Schwachstellenmelde-Kontaktpunkte:
- security.txt: https://firma.com/.well-known/security.txt
- E-Mail: security@firma.com
- Webformular: https://firma.com/security/melden
- Richtlinie: https://firma.com/security/richtlinie

Vollständiges Beispiel

Hier ist eine produktionsreife security.txt:

# ============================================================
# SECURITY.TXT für AcmeTech Produkte
# https://acmetech.eu/.well-known/security.txt
# ============================================================
#
# Wenn Sie eine Sicherheitsschwachstelle in einem AcmeTech-
# Produkt gefunden haben, melden Sie diese bitte über die
# unten stehenden Kontaktmethoden.
#
# Wir schätzen verantwortungsvolle Offenlegung und werden
# Ihren Beitrag auf Wunsch würdigen.
#
# ============================================================

# Primäre Kontaktmethoden (bevorzugte Reihenfolge)
Contact: https://acmetech.eu/security/melden
Contact: mailto:security@acmetech.eu

# Diese Datei läuft ab (vor diesem Datum aktualisieren)
Expires: 2027-06-01T00:00:00.000Z

# Für verschlüsselte Kommunikation
Encryption: https://acmetech.eu/.well-known/pgp-key.txt

# Sprachen, die unser Sicherheitsteam bearbeitet
Preferred-Languages: de, en, es

# Autoritativer Ort dieser Datei
Canonical: https://acmetech.eu/.well-known/security.txt

# Unsere Schwachstellen-Offenlegungsrichtlinie
Policy: https://acmetech.eu/security/offenlegungsrichtlinie

# Sicherheitsforscher, die uns geholfen haben
Acknowledgments: https://acmetech.eu/security/hall-of-fame

# Werden Sie Teil unseres Sicherheitsteams
Hiring: https://acmetech.eu/karriere#sicherheit

# ============================================================
# Zuletzt aktualisiert: 2026-01-15
# Bei Fragen zu dieser Datei: security@acmetech.eu
# ============================================================

Verwandte Leitfäden

• Koordinierte Schwachstellenoffenlegung nach CRA: Richtlinien-Vorlage
• ENISA-Schwachstellenmeldung: Die 24-Stunden-Anforderung
• CRA-Technische Datei (Anhang VII) Leitfaden

Wie CRA Evidence hilft

CRA Evidence kann:

• security.txt generieren: Vorausgefüllt mit Ihren Organisationsdetails
• Ablauf überwachen: Warnung vor Ablauf Ihrer Datei
• Format validieren: Auf häufige Fehler prüfen
• Updates verfolgen: Audit-Trail von Änderungen

Richten Sie Ihre security.txt ein unter app.craevidence.com.

Dieser Artikel dient nur zu Informationszwecken und stellt keine Rechtsberatung dar. Für spezifische Compliance-Anleitung konsultieren Sie qualifizierten Rechtsberater.