Wissen · Ratgeber

Bug Bounty und Vulnerability Disclosure: Plattformen im Überblick

Ein Bug Bounty bezahlt externe Sicherheitsforschende für gültige Funde, ein Vulnerability Disclosure Programme (VDP) bietet ihnen nur einen sicheren, dokumentierten Meldeweg, und ein Pentest ist ein zeitlich begrenzter Test durch ein Team deiner Wahl. Plattformen bieten jedes dieser Formate an. Für die meisten Unternehmen ist ein VDP mit security.txt der sinnvolle Start, ein bezahltes Bounty folgt, wenn Triage und Behebung zuverlässig laufen.

Aktualisiert: 6. November 2026

Bug Bounty, VDP und Pentest: die Unterschiede

Ein VDP ist eine veröffentlichte Richtlinie. Sie sagt jedem, der eine Schwachstelle findet, wohin er sie melden kann, was du damit tust und was du im Gegenzug zusicherst. Meist gibt es Anerkennung statt Geld, und das Programm läuft dauerhaft ohne Enddatum.

Ein Bug Bounty baut darauf auf und ergänzt Belohnungen. Forschende erhalten Geld für gültige Funde im Scope, meist gestaffelt nach Schweregrad. Ein Pentest funktioniert anders: Du beauftragst ein festes Team für einen festen Zeitraum und Umfang und bekommst einen Bericht. Das liefert planbare Abdeckung, während ein Bounty fortlaufende Abdeckung mit schwankenden Ergebnissen bringt.

Viele Organisationen kombinieren die Formate: ein Pentest vor dem Go-live, ein VDP als dauerhafte Anlaufstelle und ein Bounty für die Systeme, die du am genauesten prüfen lassen willst. Mehrere der unten genannten Plattformen bieten alle drei Formate an. Die Frage ist deshalb selten, was es gibt, sondern was dein Team betreiben kann.

Privat oder öffentlich, betreut oder in Eigenregie

An einem öffentlichen Programm kann jede registrierte Person teilnehmen. Das bringt die meisten Augen, aber auch das meiste Rauschen. Ein privates Programm lädt nur einen begrenzten Kreis ein, oft von der Plattform nach Erfahrung ausgewählt. Es passt, wenn du weniger, aber bessere Meldungen willst oder noch nicht bereit für offenen Zulauf bist. Viele starten privat und öffnen später.

Betreut oder in Eigenregie beschreibt, wer die Arbeit rund um die Meldungen erledigt. Bei plattformseitiger Triage prüfen Mitarbeitende des Anbieters die Eingänge, sortieren Duplikate und ungültige Meldungen aus und geben dir einen validierten Fall weiter. In Eigenregie erhältst du die Rohmeldungen und entscheidest alles selbst. Das spart Geld und kostet interne Zeit. Manche Anbieter stellen auch ein gehostetes VDP-Werkzeug bereit, oder du setzt Open-Source-Software auf eigener Infrastruktur ein. Frag jeden Anbieter genau, welche Schritte enthalten sind, wer den Schweregrad festlegt und wo deine Daten liegen.

Die wichtigsten Plattformen im Überblick

Die Liste ist alphabetisch und kein Ranking. Beschreibungen und Standorte folgen den Angaben der Anbieter auf ihren eigenen Websites, Stand November 2026. Nennt eine Seite keinen Hauptsitz, geben wir auch keinen an. Klär Umfang, Preise und Vertragsbedingungen direkt mit dem Anbieter.

• Bugcrowd: Crowdsourcing-Bug-Bounty, VDP und Penetrationstests; San Francisco (USA) und Sydney (Australien).
• HackerOne: Bug Bounty, VDP, Pentests und kontinuierliche Tests auf einer Plattform mit Forschendencommunity; Hauptsitz San Francisco (USA).
• Intigriti: Bug Bounty, VDP, Pentest as a Service und Live-Hacking-Events mit Datenhaltung in der EU; Büros in Antwerpen (Belgien) und London (Vereinigtes Königreich).
• Open Bug Bounty: gemeinnützige Plattform für koordinierte Offenlegung von Web-Schwachstellen, die ohne intrusive Tests gefunden wurden; die Seite nennt keinen Standort, Belohnungen sind optional.
• Synack: Pentests mit einem geprüften Forschendennetzwerk, dazu KI-gestützte Tests, Attack-Surface-Management und ein VDP-Angebot; globaler Hauptsitz in Redwood City, Kalifornien (USA).
• YesWeHack: Bug Bounty, VDP, Vulnerability Management und Exposure Management mit Anbindung an Ticketsysteme.
• Yogosha: Bug Bounty, VDP, Pentest as a Service und Sonderformate wie Red Teaming; Hauptsitz in Paris (Frankreich).
• Zerocopter: koordinierte Schwachstellenmeldung, Bug Bounty, Pentests und Reconnaissance; Büro in Groningen (Niederlande).

security.txt und die ISO-Normen

RFC 9116 vom April 2022 definiert security.txt, eine kleine Textdatei, die Forschenden zeigt, wie sie dich erreichen. Es ist ein informatives RFC und kein Internetstandard. Pflicht sind ein Contact-Feld und ein Ablaufdatum (Expires). Die Datei wird per HTTPS unter /.well-known/security.txt ausgeliefert und sollte vor Ablauf erneuert werden. Auch das BSI empfiehlt sie, zusammen mit einem Funktionspostfach wie psirt@ und einem OpenPGP-Schlüssel.

ISO/IEC 29147 beschreibt, wie ein Hersteller Schwachstellenmeldungen entgegennimmt und Sicherheitshinweise veröffentlicht. ISO/IEC 30111 deckt den Teil dazwischen ab: untersuchen, beheben, prüfen. Beide liegen in der zweiten Ausgabe vor (2018 und 2019); ISO führt sie als aktuell und zur Überarbeitung vorgesehen. Nutze sie als Checkliste für den eigenen Prozess, auch ohne Zertifizierungsabsicht.

Auf EU-Ebene verpflichtet Artikel 12 der NIS-2-Richtlinie jeden Mitgliedstaat, ein nationales CSIRT als Koordinator für die koordinierte Offenlegung zu benennen. Der Koordinator kann als neutraler Vermittler zwischen Meldenden und Hersteller auftreten, und die ENISA pflegt eine europäische Schwachstellendatenbank.

EU Cyber Resilience Act: Pflichten und Termine

Die Verordnung (EU) 2024/2847, der Cyber Resilience Act (CRA), gilt für Hersteller von Produkten mit digitalen Elementen, die in der EU angeboten werden. Laut Europäischer Kommission trat sie am 10. Dezember 2024 in Kraft. Die Meldepflichten gelten ab dem 11. September 2026, die Hauptpflichten ab dem 11. Dezember 2027.

Seit dem 11. September 2026 muss ein Hersteller, dem eine aktiv ausgenutzte Schwachstelle in seinem Produkt oder ein schwerwiegender Sicherheitsvorfall bekannt wird, dies über die zentrale Meldeplattform der ENISA melden, die an diesem Tag in Betrieb ging. Die Meldung geht an das CSIRT des Mitgliedstaats der Hauptniederlassung. Die Fristen: Frühwarnung binnen 24 Stunden, ausführlichere Meldung binnen 72 Stunden und Abschlussbericht binnen 14 Tagen, nachdem eine Korrektur oder Abhilfe verfügbar ist (bei Schwachstellen), bzw. binnen eines Monats nach der 72-Stunden-Meldung (bei schweren Vorfällen).

Ab Dezember 2027 gelten zusätzlich die Anforderungen an den Umgang mit Schwachstellen aus Anhang I. Dazu gehören eine Richtlinie zur koordinierten Offenlegung und eine Kontaktadresse für Meldungen. Ein Bug Bounty verlangt der CRA nicht, aber ein VDP, eine security.txt und ein funktionierender Meldeprozess sind ein praktischer Weg, diese Punkte zu erfüllen. Lass juristisch klären, welche deiner Produkte im Anwendungsbereich liegen.

Rechtlicher Schutz für Forschende (Safe Harbour)

Forschende fürchten, dass gutgläubiges Testen als unbefugter Zugriff gewertet wird. Eine Safe-Harbour-Klausel in deiner Richtlinie erklärt, dass du gegen Personen, die sich an die Regeln halten, nicht rechtlich vorgehst. Sie ändert nicht das Gesetz und bindet weder Staatsanwaltschaften noch Dritte, nimmt aber einen wichtigen Grund, lieber zu schweigen.

Die gemeinnützige Organisation disclose.io stellt offene, herstellerneutrale Richtlinienvorlagen und Safe-Harbour-Formulierungen bereit. Auch Plattformen haben meist eigene Standardbedingungen. Lass den Wortlaut von deiner Rechtsabteilung gegen das nationale Recht prüfen, besonders bei Tätigkeit in mehreren Ländern, und regle Systeme Dritter, personenbezogene Daten und das Verhalten nach einem gefundenen Zugang.

Vorbereitung vor dem Start

Die meisten Programme scheitern am Betrieb, nicht an der Technik. Kläre Folgendes, bevor du jemanden einlädst.

• Scope: Liste Domains, Apps und APIs im Scope auf und benenne Ausschlüsse wie Produktivdaten, Denial of Service, Social Engineering und Dienste Dritter.
• Triage-Kapazität: Lege fest, wer Meldungen liest, wie schnell du bestätigst und wer die Funde behebt. Reserviere Zeit in der Entwicklung.
• Belohnungsrichtlinie: Wähle eine Schweregrad-Skala, Spannen je Stufe, einen Auszahlungsprozess und eine Regel für Duplikate. Kannst du noch nicht zahlen, starte mit einem VDP.
• Spielregeln: Definiere Testkonten, Ratenlimits, Datenumgang und Zeitpunkt der Veröffentlichung.
• Recht und Kommunikation: Ergänze Safe Harbour, benenne die Kontaktstelle und plane den internen Eskalationsweg für kritische Funde.
• Grundhygiene: Behebe bekannte Schwächen zuerst, denn ein Bounty auf einem ungepatchten System ist ein teurer Weg, etwas zu finden, das ein Scan auch gezeigt hätte.