Ein Vulnerability Disclosure Program 2026 aufsetzen

Ein Vulnerability Disclosure Program (VDP) ist ein strukturierter Prozess, der externen Sicherheitsforschern einen sicheren, rechtlich geschützten Kanal zur Meldung von Schwachstellen in Ihrem Produkt bietet. Anders als ein Bug Bounty, das pro Fund eine Vergütung zahlt, schafft ein VDP lediglich den Meldemechanismus. Jedes Unternehmen mit einem über das Internet erreichbaren Produkt braucht eines. Die U.S. Cybersecurity and Infrastructure Security Agency (CISA) hat VDPs für Bundesbehörden 2020 durch die Binding Operational Directive 20-01 verpflichtend gemacht, und der Privatsektor ist seitdem rasch nachgezogen.

Warum Ihr Startup ein VDP braucht, bevor alles andere kommt

Sicherheitsforscher werden Schwachstellen in Ihrem Produkt finden, ob Sie sie dazu einladen oder nicht. Die einzige Frage ist, was danach passiert.

Stellen Sie sich ein konkretes Szenario vor. Ein Forscher entdeckt eine SQL-Injection in Ihrer API. Ohne VDP hat er drei Optionen: eine E-Mail an Ihre allgemeine Support-Adresse schicken und hoffen, dass jemand Technisches sie liest, das Problem öffentlich in sozialen Medien posten oder es in einem Forum verkaufen. Keines dieser Ergebnisse ist gut für Sie. Mit einem VDP hat der Forscher einen klaren Meldeweg, und Sie haben einen strukturierten Prozess, um das Problem zu bewerten und zu beheben, bevor es zu einem Datenleck wird.

Die wirtschaftlichen Fakten sind eindeutig. Laut dem 2024 Cost of a Data Breach Report von IBM belaufen sich die durchschnittlichen Kosten eines Datenlecks auf 4,88 Millionen US-Dollar weltweit. Für ein Startup in der Seed-Phase ist diese Summe existenzbedrohend. Die Einrichtung eines VDP kostet hingegen nichts außer Entwicklerzeit. Vergleichen Sie das mit einem Penetrationstest, der zwischen 15.000 und 50.000 US-Dollar pro Durchführung kostet.

Auch der regulatorische Druck nimmt zu. Die NIS2-Richtlinie der EU, seit Oktober 2024 in Kraft, verpflichtet Organisationen in kritischen Sektoren zur Umsetzung einer koordinierten Schwachstellenmeldung. Die US-SEC-Cybersecurity-Regeln von 2023 verlangen von börsennotierten Unternehmen, wesentliche Vorfälle innerhalb von vier Geschäftstagen zu melden. SOC 2-Prüfer fragen zunehmend nach Nachweisen für einen externen Schwachstellen-Eingang, und mehrere Trust Services Criteria (CC7.1, CC7.2) sind direkt auf VDP-Fähigkeiten abbildbar. Wenn Sie an Enterprise-Kunden verkaufen wollen, taucht ein veröffentlichtes VDP in Sicherheitsfragebögen auf. Fragen zum Schwachstellenmanagement sind mittlerweile Standard in Lieferanten-Sicherheitsbewertungen, und ein VDP gibt dem Einkauf eine sofortige Antwort, die Ihren Vertriebszyklus verkürzt.

VDP vs. Bug Bounty: Was kommt zuerst?

Ein VDP ist das Fundament. Ein Bug Bounty fügt eine finanzielle Anreizschicht darüber hinzu. Mit einem Bug Bounty zu beginnen, bevor Sie das Meldevolumen bewältigen können, ist ein häufiger und teurer Fehler.

Laut dem 2024 Hacker-Powered Security Report von HackerOne haben 77 % der Organisationen mit Bug-Bounty-Programmen zunächst mit einem VDP begonnen. Die These ist einfach: Bauen Sie den Prozess auf, bevor Sie das Budget einplanen. Ein fünfköpfiges Startup kann nicht mit der Triage-Geschwindigkeit von Google mithalten, aber es kann durchaus ein professionelles VDP betreiben.

Die vier Phasen der VDP-Implementierung

Die Einführung eines VDP ist kein Wochenendprojekt, erfordert aber auch keine monatelange Planung. Der Prozess gliedert sich in vier Phasen, die ein einzelner Entwickler in einer Woche abschließen kann.

Phase 1: Scope-Definition

Definieren Sie genau, welche Assets Forscher testen dürfen. Seien Sie konkret bei Domains, APIs und mobilen Apps. Unklarheiten verursachen Probleme in beide Richtungen: Forscher verschwenden Zeit mit Assets außerhalb des Scope, und Sie erhalten Meldungen, die Sie nicht bearbeiten können.

Im Scope: Produktive Webanwendungen, öffentliche APIs, mobile Apps, spezifische Subdomains unter Ihrer Kontrolle. Außerhalb des Scope: Interne Unternehmensinfrastruktur, Mitarbeiter-Accounts, SaaS-Dienste von Drittanbietern (Stripe, Intercom) und physische Sicherheit.

Ein zu breiter Scope ist für ein Seed-Stage-Startup gefährlich. Ihr Entwicklerteam hat begrenzte Kapazitäten für die Bewertung von Findings. Wenn ein Forscher eine Schwachstelle in einer Staging-Umgebung meldet, die Sie vergessen haben öffentlich zu lassen, müssen Sie reagieren können. Ein zu enger Scope sendet ein anderes Signal. Wenn Sie Ihr VDP auf eine einzelne Marketing-Seite beschränken, während Ihre tatsächliche Angriffsfläche APIs und mobile Apps umfasst, signalisiert das den Forschern, dass Sie es nicht ernst meinen.

Der Mittelweg: Nehmen Sie alles in den Scope auf, was Ihre Kunden nutzen. Das bedeutet produktive Web-Apps, öffentliche APIs und alle mobilen Clients, die Sie ausliefern. Schließen Sie aus, was Sie nicht beheben können (Drittanbieter-Integrationen, vom Anbieter verwaltete Infrastruktur).

Phase 2: Meldemechanismen und security.txt

Forscher brauchen einen sicheren, zuverlässigen Kanal zur Einreichung von Findings. Der minimale Ansatz ist eine dedizierte [email protected]-E-Mail-Adresse mit PGP-Verschlüsselung. Für Startups, die mehr als eine Handvoll Meldungen pro Monat erhalten, spart ein strukturiertes Webformular oder eine verwaltete Plattform (HackerOne Response, Bugcrowd VDP, Intigriti) erheblich Triage-Zeit.

Unabhängig vom gewählten Kanal ist der Erkennungsmechanismus standardisiert: security.txt. Definiert in RFC 9116, handelt es sich um eine maschinenlesbare Klartextdatei unter /.well-known/security.txt, die Forschern genau mitteilt, wo und wie sie Schwachstellen melden können.

Eine vollständige security.txt sieht so aus:

Contact: mailto:[email protected]
Contact: https://yourcompany.com/security/report
Expires: 2027-03-15T00:00:00.000Z
Encryption: https://yourcompany.com/.well-known/pgp-key.txt
Policy: https://yourcompany.com/security/policy
Preferred-Languages: en
Canonical: https://yourcompany.com/.well-known/security.txt

Das Expires-Feld ist verpflichtend. Setzen Sie es maximal ein Jahr in die Zukunft und richten Sie eine wiederkehrende Kalendererinnerung zur Aktualisierung ein. Eine abgelaufene security.txt signalisiert ein nicht gepflegtes Programm, was schlimmer ist als gar keines zu haben. Die Verbreitung ist nach wie vor gering. Laut Daten von securitytxt.org veröffentlichen nur etwa 1,25 % der Top-eine-Million-Websites eine security.txt-Datei (Stand 2025), gegenüber circa 0,5 % im Jahr 2022. Die geringe Verbreitung bedeutet, dass Ihre den Forschern auffallen wird. Veröffentlichen Sie sie, bevor Sie sie brauchen.

Phase 3: Safe-Harbor-Richtlinie

Dies ist die rechtlich sensibelste Komponente Ihres VDP. Ohne klare Safe-Harbor-Formulierungen werden Forscher Ihnen nichts melden. Sie befürchten eine Strafverfolgung nach dem Computer Fraud and Abuse Act (CFAA) in den USA oder vergleichbaren Gesetzen international.

Die CFAA-Leitlinien des US-Justizministeriums von 2022 stellen ausdrücklich fest, dass “gutgläubige Sicherheitsforschung nicht strafrechtlich verfolgt werden sollte.” Ihre Safe-Harbor-Klausel muss vier Zusicherungen enthalten: die Zusage, keine rechtlichen Schritte gegen Forscher einzuleiten, die der Richtlinie folgen, die Verpflichtung, keine CFAA- oder DMCA-Ansprüche bei gutgläubiger Forschung geltend zu machen, die Erklärung, mit Forschern zusammenzuarbeiten, falls Dritte rechtliche Schritte einleiten, und die Anerkennung, dass im Rahmen der Richtlinie durchgeführte Forschung autorisiert ist.

Eine schlecht formulierte Safe-Harbor-Klausel kann das Unternehmen entweder haftbar machen oder Forscher nicht ausreichend schützen, sodass diese keine Meldungen einreichen. Beginnen Sie mit den Community-Vorlagen von disclose.io, die von Rechtsteams der EFF, Dropbox und Bugcrowd geprüft wurden. Lassen Sie anschließend Ihre eigene Rechtsabteilung darüber schauen. Die meisten Startup-Anwälte erledigen das innerhalb von 24 Stunden.

Formulieren Sie Safe-Harbor-Klauseln nicht von Grund auf neu. Das ist ein juristisches Dokument. Die disclose.io-Vorlagen existieren genau deshalb, damit Startups nicht 10.000 US-Dollar an Anwaltskosten für eine Eigenentwicklung aufwenden müssen.

Phase 4: Interne SLAs und Triage-Prozess

Die Reaktionszeit ist das stärkste Signal dafür, ob Ihr VDP ernst gemeint ist oder nur pro forma existiert. Der Success Index von HackerOne zeigt durchgängig, dass Programme mit schnellen Reaktionszeiten deutlich mehr und qualitativ hochwertigere Meldungen erhalten. Forscher sprechen miteinander. Wenn drei Personen Probleme melden und nichts hören, ist Ihr Programm faktisch tot.

Definieren und veröffentlichen Sie diese SLAs, kalibriert auf das, was ein kleines Team tatsächlich leisten kann:

Verwenden Sie CVSS 4.0 (FIRST.org-Spezifikation, veröffentlicht im November 2023) für die Schweregradbewertung. Erfinden Sie keine eigene Skala. CVSS ist nicht perfekt, aber es ist eine gemeinsame Sprache zwischen Ihrem Team und der Forscher-Community.

Bauen Sie einen Triage-Workflow auf, der fünf Stufen abdeckt: Eingang (Meldungen treffen über einen dedizierten Kanal ein), Triage (ein Entwickler bewertet den Schweregrad mittels CVSS), Nachverfolgung (internes Ticket erstellen, niemals in öffentlichen GitHub Issues), Behebung (Zuweisung an das zuständige Team) und Rückmeldung (den Forscher bei jedem Statuswechsel informieren). Wenn der Fix ausgerollt ist, benachrichtigen Sie den Forscher und bieten Sie eine Nennung in einer öffentlichen Hall of Fame an.

Compliance-Frameworks, die ein VDP erfordern

Ein VDP ist nicht nur gute Praxis. Mehrere Frameworks verlangen mittlerweile ausdrücklich eines oder schaffen starke Anreize dafür.

SOC 2 Type II schreibt kein VDP namentlich vor, aber die Common Criteria für Risikobewertung (CC3.2) und Kommunikation (CC2.3) lassen sich mit einem dokumentierten externen Schwachstellen-Eingang deutlich leichter erfüllen. Prüfer erwarten es zunehmend.

ISO 27001:2022 Control A.8.8 verlangt von Organisationen, “Regeln für die Offenlegung von Schwachstellen festzulegen und umzusetzen.” Ein VDP erfüllt diese Anforderung direkt.

PCI DSS 4.0 Anforderung 6.3.1 schreibt die Identifizierung und Verwaltung von Sicherheitsschwachstellen aus externen Quellen vor. Ein VDP belegt die Erfüllung dieser Anforderung.

NIST Cybersecurity Framework 2.0 fordert, dass Schwachstellen in Assets “identifiziert, validiert und dokumentiert” werden (ID.RA-01), ausdrücklich einschließlich externer Entdeckung. Die neue Govern-Funktion (GV.SC-05) ergänzt Supply-Chain-Risikomanagement, bei dem VDPs eine zunehmend wichtige Rolle spielen.

NIS2-Richtlinie (EU) Artikel 12 verpflichtet Mitgliedstaaten, koordinierte Schwachstellen-Offenlegungsrichtlinien einzuführen. Organisationen in wesentlichen und wichtigen Sektoren müssen daran teilnehmen.

Für ein Seed-Stage-Startup ist das Compliance-Argument vorausschauend. Sie brauchen SOC 2 vielleicht heute noch nicht, aber Ihr erster Enterprise-Vertrag wird danach fragen. Wenn Ihr VDP beim Eintreffen des Prüfers bereits läuft, sparen Sie sich monatelanges Nachrüsten.

Vom VDP zum Bug Bounty: Wann finanzielle Belohnungen sinnvoll werden

Sobald Ihr VDP drei bis sechs Monate mit einem zuverlässigen Triage-Workflow läuft, können Sie über Bounties nachdenken. Sie sind bereit, wenn Ihre durchschnittliche Zeit bis zur ersten Antwort unter 24 Stunden liegt, Sie mindestens 80 % der gemeldeten Schwachstellen innerhalb Ihrer veröffentlichten SLAs behoben haben und Ihr Entwicklerteam einen Prozess hat, um Sicherheitsfixes neben Feature-Arbeit zu priorisieren.

Bounty-Beträge sollten die tatsächliche Auswirkung widerspiegeln. HackerOne-Daten von 2024 zeigen die medianen Auszahlungen: Kritisch (Remote Code Execution, Auth Bypass): 3.000 bis 15.000 USD. Hoch (Stored XSS, IDOR mit PII-Exposure): 1.000 bis 5.000 USD. Mittel (Reflected XSS, Information Disclosure): 250 bis 1.000 USD. Niedrig (Open Redirect, ausführliche Fehlermeldungen): 50 bis 250 USD.

Für Startups ist es völlig in Ordnung, am unteren Ende zu beginnen. Forscher legen mehr Wert auf Reaktionsgeschwindigkeit und respektvollen Umgang als auf maximale Auszahlungen. Ein Programm, das 500 USD zahlt und in 4 Stunden antwortet, zieht bessere Talente an als eines, das 5.000 USD zahlt und Meldungen wochenlang ignoriert.

So handhabt Kit die Schwachstellenmeldung

Kit enthält ein integriertes CSIRT-Modul (Computer Security Incident Response Team), das Vulnerability Disclosure als erstklassigen Workflow behandelt.

Das Modul liefert ein anpassbares Sicherheitsportal auf Ihrer Domain, über das Forscher strukturierte Meldungen einreichen: Schwachstellentyp, betroffene Assets, Reproduktionsschritte und Auswirkungsanalyse. Kein mühsames Auswerten von Freitext-E-Mails oder verlorene Meldungen im Sammelpostfach mehr. Jede Meldung durchläuft eine definierte Triage-Pipeline mit konfigurierbaren SLAs. Kit verfolgt automatisch die Zeit bis zur ersten Antwort, bis zur Triage und bis zur Behebung. Wenn eine Frist naht, wird das zuständige Teammitglied benachrichtigt. Wenn sie überschritten wird, greifen Eskalationsregeln.

Kit generiert und pflegt Ihre security.txt-Datei automatisch, einschließlich des verpflichtenden Expires-Feldes mit einer wiederkehrenden Prüfung, die Sie warnt, bevor es abläuft. Das Sicherheitsportal unterstützt eigene Domains, sodass Forscher mit security.ihrfirma.de interagieren statt mit einer Drittanbieter-Plattform-URL.

Das Modul umfasst außerdem eine öffentliche Hall of Fame, Slack-Integration für Echtzeit-Benachrichtigungen bei Meldungen und Forscherkommunikation direkt über das Portal. Auszahlungen für Bug-Bounty-Vergütungen werden mit einem vollständigen Ledger nachverfolgt, das Ihnen prüfungsbereite Aufzeichnungen für SOC 2- und ISO 27001-Reviews liefert.

Für Startups, die sowohl Recruiting als auch Security-Infrastruktur benötigen, bedeutet der Betrieb beider Bereiche auf einer Plattform: ein Anbieter weniger, ein Sicherheitsfragebogen weniger und ein Login weniger für Ihr Team.

Starten Sie Ihr VDP diese Woche

Sie brauchen keine monatelange Planung. Hier ist, was ein einzelner Entwickler in fünf Tagen schaffen kann.

Tag 1 bis 2: Richtlinie schreiben. Beginnen Sie mit den disclose.io-Vorlagen. Definieren Sie den Scope. Lassen Sie die Safe-Harbor-Formulierungen von der Rechtsabteilung prüfen.

Tag 3: Meldekanal einrichten. Konfigurieren Sie eine security@-E-Mail-Adresse mit PGP oder richten Sie ein Webformular ein. Veröffentlichen Sie Ihre security.txt unter /.well-known/security.txt.

Tag 4: Triage-Workflow aufbauen. Legen Sie fest, wer Meldungen erhält, wie der Schweregrad bewertet wird und wie Fixes intern nachverfolgt werden.

Tag 5: Testen, indem Sie eine Meldung durch Ihren eigenen Prozess einreichen. Prüfen Sie, ob die Bestätigungs-E-Mails ausgelöst werden, der Triage-Workflow korrekt routet und die Antwortvorlagen verständlich sind. Dann ankündigen: Link im Website-Footer hinzufügen, Beitrag auf dem Engineering-Blog veröffentlichen und relevante Security-Communities benachrichtigen.

Ein VDP ist kein einmaliges Projekt. Es ist eine dauerhafte operative Verpflichtung gegenüber Ihren Nutzern. Die Einrichtung dauert eine Woche. Die Glaubwürdigkeit, die es aufbaut, wächst über Jahre. Beginnen Sie jetzt, solange es noch ein Wettbewerbsvorteil ist und nicht eine regulatorische Pflichtübung, die Sie überstürzt nachholen müssen.