Wir betreiben Sicherheitsforschung und melden regelmäßig Schwachstellen an Hersteller und Betreiber. Heute wollen wir aber nicht über einzelne Funde sprechen, sondern den Blick auf das richten, was nach dem Fund passiert: der verantwortungsvolle Umgang mit einer entdeckten Lücke.
Diese zu melden ist weniger eine starre Prozedur als eine professionelle Beziehung auf Augenhöhe. Sie funktioniert, wenn Forschende und Firmen sauber miteinander kommunizieren. Und sie scheitert, wenn eine Seite das aufkündigt. Dieser Beitrag zeigt, welche Offenlegungs-Modelle es gibt, welches wir wählen und warum.
Wir zeigen, wie aus unserer Sicht beide Seiten kommunizieren sollten und woran man sich auf dem Weg von der Lücke zur Meldung orientieren kann.
Sobald eine Schwachstelle gefunden ist, stellt sich die zentrale Frage: Wer erfährt was, und wann? Daraus ergeben sich grob drei Wege.
Coordinated Disclosure
Full DisclosureFür uns ist koordinierte Offenlegung der Default. Unser Ziel ist es, Missstände aufzuzeigen und abzustellen, nicht zur Unsicherheit beizutragen. Solange eine Lücke öffentlich, aber ungepatcht ist, hilft das vor allem denjenigen, gegen die wir arbeiten.
Verantwortungsvolle Offenlegung beginnt nicht erst bei der Meldung, sondern schon bei der Wahl des Forschungsziels. Eine sinnvolle Frage vorab lautet: Wer würde eine Meldung empfangen, und könnte der Hersteller oder Betreiber überhaupt etwas damit anfangen?
Ein Whitelabel-Gerät eines Herstellers ohne Webseite, ohne Kontakt und ohne Update-Mechanismus lässt niemanden zurück, den man informieren könnte, und keinen Weg zu einem Fix. Daraus ergibt sich eine unbequeme Frage: Wenn ein System nicht einmal die Möglichkeit bietet, Updates auszuliefern, und niemand erreichbar ist, der die Lücke schließen könnte, sollte man so etwas dann überhaupt beforschen? Eine pauschale Antwort gibt es nicht. Hier muss der Nutzen einer Warnung vor einem unsicheren Produkt gegen den zu erwartenden Schaden durch das Veröffentlichen einer Sicherheitslücke abgewogen werden. Das ist eine Frage, die an den Anfang der Forschung gehört, nicht ans Ende, wenn eine Lücke bereits gefunden wurde.
Ist die Lücke gefunden, folgt ein Ablauf, der sich in fünf Schritte gliedern lässt. Jeder davon hat seine eigenen Fallstricke.
Eine Meldung ist nur dann etwas wert, wenn der Hersteller das Problem nachvollziehen kann. Der Nachweis muss also belastbar sein. Gleichzeitig gilt: so viel wie nötig, kein Stück mehr. Erlaubt eine Lücke etwa den Zugriff auf die Daten eines anderen Nutzers, legt man sich zwei eigene Testkonten an und greift mit dem einen auf die Daten des anderen zu. Das beweist die Lücke vollständig, ohne dass je echte Nutzerdaten berührt werden. Genau an dieser Linie trennt sich seriöse Forschung von einem Vorgehen, das vor Gericht bestraft wird.
Bevor man melden kann, braucht man einen Empfänger. Der beste Fall ist eine security.txt, eine standardisierte Datei nach RFC 9116, die im Pfad /.well-known/ liegt und den Sicherheitskontakt sowie oft einen passenden Schlüssel benennt. Existiert sie nicht, helfen ein ausgewiesener Security-Kontakt, ein Vulnerability-Disclosure-Programm oder eine Bug-Bounty-Plattform. Findet sich gar nichts davon, bleibt nur der allgemeine Kontaktweg.
Eine gute Meldung ist eine, mit der die Gegenseite sofort arbeiten kann, ohne mehrfach nachfragen zu müssen. Dazu gehören eine klare, nachvollziehbare Reproduktion, die betroffenen Versionen oder Konfigurationen und eine realistische Einschätzung des Impacts. Sensible Details gehören über einen verschlüsselten Kanal übermittelt, etwa mit dem Schlüssel aus der security.txt. Genauso wichtig wie der Inhalt ist der Ton: sachlich, klar und auf Augenhöhe.
Eine Frist, also die Zeitspanne zwischen Meldung und Veröffentlichung, hält zwei berechtigte Interessen in der Waage: Der Hersteller braucht Zeit für einen sauberen Fix, die Nutzer ein absehbares Ende ihrer Gefährdung. Entscheidend ist, dass die Frist vorab kommuniziert wird und beide Seiten sie kennen.
Am Ende steht ein gemeinsam abgestimmter Veröffentlichungstermin. Eine CVE-Nummer aus dem CVE-Programm macht die Lücke eindeutig referenzierbar, sodass Verteidiger weltweit sie zuordnen und ihre eigenen Systeme prüfen können. Geschlossen ist der Kreis aber erst mit dem Fix.
ISO/IEC 29147 und 30111 beschreiben diesen Austausch aus Sicht beider Seiten und sind ein guter Orientierungsrahmen.Bleibt eine Antwort aus, ist der erste Reflex oft Frust. Der ist verständlich, aber verfrüht. Schweigen heißt nicht Ignoranz. Sicherheitspostfächer sind häufig überlaufen und gerade in letzter Zeit landet dort viel automatisierter AI-Spam mit halluzinierten Sicherheitslücken, der echte Meldungen untergehen lässt. Vielleicht ist die zuständige Person im Urlaub und es achtet vorübergehend niemand auf das Postfach. Bevor man von Verweigerung ausgeht, lohnt sich Geduld.
Konkret heißt das: mehrfach und in Abständen freundlich nachfassen. Weitere Kontaktwege ausprobieren, etwa eine zweite Adresse, das allgemeine Kontaktformular oder einen namentlich benannten Ansprechpartner. Auf jeden Fall sollte schon in der ersten Meldung um eine kurze Empfangsbestätigung gebeten werden, um sicherzugehen, dass die Meldung gesehen wurde und bearbeitet wird.
Wenn auf mehreren Kanälen über längere Zeit keinerlei Rückmeldung kommt, ist die Sorgfaltspflicht der Forschenden aus unserer Sicht erfüllt. Dann wird zunächst die vereinbarte Frist abgewartet. Verstreicht auch sie ohne Reaktion, folgt die nächste Stufe: ein Vermittler. Dies ist der absolute Ausnahmefall.
Erst wenn auch mit Hilfe eines Vermittlers keine Gesprächsbereitschaft entsteht und die Nutzer dauerhaft gefährdet bleiben, wird die volle Offenlegung zum letzten Mittel. Sie steht am Ende eines langen, dokumentierten Weges, nicht an seinem Anfang.
Die wichtigsten Punkte nochmal zusammengefasst.
Das sollten Forschende tun
Das sollten Forschende vermeidenEine Eskalation entsteht selten aus reiner Bösartigkeit. Häufiger kippt eine Meldung, wenn Forschende ethische oder rechtliche Grenzen überschreiten und gleichzeitig die Kommunikation auf einer der beiden Seiten schlecht läuft. Im schlimmsten Fall mündet das in eine rechtliche Auseinandersetzung, die niemandem hilft. Sie kostet beide Seiten Zeit, Geld und Vertrauen, und ausgerechnet in diesen Fällen bleibt die eigentliche Lücke am längsten ungelöst.
Professionelles Verhalten ist deshalb keine Einbahnstraße. Es gehört auf beide Seiten des Tisches.
Wechseln wir die Perspektive. Wie sollte eine Firma reagieren, die eine solche Meldung erhält?
Die wichtigste Erkenntnis: Eine Meldung ist kein Angriff, sondern kostenlose Qualitätssicherung. Manche Forschende haben gezielt gesucht, andere sind eher zufällig über das Problem gestolpert. In beiden Fällen hat sie niemand gezwungen, die Sicherheitslücke zu melden. Das sollte aus unserer Sicht honoriert werden.
Eine Vulnerability Disclosure Policy veröffentlichen, die sagt, welche Forschung erlaubt ist und wie gemeldet werden soll.
Eine security.txt bereitstellen und einen verschlüsselten Kanal für sensible Details anbieten.
Meldungen zügig bestätigen, triagieren und eine realistische Frist gemeinsam vereinbaren.
security.txt bereitstellen, damit Forschende den richtigen Kontakt sofort findenResponsible Disclosure ist im Kern keine Checkliste, sondern eine professionelle Beziehung auf Augenhöhe. Fristen, security.txt und Eskalationswege sind nur die Werkzeuge, die diese Beziehung strukturieren. Funktioniert die Kommunikation, profitieren beide Seiten und am Ende die Nutzer.
Du forschst selbst und suchst Partner für eine koordinierte Offenlegung? Oder dir ist etwas aufgefallen, das aus gesellschaftlicher Relevanz einmal beforscht werden sollte?
Quellen