Safe Harbor oder Klage? Die VDP-Klausel, die Sie schützt

Safe Harbor in einer Vulnerability Disclosure Policy ist eine ausdrückliche Zusage, dass Ihr Unternehmen keine rechtlichen Schritte gegen Forscher einleitet, die Schwachstellen in gutem Glauben melden. Sie verwandelt vage Erwartungen an „verantwortungsvolles” Verhalten in einen schriftlichen Vertrag: Bleiben Sie im Geltungsbereich, exfiltrieren Sie keine Daten, stören Sie den Dienst nicht, melden Sie über den offiziellen Kanal – und schon sind Sie zum Testen berechtigt. Ohne sie lassen jahrzehntealte Anti-Hacking-Gesetze selbst gewissenhafte Melder im Regen stehen, und der Forscher, der Ihren Bug gefunden hat, hat allen Grund zu schweigen oder ihn zu verkaufen.

Im Mai 2026 führte Microsoft der gesamten Branche vor Augen, was passiert, wenn diese Klausel fehlt oder ignoriert wird. Die Geschichte ist eine fast lehrbuchreife Fallstudie dafür, wie eine mehrdeutige Policy plus eine reflexhafte rechtliche Drohung das Vertrauen von Forschern über Nacht zerstört. Die gute Nachricht für Gründer: Das Versagen war organisatorisch, nicht technisch – ein Startup kann es also mit der richtigen Policy und dem richtigen Prozess vom ersten Tag an vermeiden.

Was Microsoft gerade getan (und schnell zurückgenommen) hat

Microsoft drohte einem Sicherheitsforscher mit strafrechtlichen Ermittlungen, sah sich tagelangem öffentlichem Gegenwind aus der Infosec-Community ausgesetzt und ruderte dann öffentlich zurück. Der gesamte Bogen spannte sich über rund einen Monat.

Ab Anfang April 2026 veröffentlichte ein unter dem Pseudonym „Nightmare-Eclipse” auftretender Forscher öffentlich Proof-of-Concept-Exploit-Code für eine Reihe von Windows-Zero-Days, ohne sich vorher mit Microsoft abzustimmen. Die Zahl war ein bewegliches Ziel: rund sechs Bugs bis Ende Mai (mit Namen wie BlueHammer, RedSun, UnDefend und YellowKey, einem kritischen BitLocker-Bypass, der als CVE-2026-45585 geführt wird), und es wurden mehr, je länger sich die Fehde bis in den Juni zog. Microsoft veröffentlichte einen Blogbeitrag, der unkoordinierte Offenlegung als „niemals zu rechtfertigen” bezeichnete. Seine Digital Crimes Unit erklärte, sie werde „weiterhin Fälle gegen diese Akteure und gegen jene verfolgen, die ihre kriminellen Aktivitäten ermöglichen, und sich bei Bedarf mit Strafverfolgungsbehörden auf der ganzen Welt abstimmen”.

Die Community las das als Drohung mit strafrechtlicher Verfolgung gegen einen Forscher. Der Gegenwind kam sofort und heftig. Um den 1. bis 2. Juni 2026 ruderte Microsoft zurück und erklärte, man habe „nicht die Absicht, gegen Personen vorzugehen, die Sicherheitsforschung betreiben oder veröffentlichen” – mit dem Vorbehalt, dass man mit Strafverfolgungsbehörden zusammenarbeite, wenn jemand „gegen das Gesetz verstößt und böswillig handelt und damit unseren Kunden realen Schaden zufügt”.

Ein Detail ist aufschlussreicher als die Kehrtwende selbst. Während der Krise tauschte Microsoft in seiner Kommunikation klammheimlich den Begriff „responsible disclosure” gegen „Coordinated Vulnerability Disclosure” aus. Diese Wortänderung, auf die wir noch zurückkommen, war ein verräterisches Zeichen.

Warum dies das Vertrauensversagen Nummer eins bei der Offenlegung ist

Der Schaden hier entstand nicht durch einen ausgeklügelten Exploit. Er entstand durch Mehrdeutigkeit. Wenn eine Policy nicht schriftlich festhält, dass gutgläubige Forscher sicher sind, wird jede Meldung zum Glücksspiel – und die Laune des Anbieters an einem beliebigen Tag entscheidet, ob ein hilfsbereiter Fremder ein Partner oder ein Angeklagter ist.

Der Widerspruch machte es schlimmer. Kevin Beaumont, Sicherheitsforscher und früherer Microsoft-Mitarbeiter, nannte die Episode „ein selbst verschuldetes Desaster” und wies darauf hin, dass Microsoft zuvor SandboxEscaper eingestellt hatte – eine Forscherin, die Proof-of-Concept-Code für einen Windows-Zero-Day veröffentlicht hatte, also genau jenes Verhalten, das der Blogbeitrag des Unternehmens nun als kriminell darstellte. Eine inkonsistente Durchsetzung ist nicht von gar keiner Policy zu unterscheiden. Wenn Forscher nicht vorhersagen können, wie Sie reagieren werden, gehen sie vom Schlimmsten aus.

Katie Moussouris, die Microsofts ursprüngliches Bug-Bounty-Programm konzipierte und heute Luta Security leitet, warnte vor „einem Abschreckungseffekt, durch den sich weniger Menschen melden, um Bugs zu berichten, was uns alle weniger sicher macht”. Das ist die zentrale Lektion. Eine Drohung wegen einer Offenlegung bestraft nicht nur einen Forscher. Sie bringt den nächsten hundert bei, lieber zu schweigen.

Was „Safe Harbor” wirklich bedeutet

Safe Harbor ist die Klausel, die das Glücksspiel beseitigt. Es ist ein in Ihrer Policy veröffentlichtes schriftliches Versprechen, dass Forscher, die in gutem Glauben handeln, nicht verklagt oder zur Strafverfolgung gemeldet werden.

Um sich für den Schutz zu qualifizieren, müssen Forscher in der Regel eine kurze Liste von Bedingungen erfüllen:

1. In gutem Glauben handeln, mit der Absicht, die Sicherheit zu verbessern, nicht zu erpressen oder Schaden anzurichten.
2. Innerhalb des definierten Geltungsbereichs bleiben, also nur die Assets testen, die Sie dafür freigegeben haben.
3. Datenschutzverletzungen und Datenexfiltration vermeiden und nur auf das Minimum zugreifen, das zum Nachweis eines Bugs nötig ist.
4. Dienstunterbrechungen vermeiden, also keine Denial-of-Service- oder zerstörerischen Tests.
5. Über den offiziellen Kanal melden und eine angemessene Frist zur Behebung einräumen, bevor öffentlich offengelegt wird.

Das ist keine juristische Außenseitertheorie. Das Safe-Harbor-Framework von disclose.io, ein Open-Source-Standard, wurde 2020 von der CISA, von Herstellern von Wahlmaschinen und von mehreren US-Bundesstaaten übernommen und ist bei Bugcrowd-Programmen standardmäßig dabei. HackerOne pflegt einen „Gold Standard Safe Harbor”. Dropbox, Mozilla und Programme aus der GitHub-Ära nutzen alle Varianten davon. Safe Harbor ist heute der Mainstream-Standard – und genau deshalb wirkt sein Fehlen wie ein Warnsignal auf jene Menschen, von denen Sie sich am meisten Meldungen wünschen.

Schützt das Gesetz Forscher nicht schon? Meistens nein

Viele Gründer nehmen an, dass Forscher nun sicher seien und eine eigene Klausel überflüssig sei, seit das US-Justizministerium seine Haltung zum Computer Fraud and Abuse Act gelockert hat. Diese Annahme ist in zwei wichtigen Punkten falsch.

Am 19. Mai 2022 überarbeitete das DOJ seine CFAA-Anklagepolitik dahingehend, dass es gutgläubige Sicherheitsforschung nicht verfolgen werde. Das war echter Fortschritt. Doch das DOJ stellte selbst ausdrücklich klar, dass die Änderung weder die zivilrechtliche Haftung berührt noch bundesstaatliche Computerkriminalitätsgesetze bindet. Wie die Kanzlei Wilson Sonsini in ihrer Analyse anmerkte, bleiben für Forscher offene Fragen und eine mögliche zivilrechtliche Haftung bestehen.

Übersetzt in Klartext: Ein Unternehmen kann einen Forscher weiterhin zivilrechtlich verklagen. Ein Staatsanwalt eines Bundesstaates kann auf Grundlage eines bundesstaatlichen Hacking-Gesetzes weiterhin Anklage erheben. Der bundesrechtliche strafrechtliche Schutzschild ist eng gefasst, und er liegt nicht in Ihrer Hand. Das einzige Instrument, das diese Lücken für die Menschen schließt, die Ihre Systeme testen, ist eine Safe-Harbor-Formulierung in Ihrer eigenen Policy. Das Gesetz setzt eine Untergrenze; erst Ihre Policy macht die Einladung echt.

„Responsible” versus „coordinated” Disclosure: Wörter zählen

Die Terminologie, die Sie wählen, signalisiert, ob Sie Forscher als Mitstreiter oder als Verdächtige sehen – und die Branche hat sich bewusst von dem vorbelasteten Begriff abgewandt.

„Responsible disclosure” ist wertend. Es unterstellt leise, dass jeder, der sich nicht an den vom Anbieter bevorzugten Zeitplan hält, unverantwortlich handle – womit die moralische Last vollständig dem Melder aufgebürdet wird und keine dem Anbieter, der auf einem Fix gesessen hat. CERT/CC und der Großteil der Sicherheits-Community verwenden heute Coordinated Vulnerability Disclosure (CVD), das den Prozess ohne erhobenen Zeigefinger beschreibt. Es rahmt Offenlegung als beidseitiges Koordinationsproblem ein – was sie ja tatsächlich ist.

Das ist keine akademische Haarspalterei. Erinnern Sie sich daran, dass Microsoft selbst mitten in der Krise von „responsible” auf „coordinated” umschwenkte. Moussouris hatte die ursprüngliche Wortwahl als „den ersten Schlag” bezeichnet. Wenn das Unternehmen im Auge des Sturms unter Druck sein Vokabular ändert, verrät Ihnen das, auf welches Wort die Menschen achten, die Bugs melden. Verwenden Sie „coordinated” in Ihrer Policy. Es kostet nichts und signalisiert Respekt.

Was es kostet, keine VDP zu haben: Schweigen oder der Graumarkt

Wenn Forscher nicht sicher melden können, verschwindet die Schwachstelle nicht. Sie erfahren schlicht nichts davon, bis sie als Waffe eingesetzt wird – weil der Finder verstummt ist oder einen besser zahlenden Käufer gefunden hat.

Das Ausmaß der Lücke ist groß. Nach HackerOnes eigener Zählung haben 93 % der Forbes-Global-2000-Unternehmen keine veröffentlichte Möglichkeit, über die Forscher ein Sicherheitsproblem melden könnten. Das ist HackerOnes Befund und kein unabhängiger Zensus, doch die Richtung ist unstrittig: Die meisten Organisationen haben keine Eingangstür.

Der Alternativmarkt folgt brutaler Ökonomie. Exploit-Preise auf dem Graumarkt stellen jede Anbieterprämie in den Schatten. Broker wie Crowdfense haben bis zu rund 9 Mio. $ für eine vollständige mobile Zero-Click-Exploit-Kette ausgelobt; Browser-Exploits erzielen 3 bis 3,5 Mio. $; Zerodium hat bis zu 2 Mio. $ für eine Android-Kette zur Remotecodeausführung beworben. Mit diesen Preisen konkurrieren Sie nicht – und das müssen Sie auch nicht. Sie müssen koordinierte Meldungen nur sicher und reibungslos genug machen, damit ein Forscher den legalen Weg wählt. Ein Drohbrief treibt ihn in die andere Richtung.

Die fünf Zutaten einer Policy, die beide Seiten schützt

Eine Disclosure Policy, die funktioniert, ist kurz und konkret. Sie hat fünf Teile, und ein Forscher sollte sie in zwei Minuten lesen und genau wissen können, was erlaubt ist.

Beim Timing orientieren Sie sich an etablierten Normen, damit keine Seite bei null verhandeln muss. Das faktische Branchenstandard-Offenlegungsfenster liegt bei rund 90 Tagen; CERT/CC nutzt standardmäßig etwa 45 Tage; Google Project Zero setzt bei aktiv ausgenutzten Bugs eine Frist von 7 Tagen. Ein SLA von 24 bis 48 Stunden für die Eingangsbestätigung ist gängige Praxis und das mit Abstand günstigste Vertrauenssignal, das Sie bieten können. Der zentrale Vorwurf des Forschers Nightmare-Eclipse betraf die schlechte Behandlung – ein gesperrtes Konto, eine einbehaltene Prämie, eine gestrichene Nennung –, nicht das Ausbleiben einer Auszahlung. Bekommen Sie die Vertrauenssignale richtig hin, entstehen die meisten Streitigkeiten gar nicht erst.

So bauen Sie es vom ersten Tag an auf, ohne Enterprise-Aufwand

Der Grund, warum die meisten Startups auf eine VDP verzichten, ist keine Uneinigkeit mit irgendetwas davon. Es liegt daran, dass die vorhandene Anleitung entweder ein abstrakter Standard oder eine juristische Vorlage ist – ohne ein laufendes Programm dahinter. OWASP liefert Ihnen die Theorie. disclose.io liefert Ihnen die Klausel. Keines liefert Ihnen Sichtung, SLAs oder einen Ort, an dem Forscher tatsächlich eine Meldung einreichen und deren Fortschritt verfolgen können.

Genau diese Lücke schließt das Sicherheitsmodul von Kit. Statt ein Policy-Dokument, ein Kontaktformular und eine Tabelle zusammenzustückeln, konfigurieren Sie ein einziges Programm, das direkt auf die fünf Zutaten oben abbildet:

• Safe Harbor und Geltungsbereich sind Teil der Programmkonfiguration, sodass die Autorisierungsformulierung und die Liste der Assets im Geltungsbereich in der Policy stehen, die ein Forscher liest – und nicht im Gedächtnis eines Gründers.
• Ein geführter Setup-Ablauf bringt ein neues Konto von null zu einem laufenden Programm, sodass „Wo fange ich überhaupt an” nie zur Sackgasse wird.
• Ein standardisierter Workflow für Coordinated Disclosure erledigt Sichtung, Schweregrad-Bewertung und Duplikatsprüfung für jeden Melder auf dieselbe Weise – genau die Konsistenz, die Microsoft fehlte.
• Vertrauenssignale für Forscher sind eingebaut: programminterne Nachrichten, transparenter Sichtungsstatus, Forscher-Karma sowie eine saubere Prämien- und Finanzhauptbuch-Historie, damit sich niemand ignoriert oder geprellt fühlt.
• Zugesagte SLAs und sichtbare Zeitleisten halten die Reaktion schnell und nachvollziehbar und beseitigen das langsam-und-still-Muster, das Forscher in Richtung öffentlicher Offenlegung drängt.

Eine ehrliche Einschränkung, weil es bei diesem Artikel gerade nicht um Übertreibung geht: Kit gibt Ihnen das operative Gerüst und den richtigen Ort für Ihre Safe-Harbor-Formulierung. Es ist keine Rechtsberatung. Lassen Sie Ihren endgültigen Policy-Text von einem Anwalt prüfen, bevor Sie ihn veröffentlichen, besonders die Formulierungen zu Autorisierung und Geltungsbereich. Das offen auszusprechen, ist selbst ein Vertrauenssignal und passt zur These: Klarheit schlägt Mehrdeutigkeit jedes Mal.

Wenn Sie die Mechanik vertiefen möchten, behandelt unser Leitfaden dazu, wie Sie ein Vulnerability-Disclosure-Programm aufsetzen, die Eingangs-Infrastruktur, und wenn Forscher an die Öffentlichkeit gehen geht der Frage nach, warum langsame Bearbeitung und nicht Feindseligkeit Zero-Day-Veröffentlichungen hervorbringt. Wenn Sie in die EU liefern, macht die Offenlegungsfrist des Cyber Resilience Act eine CVD-Policy zur gesetzlichen Pflicht und nicht bloß zur Best Practice.

Eine Day-One-Checkliste für Gründer

Sie brauchen dafür kein Sicherheitsteam. Sie brauchen einen Nachmittag. Hier das Minimum:

1. Veröffentlichen Sie eine Safe-Harbor-Klausel, die festhält, dass Sie keine rechtlichen Schritte gegen gutgläubige Forscher einleiten, die im Geltungsbereich bleiben. Übernehmen Sie sie von disclose.io und lassen Sie sie von einem Anwalt prüfen.
2. Definieren Sie Ihren Geltungsbereich ausdrücklich: welche Domains und Assets freigegeben sind und was tabu ist (keine Datenexfiltration, kein DoS, kein Social Engineering, keine Drittanbieterdienste).
3. Öffnen Sie einen Meldekanal und machen Sie ihn mit einer security.txt-Datei unter /.well-known/security.txt bekannt.
4. Verpflichten Sie sich zu einem Reaktions-SLA: bestätigen Sie den Eingang innerhalb von 48 Stunden und geben Sie einen realistischen Zeitplan für Fix und Offenlegung an.
5. Verwenden Sie durchgängig „coordinated”, nicht „responsible” disclosure, und sagen Sie jedem, der es möchte, eine Nennung zu.

Microsofts Fehler war, zur rechtlichen Drohung zu greifen, als es zu einer klaren Policy hätte greifen sollen. Ein Startup hat den Vorteil, die Policy zuerst aufzubauen – vor dem ersten verärgerten Forscher, vor der ersten unbeholfenen Meldung in support@, bevor die Zahl der unbehobenen Bugs öffentlich zu steigen beginnt. Verankern Sie Safe Harbor, Geltungsbereich, SLAs und Vertrauenssignale jetzt in Ihrem Disclosure-Programm, und Sie müssen den Entschuldigungs-Blogbeitrag später nie schreiben.

Stellen Sie noch heute Nachmittag eine forscherfreundliche VDP auf die Beine, nicht erst nächstes Quartal. Starten Sie kostenlos mit Kit und konfigurieren Sie Ihr Disclosure-Programm an einem einzigen Ort.