Sicherheitslücken werden oft von Außenstehenden entdeckt: von Forschenden, Kundinnen und Kunden oder Fachleuten, die zufällig auf einen Fehler stoßen. Ohne geregelten Weg landen solche Funde im Spam-Ordner, werden ignoriert oder sofort öffentlich gemacht, bevor ein Update existiert. CVD schafft einen verlässlichen Ablauf, der Finder, Hersteller und Nutzende gleichermaßen schützt. Der früher verbreitete Begriff Responsible Disclosure meint im Wesentlichen dasselbe.
Wie läuft eine koordinierte Offenlegung ab?
- Meldung: Die findende Person meldet die Lücke vertraulich an die veröffentlichte Kontaktstelle des Herstellers oder Betreibers.
- Bestätigung und Prüfung: Der Empfänger bestätigt den Eingang, prüft den Befund und hält die meldende Person auf dem Laufenden.
- Behebung: Der Hersteller entwickelt ein Update oder eine Ausweichmaßnahme.
- Veröffentlichung: Beide Seiten veröffentlichen abgestimmt, meist mit CVE-Kennung und Sicherheitshinweis, und nennen auf Wunsch die findende Person.
Die internationalen Normen ISO/IEC 29147 und ISO/IEC 30111 beschreiben diesen Weg: 29147 die Offenlegung nach außen, 30111 die interne Bearbeitung gemeldeter Schwachstellen.
CVD in der EU und in Österreich
Die NIS2-Richtlinie verpflichtet jeden Mitgliedstaat in Art. 12, ein CSIRT als Koordinator für die koordinierte Offenlegung zu benennen. Es tritt als vertrauenswürdiger Vermittler auf, handelt Offenlegungsfristen aus und muss auf Wunsch anonyme Meldungen ermöglichen. Zugleich betreibt die ENISA eine europäische Schwachstellendatenbank, die EUVD. In Österreich nimmt CERT.at Schwachstellenmeldungen entgegen und vermittelt bei Bedarf zwischen meldender Person und Hersteller; die koordinierte Offenlegung zählt laut CERT.at zu den Aufgaben des nationalen CSIRT nach dem NISG 2026. Hersteller vernetzter Produkte brauchen nach dem Cyber Resilience Act zudem eine eigene Strategie zur koordinierten Offenlegung.
Praxis für KMU und Gemeinden
Auch wer keine Software herstellt, betreibt Websites, Portale oder Online-Formulare, in denen jemand eine Lücke finden kann. Sinnvoll sind:
- Eine Meldeadresse, die gelesen wird, etwa ein eigenes Postfach für Sicherheitsmeldungen.
- Eine security.txt-Datei unter
/.well-known/security.txt, wie sie RFC 9116 beschreibt. Pflichtangaben sind ein Kontakt und ein Ablaufdatum. - Eine kurze Richtlinie, die erklärt, wie gemeldet werden soll, wie schnell Sie antworten und dass gutgläubige Meldungen willkommen sind.
- Einen internen Ablauf, wer eine Meldung bewertet, wer den Dienstleister einbindet und wer entscheidet, ob ein Sicherheitsvorfall vorliegt.
Risiken und typische Fehler
- Meldungen ins Leere: Fehlt ein Kontakt, wenden sich Finder an die Öffentlichkeit oder geben auf.
- Drohungen statt Dank: Wer auf eine gutgläubige Meldung mit rechtlichen Schritten reagiert, erfährt von der nächsten Lücke womöglich zuletzt.
- Kein Ende: Ohne Frist und Rückmeldung bleibt eine Lücke unnötig lange offen.
Bezug zu TOMORIS
Mit dem kostenlosen security.txt-Check der TOMORIS Toolbox prüfen Sie Ihre Datei nach RFC 9116 und erstellen eine neue direkt im Browser. Gemeldete Schwachstellen nach Wirkung und Dringlichkeit zu bearbeiten, unterstützt EXPERTS Cyber Security.