Bug Bounty vs VDP: Den Unterschied verstehen

Organisationen nutzen "Bug Bounty" und "Vulnerability Disclosure Program" oft austauschbar. Das sind sie nicht. Die Unterscheidung betrifft Kosten, rechtliche Implikationen und Forscher-Beziehungen.

Ein Vulnerability Disclosure Program bietet einen Kanal für Forscher, Security-Issues zu melden. Es bietet typischerweise rechtlichen Safe Harbor und Anerkennung, aber keine Zahlung. Ein Bug Bounty Program zahlt Forscher für valide Vulnerability-Reports. Die Zahlung ist das definierende Merkmal.

Jedes Bug-Bounty-Programm beinhaltet die Elemente eines VDP, aber nicht jedes VDP beinhaltet Bounties. Du kannst kein Bug Bounty ohne das Disclosure-Framework betreiben, aber du kannst absolut ein Disclosure-Programm ohne Zahlungen betreiben.

Legal Framework

Ein VDP bietet rechtliche Klarheit, dass Security-Research auf deinen Systemen nicht zu rechtlichen Schritten führt, vorausgesetzt Forscher folgen deinen Regeln. Das ist wichtig, weil Security-Testing technisch Computer-Fraud-Gesetze in vielen Jurisdiktionen verletzen kann. Ohne expliziten Safe Harbor riskieren Forscher rechtliche Exposition, selbst wenn sie Vulnerabilities verantwortungsvoll melden.

Bug Bounties beinhalten denselben rechtlichen Schutz, fügen aber Zahlungsbedingungen hinzu, was eine vertragliche Beziehung mit finanziellen Verpflichtungen schafft. Das macht das Legal Framework etwas komplexer, aber die Safe-Harbor-Bestimmungen funktionieren gleich.

Der Safe Harbor spezifiziert typischerweise, welche Systeme im Scope sind, welche Testing-Methoden erlaubt sind, was Forscher nicht tun dürfen und wie sie Findings melden sollen. Übliche Restriktionen beinhalten keine Daten-Exfiltration, keine Service-Disruption und kein Zugriff auf andere User-Daten jenseits dessen, was nötig ist, um die Vulnerability zu demonstrieren.

Kostenstruktur

Ein VDP hat minimale direkte Kosten. Du brauchst Infrastruktur, um Reports zu empfangen, Staff-Zeit zum Triagieren und Antworten, und Ressourcen zum Fixen von Issues. Aber es gibt keine Per-Vulnerability-Zahlung. Deine Kosten sind größtenteils fix, unabhängig davon, wie viele Reports du erhältst.

Bug Bounties haben variable Kosten basierend auf Submissions. Ein seriöses Programm könnte jährlich €100.000 oder mehr in Bounties zahlen, plus Plattform-Gebühren wenn du einen Third-Party-Service nutzt. Kosten sind unvorhersehbar. Ein Forscher könnte zehn kritische Issues in einem Monat finden, oder du könntest Monate ohne valide High-Severity-Reports haben.

Organisationen starten oft mit einem VDP, um Prozesse zu etablieren, und fügen dann Bounties hinzu, sobald sie Vertrauen in ihre Fähigkeit haben, Volumen zu handeln und Budget für Zahlungen allokiert haben.

Forscher-Motivation

VDP-Forscher sind durch Reputation, Community-Beitrag, Lernen oder ethische Verpflichtung motiviert. Viele Forscher melden Vulnerabilities ohne Erwartung von Zahlung, weil sie glauben, es ist das Richtige zu tun. Einige bauen Portfolios für zukünftige Beschäftigung. Andere genießen einfach die intellektuelle Herausforderung, Security-Issues zu finden.

Bug-Bounty-Forscher beinhalten professionelle Security-Tester, die ihre Zeit basierend auf erwartetem Return allokieren. Höhere Bounties ziehen skillte Forscher und mehr Attention zu deinem Programm an. Aber das bedeutet nicht, dass Bug-Bounty-Forscher inhärent besser sind. Einige der skilltesten Security-Forscher partizipieren selten an Bounties, bevorzugend zu Projekten beizutragen, die ihnen wichtig sind, oder auf spezifische Research-Interessen zu fokussieren.

Scope Definition

VDPs haben oft breiten Scope. "Wenn du ein Security-Issue in irgendeinem unserer Systeme findest, melde es bitte" funktioniert für viele Programme. Das Ziel ist, jede Security-Information zu fördern, die hilft, die Security-Posture zu verbessern.

Bug Bounties haben typischerweise engeren Scope, weil du für Findings zahlst. Du definierst explizit, was im Scope ist und für welche Vulnerabilities du zahlst. Out-of-Scope-Findings werden möglicherweise noch akzeptiert, aber ohne Zahlung. Du lenkst Forscher-Attention auf deine höchst-prioritären Systeme.

Payment Models

Bug Bounties nutzen verschiedene Payment-Ansätze. Fixed Bounties setzen spezifische Beträge per Severity-Level, wie €5000 für Critical, €2000 für High. Variable Bounties lassen dein Team jedes Finding bewerten und angemessene Zahlung basierend auf multiplen Faktoren bestimmen. Einige Plattformen nutzen Point-Systeme, die zu Zahlung konvertieren.

Wann VDP wählen

Ein VDP macht Sinn, wenn du Vulnerability Disclosure startest und erst Prozesse etablieren willst. Es funktioniert gut, wenn dein Budget keine Bounty-Zahlungen unterstützt oder du eine Non-Profit oder kleine Organisation mit limitierten Ressourcen bist. Wähle ein VDP, wenn dein primäres Ziel rechtliche Klarheit ist statt Forscher-Recruitment, oder wenn du niedrige Volumen organischer Security-Reports handhaben willst.

Wann Bounties hinzufügen

Erwäge Bounties hinzuzufügen, wenn du erfolgreich ein VDP betrieben hast und Prozesse etabliert sind. Du brauchst Budget für variable Security-Kosten und Kapazität, höhere Submission-Volumen zu handhaben. Füge Bounties hinzu, wenn du spezifische Assets oder Vulnerability-Typen priorisieren willst, wenn du externes Security-Testing brauchst, um interne Efforts zu complementieren, oder wenn dein Threat Model die zusätzlichen Kosten rechtfertigt.

Hybrid-Ansätze

Einige Organisationen betreiben beides. Sie maintainen ein VDP mit breitem Scope, das Reports auf jedem System ohne Zahlung akzeptiert, während sie ein Bug Bounty mit engem Scope betreiben, das Zahlung für spezifische kritische Systeme bietet. Das catched organische Reports durch das VDP, während bezahlte Attention auf Prioritäts-Systeme durch das Bounty fokussiert wird.

Plattform vs Self-Hosted

VDPs können leicht self-hosted werden. Eine security.txt-Datei, eine E-Mail-Adresse und eine Webpage, die deinen Prozess erklärt, sind ausreichend. Der operationale Overhead ist für die meisten Organisationen managebar.

Bug Bounties nutzen oft Plattformen wie HackerOne oder Bugcrowd, weil sie Payment-Processing, Forscher-Verification und Volume-Management handhaben. Self-hosted Bounties existieren, erfordern aber das Lösen operationaler Probleme wie Payment-Processing, Tax-Compliance über Jurisdiktionen hinweg und Forscher-Identity-Verification. Wenige Organisationen haben die Expertise, das gut zu handhaben.

Zwischen Modellen wechseln

Von VDP zu Bounty zu wechseln ist straightforward. Füge Payment-Terms hinzu, allokiere Budget und announche die Änderung. Forscher, die bereits partizipiert haben, werden die Compensation schätzen, und neue Forscher werden joinen.

Von Bounty zu VDP zu wechseln, indem man Zahlungen entfernt, ist härter. Forscher, die wegen Zahlung engagiert waren, werden stoppen zu partizipieren. Wenn du das tun musst, announce es klar und mit Vorankündigung. Erkläre warum und danke Partizipanten für ihre vergangenen Beiträge.

Rechtliche Anforderungen

Einige Jurisdiktionen erwägen, VDPs für bestimmte Organisationen zu fordern. Die EU's NIS2-Direktive erwähnt Coordinated-Disclosure-Capabilities. US-Government-Contractors brauchen oft VDPs als Teil ihrer Security-Requirements. Aber keine Jurisdiction fordert Bug Bounties. Sie sind immer optional.

Welches solltest du wählen?

Für die meisten Organisationen ist die Progression klar. Starte ohne formelles Programm, wo Forscher keinen klaren Weg haben, Issues zu melden. Füge ein Basic-VDP hinzu, um Safe Harbor und einen Reporting-Channel zu etablieren. Mature dein VDP mit konsistenten Response-Times und public Acknowledgment. Erwäge ein Private Bug Bounty, das spezifische Forscher einlädt, spezifische Systeme zu testen. Schließlich launche ein Public Bug Bounty, offen für alle Forscher.

Diese Progression lässt dich Capability bei jeder Stage bauen, bevor du die Komplexität der nächsten hinzufügst. Die Schlüsselfrage ist nicht "Bug Bounty oder VDP?" Sie ist "Für welche Stage sind wir bereit?" Starte mit dem, was du sustainen kannst, und entwickle dich dann, während deine Capability wächst.