Wenn Forscher an die Öffentlichkeit gehen: Was eine verpatzte Offenlegung kostet

Sicherheitsforscher entscheiden sich für Full Disclosure statt Responsible Disclosure, wenn sie das Vertrauen in den Prozess des Anbieters verlieren – nicht, weil sie Schaden anrichten wollen. Der Auslöser ist fast immer operativer Natur: eine Meldung, die wochenlang unbeantwortet liegen blieb, ein Fix, der klammheimlich ohne Nennung ausgeliefert wurde, oder ein Schweregrad, der leise auf „keine Auswirkung“ heruntergestuft wurde. Sobald ein Forscher zu dem Schluss kommt, dass die Abstimmung mit Ihnen reine Zeitverschwendung ist, veröffentlicht er. Das Problem war nie der Bug. Das Problem war Ihr Offenlegungsprozess.

Das ist das Day-2-Problem, das die meisten Teams ignorieren. Ein Vulnerability-Disclosure-Programm aufzusetzen ist der einfache Teil: eine security.txt-Datei, eine Scope-Definition, ein Postfach. Es so zu betreiben, dass echte Forscher weiterhin an Sie melden statt über Sie, ist der schwierige Teil. Und 2026 ist überdeutlich geworden, was es kostet, das falsch zu machen.

Die github.dev-Offenlegung, die Microsoft komplett übersprang

Am 2. Juni 2026 veröffentlichte der Sicherheitsforscher Ammar Askar einen vollständigen Proof-of-Concept für einen One-Click-Diebstahl von GitHub-OAuth-Tokens in github.dev, dem browserbasierten VS-Code-Editor. Der Exploit verkettete das Bubbling von keydown-Events in VS Codes Webview, um still und heimlich eine lokale Erweiterung zu installieren und das Token des Nutzers abzugreifen. Das gestohlene Token war nicht auf ein einzelnes Repository beschränkt; es gewährte Zugriff auf jedes Repo, das das Opfer erreichen konnte, einschließlich privater (Quellen: BleepingComputer, CSO Online).

Der technische Schweregrad war hoch. Doch der Teil, den jeder Programmverantwortliche studieren sollte, ist die Offenlegung selbst.

Askar gab GitHub nur eine Stunde Vorlaufzeit, bevor er an die Öffentlichkeit ging, und umging Microsofts Security Response Center (MSRC) ganz bewusst komplett. Seine erklärte Begründung: Ein früherer VS-Code-Bug, den er gemeldet hatte, war still behoben worden – ohne Nennung und mit dem Vermerk, er habe keine sicherheitsrelevante Auswirkung. Er kam zu dem Schluss, dass der Prozess seine Arbeit nicht fair behandeln würde, und stieg deshalb aus. Aus einem kooperativen Forscher wurde ein Zero-Day-Veröffentlicher – nur wegen der Art, wie eine frühere Meldung behandelt worden war.

Das ist die ganze Lektion in einem Satz. Das Versagen bei der Offenlegung verwandelte einen Verbündeten in einen Gegner, und keine noch so große technische Brillanz aufseiten Microsofts konnte das im Nachhinein ungeschehen machen. Microsoft lieferte einen Notbehelf-Fix aus (eine Bestätigungsabfrage für Web-Notebooks und eine Sperre für das Überspringen der Publisher-Vertrauensprüfung), aber das Vertrauen war bereits dahin und der ungepatchte Exploit bereits öffentlich.

Responsible Disclosure vs. Full Disclosure – und warum sich die Grenze verschiebt

Responsible Disclosure (auch koordinierte Schwachstellenoffenlegung genannt) bedeutet, dass ein Forscher privat meldet und dem Anbieter Zeit gibt, das Problem zu beheben, bevor irgendein öffentliches Detail erscheint. Full Disclosure bedeutet, dass der Forscher die Schwachstelle veröffentlicht – oft mit funktionierendem Exploit –, bevor ein Patch existiert. Die Grenze zwischen beiden ist kein Charakterzug. Sie hängt davon ab, ob der Forscher glaubt, dass der Anbieter seinen Teil der Abmachung einhält.

Die Branche kennt etablierte Referenzfristen dafür, was „faire Zeit zum Beheben“ bedeutet:

• Google Project Zero arbeitet mit einer Offenlegungsfrist von 90 Tagen, die bei aktiv ausgenutzten Bugs auf 7 Tage sinkt.
• CERT/CC legt 45 Tage nach der ersten Meldung offen – unabhängig davon, ob ein Patch verfügbar ist.

(Quellen: CERT/CC Guide to Coordinated Vulnerability Disclosure, Wikipedia: Coordinated vulnerability disclosure.)

Diese Fristen existieren, weil Forscher einen neutralen Maßstab brauchten, auf den sie verweisen konnten, wenn Anbieter unbegrenzt auf Zeit spielten. Sie sind der Vergleichswert, an dem ein frustrierter Forscher Sie misst.

Was Responsible Disclosure einem Anbieter tatsächlich abverlangt

Responsible Disclosure ist ein Geschäft auf Gegenseitigkeit. Der Forscher willigt ein zu warten und still zu bleiben. Im Gegenzug verpflichtet sich der Anbieter, die Meldung zügig zu bestätigen, ehrlich über Schweregrad und Zeitplan zu kommunizieren, das Problem zu beheben und die Leistung zu würdigen. Die meisten veröffentlichten Offenlegungsrichtlinien fassen es genau so: Kooperation gegen eine Behandlung nach Treu und Glauben. Wenn die eine Seite ihr Versprechen hält und die andere nicht, bricht das Geschäft zusammen.

Wann Forscher entscheiden, dass es sich nicht lohnt

Forscher werden nicht fürs Warten bezahlt. Viele machen diese Arbeit in ihrer Freizeit, und ihr Ruf gründet auf öffentlicher Anerkennung. Wenn ein Anbieter eine Meldung als lästige Pflicht behandelt, sie ignoriert oder die Nennung streicht, die den unbezahlten Aufwand erst rechtfertigt, ist der rationale Schritt, die Abstimmung einzustellen. Die Veröffentlichung stellt das eine wieder her, das der kaputte Prozess weggenommen hat: einen sichtbaren Beweis der eigenen Arbeit.

Warum Forscher an die Öffentlichkeit gehen: die fünf Vertrauenskiller

Über den github.dev-Vorfall und die breitere Forschung zu Offenlegungsprogrammen hinweg tauchen immer wieder dieselben fünf operativen Versäumnisse auf. Keines davon ist technischer Natur. Jedes ist eine Prozessentscheidung, die Sie steuern.

1. Langsame oder ausbleibende Eingangsbestätigung. Eine Meldung, die unbeantwortet liegt, signalisiert dem Forscher, dass seine Zeit nicht zählt.
2. Ungerechtfertigte Herabstufungen des Schweregrads. Einen echten Bug als „keine Auswirkung“ oder „geringer Schweregrad“ zu kennzeichnen, wirkt wie Treuwidrigkeit – besonders, wenn der Forscher die Begründung nicht nachvollziehen kann.
3. Stille Fixes ohne Nennung. Den Patch auszuliefern, aber den Namen des Forschers zu tilgen, raubt ihm jeden Anreiz, privat zu melden.
4. Verspätete oder ausbleibende Zahlung. Wenn eine Prämie zugesagt ist, zermürben Verzögerungen und Streit das Vertrauen genauso schnell wie eine Herabstufung.
5. Kommunikations-Funkstille. Während des Fix-Zeitraums abzutauchen, lässt den Forscher rätseln, ob überhaupt etwas passiert.

(Quellen: OWASP Vulnerability Disclosure Cheat Sheet, HelpNetSecurity-Interview mit Roy Davis, Zoom.)

Langsame oder ausbleibende Eingangsbestätigung

Die Eingangsbestätigung ist das günstigste Vertrauenssignal, das Sie haben – und das am leichtesten zu verspielende. Ein Forscher, der Ihr Postfach anschreibt und zwei Wochen lang nichts hört, hat keine Möglichkeit zu erkennen, ob Sie am Problem arbeiten oder es ignorieren. Der ehrliche Schritt ist eine schnelle Bestätigung, dass ein Mensch die Meldung erhalten hat und sich darum kümmert. Behördenprogramme behandeln das als Grundvoraussetzung: Das US-Handelsministerium und das Innenministerium verpflichten sich beide, Meldungen innerhalb von 3 Werktagen zu bestätigen, und Silicon Labs sagt dasselbe zu. Wenn Bundesbehörden eine 3-Tage-Marke schaffen, schafft das auch ein Start-up.

Ungerechtfertigte Herabstufungen des Schweregrads

Streit über den Schweregrad ist der zweithäufigste Zündfunke – und er ist vermeidbar. Das Problem ist nicht die Bewertung an sich; es ist, dass die Bewertung als Black-Box-Urteil eintrifft, das der Forscher weder einsehen noch anfechten kann. Eine Herabstufung, die wie ein Trick wirkt, um eine Auszahlung zu vermeiden oder Peinlichkeit kleinzureden, liest sich als Treuwidrigkeit – selbst wenn sie es nicht ist. Die Lösung: den Schweregrad auf ein transparentes, etabliertes Rahmenwerk (CVSS) stützen und Ihren Rechenweg offenlegen, damit der Forscher dieselben Eingangsdaten sieht wie Sie.

Stille Fixes ohne Nennung

Das ist genau das Versagen, das die github.dev-Offenlegung auslöste. Der Forscher meldete einen Bug, der Anbieter patchte ihn klammheimlich, und der Name des Forschers tauchte nirgends auf. Für jemanden, der seine Laufbahn auf öffentlicher Anerkennung aufbaut, ist ein stiller Fix schlimmer als eine Ablehnung. Er nimmt die Arbeit und die Würdigung. Eine Nennung – ob als CVE-Acknowledgment oder Hall-of-Fame-Eintrag – kostet Sie nichts und ist der mit Abstand verlässlichste Weg, einen Forscher dazu zu bewegen, beim nächsten Mal wieder an Sie zu melden.

Verspätete oder ausbleibende Zahlung

Wenn Sie ein bezahltes Programm betreiben, ist die Prämie ein Versprechen. Forscher nennen durchgängig unzuverlässige oder verspätete Zahlungen als Grund, warum sie Programmen den Rücken kehren. Ein vorhersehbarer, nachvollziehbarer Auszahlungsprozess zählt mehr als eine hohe Schlagzeilen-Prämie. Unklarheit darüber, wann und ob gezahlt wird, richtet mehr Schaden an als eine bescheidene, aber zuverlässige Prämie.

Kommunikations-Funkstille

Selbst wenn Sie an der Sache arbeiten, liest sich Schweigen als Vernachlässigung. Der OWASP-Leitfaden ist eindeutig: Schicken Sie regelmäßige Status-Updates auch dann, wenn es keinen Fortschritt zu melden gibt, denn das Update selbst ist das Signal, dass die Meldung nicht vergessen wurde. Ein einzeiliges „arbeiten noch dran, hier der aktuelle Stand“ alle paar Wochen ist oft der Unterschied zwischen einem Forscher, der wartet, und einem, der veröffentlicht.

Kein Einzelfall: die Welle öffentlicher Zero-Day-Drops 2026

Der github.dev-Vorfall war kein Ausreißer. Im selben Zeitfenster von April bis Juni 2026 ließ ein Forscher unter dem Namen „Chaotic Eclipse“ öffentlich sechs ungepatchte Windows-Zero-Days fallen, von denen drei bereits aktiv in freier Wildbahn ausgenutzt wurden. Die genannten Gründe waren eine vertraute Liste: ignorierte Meldungen, ein gelöschtes Melde-Konto, null Vergütung und das Gefühl, durch die Formulierung eines CVE-Advisorys über die eigene Arbeit verunglimpft worden zu sein (Quellen: SecurityAffairs, The Hacker News).

Microsoft verurteilte die „unkoordinierten“ Offenlegungen öffentlich als unnötiges Risiko für Kunden und reichte dann den Olivenzweig, nachdem die Gegenreaktion einsetzte. Der Ablauf ist lehrreich: Den Forscher zu beschuldigen reparierte den Prozess nicht und verhinderte auch die nächste Offenlegung nicht. Wenn dasselbe Versagensmuster innerhalb eines einzigen Quartals mehrere öffentliche Drops gegen eine der bestausgestatteten Sicherheitsorganisationen der Welt hervorbringt, ist es kein Forscher-Problem mehr, sondern ein Problem des Programm-Designs.

Was ein vertrauenswürdiges VDP anders macht

Ein vertrauenswürdiges Programm verwandelt jeden einzelnen der fünf Vertrauenskiller in eine Zusage, auf die sich der Forscher verlassen kann. Die Mechanik ist nicht exotisch; sie ist operative Disziplin, konsequent angewandt.

Der rote Faden durch all das ist der Respekt vor der Zeit und der Arbeit des Forschers. Wer das richtig macht, hält die Offenlegungsuhr privat. Wer es falsch macht, treibt den Forscher dazu, die 90 Tage von Project Zero oder die 45 von CERT/CC als den Maßstab heranzuziehen, an dem Sie gescheitert sind.

Wie Kit das Vertrauen von Forschern operationalisiert

Kits Sicherheitsmodul (Csirt) wurde rund um genau diese Versagensmuster gebaut. Sich selbst über das Betriebsmodell weiterzubilden zählt mehr als jedes Werkzeug, aber der Wert eines Werkzeugs liegt darin, dass es das richtige Verhalten zum Standard macht – statt zu etwas, an das Sie unter Druck denken müssen. Jeder Vertrauenskiller entspricht so einer konkreten Einstellung.

Um klarzustellen, was Kit beanspruchen kann und was nicht: Kit hat mit dem github.dev-Bug nichts zu tun, und kein Werkzeug hätte ihn „verhindert“. Das war Microsofts Produkt. Was Kit behebt, ist das Versagen im Offenlegungsprozess, das den Forscher zur Full Disclosure trieb. Wenn Ihr Unternehmen eine Meldung wie diese erhalten hätte, sind es Kits Eingangsbestätigungs-SLA, der transparente CVSS-Schweregrad, die standardmäßige Nennung und die vorhersehbare Auszahlung, die den Forscher dazu bringen, sich weiter mit Ihnen abzustimmen, statt einen ungepatchten Exploit zu veröffentlichen.

Ihr Offenlegungsprozess ist Ihre Sicherheitslage

Die Erkenntnis aus den öffentlichen Zero-Day-Drops von 2026 ist unbequem, aber einfach: Forscher gehen nicht an die Öffentlichkeit, weil sie feindselig sind. Sie gehen an die Öffentlichkeit, weil der Prozess ihre Zeit und ihre Arbeit missachtet hat. Langsame Eingangsbestätigung, undurchsichtige Herabstufungen des Schweregrads, stille Fixes, verspätete Zahlung und Kommunikations-Funkstille sind keine kleinen administrativen Schnitzer. Sie sind die direkte Ursache dafür, dass ungepatchte Exploits mit Ihrem Namen versehen auf Hacker News landen.

Jedes dieser Versäumnisse ist eine Entscheidung, die Sie steuern, und jedes entspricht einer Einstellung, die Sie heute beheben können. Wenn Sie bereits ein VDP haben, ist der nächste Schritt nicht mehr Richtlinie, sondern der Day-2-Betrieb, der Forscher auf Ihrer Seite hält. Starten Sie mit dem Setup-Leitfaden, falls Sie noch nicht so weit sind, und verwandeln Sie Ihre Annahme dann in einen SLA-gestützten, mit Nennung versehenen, bezahlten Workflow. Wenn Sie bereit sind, das Ganze richtig zu betreiben, können Sie eine kostenlose Testphase starten und es an einem Nachmittag betriebsbereit haben.