security.txt für Startups 2026: So richtest du einen Sicherheitskontakt ein

Eine security.txt macht es Sicherheitsforschenden leicht, euch bei einer entdeckten Schwachstelle zu erreichen. Für Startups ist sie kein Konzern-Extra, sondern ein kleiner Hebel für schnellere Reaktionen.

Stell dir vor: Eine Sicherheitsforscherin stolpert über einen ungeschützten API-Endpunkt in eurem Kundenportal. Sie will euch informieren, findet auf der Website aber nur ein Sales-Kontaktformular, eine info@-Adresse und einen Chatbot. Ihre Mail landet im Support-Postfach, wird als Spam eingestuft oder wandert an den Vertrieb. Bis jemand versteht, worum es geht, vergehen Tage.

Genau diese Reibung nimmt euch ein klar veröffentlichter Sicherheitskontakt ab. Nach diesem Beitrag kannst du einen Sicherheitskontakt auf eurer Website und einen minimalen Meldeprozess in unter einem Arbeitstag aufsetzen.

Inhaltsverzeichnis

• Was hinter der kleinen Datei steckt
• Warum Erreichbarkeit Vertrauen schafft
• Vom Hinweis zur Behebung: der schlanke Meldeprozess
• Was der CRA-Bezug ab September 2026 bedeutet
• Datei korrekt aufsetzen: Felder, Beispiel und Test
• In 30 Minuten zu einem belastbaren Minimum
• Vier Gründerfälle: Worauf es jeweils ankommt
• Die Fehler, die den Nutzen wieder zunichtemachen
• FAQ
• Fazit

Was hinter der kleinen Datei steckt

Eine security.txt ist eine maschinenlesbare Textdatei mit Angaben dazu, wie eine Organisation Sicherheitslücken verantwortungsvoll melden lassen möchte. Sie enthält keine Geheimnisse, keine Konfiguration und keinen Code, sondern schlicht den Weg zu den richtigen Menschen.

Der technische Standard dahinter ist RFC 9116, eine Spezifikation der Internet Engineering Task Force (IETF). Sie legt Format, Pflichtfelder und Veröffentlichungsort fest. Wichtig zur Einordnung: RFC 9116 ist kein Schutzprogramm, und die Datei behebt selbst keine einzige Sicherheitslücke.

Der korrekte Ablageort für Webdienste lautet:

https://deine-domain.de/.well-known/security.txt

Technisch braucht es wenig: Die Datei muss per HTTPS erreichbar sein, in UTF-8 kodiert und mit dem Content-Type text/plain ausgeliefert werden. Wer eine öffentlich erreichbare Website, Webanwendung, API, App-Integration oder ein digitales Produkt betreibt, profitiert in der Regel von einem klaren Eingangskanal, besonders wenn Außenstehende eine Schwachstelle melden wollen und das Unternehmen bisher keinen sichtbaren Ansprechpartner hat.

Quelle: https://datatracker.ietf.org/doc/html/rfc9116

Warum Erreichbarkeit Vertrauen schafft

Reaktionsfähigkeit ist der erste Nutzen. Meldungen gehen direkt an Personen, die technische Sachverhalte einordnen können, statt über drei Weiterleitungen zu wandern. Das verkürzt die Zeit zwischen Hinweis und Prüfung deutlich.

Der zweite Nutzen ist Vertrauen im B2B-Geschäft. Bei Security-Fragebögen, Due Diligence oder Beschaffungsprozessen zeigt ein gepflegter Sicherheitskontakt auf der Website, dass Sicherheitsmeldungen bei euch nicht dem Zufall überlassen werden. Das ist ein kleines Signal, aber es fällt Einkäufern und Security-Teams auf.

Der dritte Nutzen wirkt nach innen: Ihr klärt früh, wer prüft, wer entscheidet und wer eskaliert. Diese Klarheit fehlt vielen Teams genau dann, wenn sie gebraucht wird.

Das BSI empfiehlt Unternehmen ausdrücklich, eine security.txt nach RFC 9116 bereitzustellen und einen dedizierten IT-Sicherheitskontakt zu veröffentlichen, weil im CVD-Prozess die richtige Ansprechperson oft schwer zu finden ist. Daraus folgt keine automatische gesetzliche Pflicht für jedes Startup. Ein Hinweis aus derselben Quelle ist besonders praxisrelevant: Nutzt ein dauerhaft betreutes Funktionspostfach statt einer personengebundenen Adresse, und stellt sicher, dass Eingang und Weiterleitung an die zuständigen Stellen tatsächlich funktionieren.

Quelle: https://www.bsi.bund.de/DE/IT-Sicherheitsvorfall/IT-Schwachstellen/FAQ_Hersteller/FAQ_Hersteller_node.html

Vom Hinweis zur Behebung: der schlanke Meldeprozess

Coordinated Vulnerability Disclosure (CVD) beschreibt ein abgestimmtes Verfahren: Finder:innen und betroffenes Unternehmen kommunizieren vertraulich, prüfen die Lücke nachvollziehbar, koordinieren eine Behebung und entscheiden erst danach gemeinsam über eine Veröffentlichung.

Die security.txt ist dabei nur der Eingangskanal. Sie ersetzt weder Validierung noch Priorisierung, weder die Entwicklung eines Fixes noch Tests, Kundenkommunikation oder eine abgestimmte Veröffentlichung.

Damit eine Meldung überhaupt bearbeitbar ist, braucht ihr Substanz. Hilfreich sind: betroffene URL oder Produktversion, verständliche Reproduktionsschritte, erwartetes und tatsächliches Verhalten, ein Hinweis auf möglichen Schaden und eine sichere Kontaktmöglichkeit für Rückfragen. Eine reine Scan-Ausgabe ohne Kontext ist keine brauchbare Meldung, das betont auch das BSI.

Für die Triage reichen vier Fragen:

1. Betrifft der Hinweis ein eigenes Produkt oder nur einen Drittanbieter?
2. Ist die Beobachtung reproduzierbar?
3. Sind Vertraulichkeit, Integrität, Verfügbarkeit oder Kundendaten potenziell betroffen?
4. Wer muss heute eingebunden werden: Tech, Geschäftsführung, Hosting, Dienstleister oder Datenschutzverantwortliche?

Quelle: https://www.bsi.bund.de/DE/IT-Sicherheitsvorfall/IT-Schwachstellen/it-schwachstellen.html

Was der CRA-Bezug ab September 2026 bedeutet

Der Cyber Resilience Act ist eine EU-Verordnung für Produkte mit digitalen Elementen und betrifft auch Startups, die Software, SaaS-Komponenten oder IoT-Geräte in Verkehr bringen. Ob euer konkretes Produkt erfasst ist, hängt vom Einzelfall ab. Dieser Artikel ersetzt keine rechtliche Prüfung.

Der Zeitplan steht in Artikel 71 der Verordnung: Sie gilt grundsätzlich ab dem 11. Dezember 2027. Artikel 14 mit bestimmten Meldepflichten gilt jedoch bereits ab dem 11. September 2026. Ab diesem Datum betreffen die vorgezogenen Pflichten insbesondere Meldungen aktiv ausgenutzter Schwachstellen und schwerwiegender Sicherheitsvorfälle bei erfassten Produkten, gemeldet über die Single Reporting Platform der ENISA. Nicht jede eingehende Sicherheitsmeldung löst automatisch eine Meldepflicht aus.

Zur sauberen Einordnung: Eine security.txt erfüllt keine CRA-Meldepflicht. Sie ist aber ein pragmatischer Baustein für eure CRA-Readiness, weil ein funktionierender externer Eingangskanal die Grundlage für Schwachstellenmanagement überhaupt erst schafft.

Quellen: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847 und https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp

Datei korrekt aufsetzen: Felder, Beispiel und Test

Eine security.txt erstellen dauert wenige Minuten. Für den Start genügen wenige korrekte Angaben, sofern der dahinterliegende Kontakt tatsächlich betreut wird.

Contact: mailto:[email protected]
Expires: 2027-06-30T23:59:59.000Z
Preferred-Languages: de, en
Policy: https://beispiel.de/security-policy

Passt das Datum vor dem Livegang an: Es muss bei Veröffentlichung weniger als ein Jahr in der Zukunft liegen.

• Contact ist Pflicht und muss eine URI sein, zum Beispiel mailto:[email protected]. Empfohlen ist ein dediziertes Funktionspostfach statt info@.
• Expires ist Pflicht und begrenzt die Gültigkeit der Angaben. RFC 9116 empfiehlt ein Ablaufdatum von weniger als einem Jahr in der Zukunft. Setzt euch direkt eine Kalendererinnerung zur Erneuerung.
• Preferred-Languages ist optional, für deutsche Teams mit internationaler Nutzerbasis aber sinnvoll: de, en.
• Policy ist optional und kann auf eine kurze Richtlinie führen: gewünschte Inhalte einer Meldung, Zusage einer Eingangsbestätigung, Umgang mit vertraulichen Informationen und die klare Aussage, dass keine Prämie zugesagt wird.
• Encryption ist optional. Verlinkt einen PGP-Schlüssel nur, wenn euer Team verschlüsselte Nachrichten empfangen, entschlüsseln und zuverlässig bearbeiten kann.
• Acknowledgments ist optional. Nutzt das Feld nur, wenn Danksagungen intern freigegeben und gepflegt werden.

Danach folgt der Test, und der wird häufig übersprungen: Ruft die URL im Browser auf, prüft HTTPS und den exakten Pfad /.well-known/security.txt, schickt eine Testmail an die hinterlegte Adresse und kontrolliert den ausgelieferten Content-Type. Nach jedem Deployment oder jeder CDN-Änderung testet ihr erneut, denn Rewrite-Regeln räumen .well-known gern versehentlich ab.

In 30 Minuten zu einem belastbaren Minimum

• Minute 0 bis 5: [email protected] anlegen und mindestens zwei Personen als Empfänger:innen oder Vertretung hinterlegen.
• Minute 5 bis 10: Eine Person für die technische Erstbewertung benennen und eine Person für Entscheidungen und Kommunikation.
• Minute 10 bis 15: Automatische Eingangsbestätigung formulieren: Eingang bestätigen, eine realistische Rückmeldefrist nennen, um reproduzierbare Schritte bitten und darauf hinweisen, sensible Daten nicht unverschlüsselt zu senden.
• Minute 15 bis 20: Geschütztes Ticket oder zugriffsbeschränkte Aufgabenliste für die Triage anlegen, mit den Status „eingegangen“, „in Prüfung“, „bestätigt“ und „behoben oder nicht betroffen“.
• Minute 20 bis 25: Eskalationsweg definieren. Wer entscheidet bei kritischen Fällen? Wer kontaktiert Hosting, Cloud-Anbieter, Entwicklungsdienstleister oder Datenschutzverantwortliche?
• Minute 25 bis 30: Datei unter dem korrekten Pfad veröffentlichen, URL testen und eine Testmeldung bis zur zuständigen Person durchspielen.

Ein Hinweis zum Schluss dieser Liste: Versprecht keine Bug-Bounty-Prämien, solange Budget, Regeln und Bearbeitungskapazität fehlen. Erst muss der Meldeweg zuverlässig laufen, alles Weitere kommt später.

Vier Gründerfälle: Worauf es jeweils ankommt

SaaS-Startup: Startet mit der Hauptdomain. In der Triage gehören Login, API, Mandantentrennung und Datenexporte ganz nach oben. Legt fest, wie sich Engineering, Produkt und Support die Zuständigkeit teilen.

D2C-Shop mit Webanwendung: Prioritäten sind Kontoübernahmen, Zahlungsumleitungen, Rabattcode-Missbrauch und Zugriff auf Kundendaten. Sicherheitsmeldungen dürfen im normalen Kundenservice nicht untergehen, deshalb braucht es einen separaten Kanal.

Shopify-App: Bietet einen unabhängigen Meldeweg für eure eigene App-Logik, Integrationen, Tokens und externe Infrastruktur. Store-Bewertungen oder gewöhnliche Support-Tickets sind kein geeigneter Sicherheitskanal.

Agentur mit Kundenportal: Trennt euer eigenes Portal organisatorisch von den Systemen eurer Kund:innen. Klärt vorab, wer technische Partner einbindet und wer Kund:innen informiert, falls eine bestätigte Lücke deren Umgebung betrifft.

Übergreifend gilt: Das Setup muss zum tatsächlichen Produkt, den verarbeiteten Daten und den realen Verantwortlichkeiten passen, nicht zur Teamgröße auf dem Papier.

Die Fehler, die den Nutzen wieder zunichtemachen

• info@ oder ein Kontaktformular statt dediziertem Sicherheitskanal → security@ als betreutes Funktionspostfach nutzen.
• Datei nur unter /security.txt veröffentlichen → den kanonischen Pfad /.well-known/security.txt verwenden.
• Abgelaufenes Expires → wiederkehrenden Termin zur Erneuerung einrichten.
• PGP-Schlüssel veröffentlichen, aber nicht bedienen können → Feld weglassen.
• Policy oder Eingangsbestätigung versprechen, aber nicht reagieren → nur realistische Zusagen veröffentlichen.
• Die einzige zuständige Person ist im Urlaub → Vertretung benennen und Zugriff testen.

FAQ

Was ist eine security.txt?

Eine security.txt ist eine einfache Textdatei nach RFC 9116, die unter /.well-known/security.txt veröffentlicht wird und Sicherheitsforschenden zeigt, wie sie eine Schwachstelle bei einem Unternehmen melden können.

Ist eine security.txt Pflicht?

Nein, RFC 9116 ist ein freiwilliger Standard. Das BSI empfiehlt Unternehmen jedoch ausdrücklich, eine security.txt bereitzustellen. Ob aus dem Cyber Resilience Act weitergehende Pflichten für euer Produkt folgen, muss im Einzelfall geprüft werden.

Welche Felder braucht eine security.txt mindestens?

Pflicht sind Contact und Expires. Alles andere, etwa Policy, Preferred-Languages, Encryption oder Acknowledgments, ist optional.

Was passiert, wenn wir eine Meldung erhalten?

Bestätigt den Eingang, prüft die Reproduzierbarkeit, bewertet die Betroffenheit von Daten und Systemen und entscheidet über Behebung und Eskalation. Sind personenbezogene Daten betroffen, greift eure DSGVO-Meldekette, bei Risiko in der Regel innerhalb von 72 Stunden nach Kenntnis.

Fazit

Eine security.txt ist kein kompliziertes Security-Projekt, sondern ein sichtbarer Startpunkt für professionelles Schwachstellenmanagement. Vier Schritte reichen für diese Woche: Funktionspostfach einrichten, Zuständigkeit plus Vertretung bestimmen, Datei veröffentlichen, Testmeldung und Ablaufdatum prüfen.

Pro-Tipp: Setzt euch einen Quartalstermin, an dem ihr Kontakt, Expires, Zuständigkeiten und die automatische Antwort kontrolliert. Bei bestätigten Vorfällen mit möglichen personenbezogenen Daten zieht ihr die Datenschutz-Eskalation früh hinzu, nicht erst am Ende.

Vertrauen entsteht nicht durch eine perfekte Security-Seite, sondern dadurch, dass ihr bei einem ernst gemeinten Hinweis klar und verlässlich reagiert.

Transparenzhinweis: Dieser Beitrag wurde unter Zuhilfenahme künstlicher Intelligenz erstellt und vor der Veröffentlichung redaktionell geprüft. Alle Zahlen und Angaben wurden gegen die im Text verlinkten Primärquellen abgeglichen.