Wie gründlich sollten Sie Bug-Bounty-Forscher prüfen?

Die Prüfung von Bug-Bounty-Forschern ist ein Regler, kein Schalter. Wie viel Sie über eine Forscherin verifizieren, richtet sich danach, wie sensibel das ist, was sie berühren kann – anhand von vier Stufen: reine Badge-Aufnahme (jeder kann melden, keine Identität nötig), ID-verifizierte Auszahlungen (pseudonyme Meldung, aber Identitäts-, Steuer- und Sanktionsprüfung, bevor Geld fließt), vertrauensbasierter Privatzugang (durch Reputation verdiente Einladungen plus verpflichtende ID-Verifizierung) und hintergrundgeprüft oder vertraglich gebunden (strafrechtliche Prüfung und namentlich benannte, vertraglich gebundene Tester für den kronjuwelenartigen Geltungsbereich). Der Fehler, den Gründer machen: Sie übernehmen die Voreinstellung eines Marktplatzes, statt die Kerbe zu wählen, die ihr Bedrohungsmodell tatsächlich braucht.

Sie sind im Begriff, Fremde einzuladen, Ihre Produktion abzuklopfen. Die Frage unter jedem Vulnerability-Disclosure-Programm (VDP) ist einfach und unbequem: Wen genau lasse ich herein, und wie viel muss ich vorher über ihn wissen? Das ist die Antwort, Stufe für Stufe.

Was „einen Forscher prüfen“ eigentlich bedeutet

Prüfen ist nicht eine Sache. Es sind drei getrennte, kombinierbare Kontrollen, die Gründer ständig vermengen – und die großen Plattformen schalten jede einzeln frei.

• Identitätsverifizierung (IDV / KYC). Der Nachweis, dass hinter dem Handle ein echter, behördlich verifizierbarer Mensch steht – meist ein Foto-Ausweis plus ein Liveness-Selfie.
• Zahlungs- und Steuer-KYC. Das Steuerformular, die Zahlungsmethode und die Sanktionsprüfung, die Sie rechtlich brauchen, bevor Sie jemandem Geld überweisen dürfen.
• Strafrechtliche Hintergrundprüfungen. Eine formelle Auskunft aus dem Führungszeugnis, typischerweise mit mehrjährigem Rückblick.

Die meisten öffentlichen Programme nutzen nur die mittlere Kontrolle. Sie können jemanden eine Schwachstelle pseudonym melden lassen und Identitäts- und Steuerunterlagen erst dann verlangen, wenn eine Auszahlung ansteht. Diese Trennung – Teilnahme auf der einen, Geld auf der anderen Seite – ist das Scharnier, um das sich das gesamte Vertrauensmodell dreht. Sobald Sie Prüfung als drei Regler statt als einen Schalter begreifen, ergibt sich die Stufeneinteilung von selbst.

Wie leicht prüfen HackerOne und Bugcrowd tatsächlich?

Die etablierten Marktplätze prüfen standardmäßig bewusst leicht, denn ihr ganzer Pitch ist Skalierung. Die registrierte Community von HackerOne umfasst weit über eine Million, größtenteils pseudonyme Konten, und das ökonomische Argument für offene Bug Bounties lautet: viele Augen bei geringer Reibung.

Bei HackerOne können Forscher pseudonym teilnehmen. Eine rechtliche Identität ist nur nötig, um bezahlt zu werden: Die ID-Verifizierung läuft über Veriff, bleibt 12 Monate gültig und wird erst verfügbar, nachdem eine Forscherin mindestens eine gültige Meldung eingereicht hat. Um tatsächlich eine Belohnung zu erhalten, braucht sie zusätzlich ein genehmigtes Steuerformular und eine Zahlungsmethode. Strafrechtliche Hintergrundprüfungen sind optional und gelten nur für die erweiterte Stufe HackerOne Clear – durchgeführt von Checkr mit 7-jährigem Rückblick, alle zwei Jahre wiederholt und Forschern vorbehalten, die Schwellen für Verhalten und Reputation erfüllen (darunter 15.000 $ an Prämien über die gesamte Laufbahn). Rund 20 Länder verbieten die Prüfung vollständig.

Bugcrowd ist um eine Kerbe strenger geworden. Es verlangt inzwischen eine Identitätsverifizierung – ein Live-Selfie plus einen amtlichen Ausweis –, bevor eine Forscherin an einem Managed-Bug-Bounty-Programm teilnehmen darf, ob öffentlich oder privat. Hintergrundprüfungen bleiben allerdings ein Zusatz nur auf Einladung, für eine kleine, hoch vertrauenswürdige Gruppe. Die beiden Marktplätze sind also nicht identisch: HackerOne setzt aufs Pseudonym zuerst, mit auszahlungsgesteuertem KYC, während Bugcrowd bereits die Teilnahme hinter die IDV stellt.

Darüber legen beide dann eine Vertrauensreise. Bei Bugcrowd schalten Forscher öffentliche, dann private, dann eingeschränkte Engagements frei, wenn ihre Reputation wächst. HackerOne baut dieselbe Idee über sein Pentester-Programm auf, bei dem Tester Clear-verifiziert sein müssen, mehr als 3 Jahre Erfahrung und Top-Zertifizierungen mitbringen, eine strafrechtliche Prüfung bestehen und in ihren ersten drei Pentests eine Probezeit durchlaufen. Selbst die „leichten“ Plattformen bauen eine Leiter hin zur hochverlässlichen Arbeit.

Das schwere Ende: Synacks geschlossenes, vertraglich gebundenes Red Team

Synack sitzt am entgegengesetzten Pol und prüft schwer, vorab, bevor überhaupt jemand einen Kunden berührt. Es betreibt sein eigenes Synack Red Team (SRT) aus über 1.500 Forschern, und jedes Mitglied durchläuft einen fünfstufigen Prüfprozess, der sowohl Können als auch Vertrauenswürdigkeit bewerten soll. Historisch werden weniger als 10 % der Bewerber angenommen, und das Onboarding ist Berichten zufolge ein monatelanger Prozess.

Der tragende Unterschied ist nicht die Annahmequote. Es ist, dass SRT-Mitglieder vertraglich gebundene Fachkräfte sind, keine zufälligen Pseudonyme. US-Mitglieder werden als 1099-Independent-Contractors bezahlt (Mitglieder außerhalb der USA über ein W-8BEN) und verdienen an Missionen, gültigen Einreichungen, Patch-Verifizierung und Mentoring. Synack überwacht laufend das Online-Verhalten seiner Mitglieder und entfernt sie, wenn es geboten ist. Das ist der geschlossene, geprüfte Pool, den Behörden und stark regulierte Unternehmen einkaufen – und sie ist genau deshalb teuer, weil derart hartes Prüfen den Trichter zusammenschrumpfen lässt.

Dieser Handel ist der ganze Sinn. Schweres Prüfen ist eine Hürde für Ihren Pool, Ihr Tempo und Ihr Budget. Eine öffentliche Marketing-Website zu überprüfen ist genauso ein Missverhältnis wie einen Zahlungskern zu wenig zu prüfen. Genau deshalb lautet die Antwort nie „maximal prüfen“, sondern „nach Geltungsbereich prüfen“.

Die vierstufige Prüfleiter – und wie Sie Ihre wählen

Wie gründlich sollten Sie Bug-Bounty-Forscher prüfen? Stimmen Sie die Prüftiefe auf die Sensibilität dessen ab, was im Geltungsbereich liegt – anhand von vier Stufen: (1) reine Badge-Aufnahme, bei der jeder melden kann und keine Identität nötig ist, für öffentliche, wenig sensible Assets; (2) ID-verifizierte Auszahlungen, bei denen die Meldung pseudonym ist, aber Identitäts-, Steuer- und Sanktions-KYC vor der Zahlung verlangt werden – die Mainstream-Voreinstellung; (3) vertrauensbasierter Privatzugang, bei der Reputation eine Einladung verdient und ID-Verifizierung verpflichtend ist; und (4) hintergrundgeprüft oder vertraglich gebunden, mit strafrechtlicher Prüfung und namentlich benannten, vertraglich gebundenen Testern für den kronjuwelenartigen, regulierten oder klassifizierten Geltungsbereich.

Hier ist die Leiter als operative Entscheidungstabelle.

Lesen Sie die Tabelle nach Schadensradius, nicht nach Prestige. Stellen Sie pro Asset eine Frage: Wenn ein Angreifer innerhalb dieses Geltungsbereichs agierte, wie schlimm wäre der schlimmste plausible Tag? Ein pseudonymer Melder, der an Ihrer öffentlichen Doku-Site herumstochert, ist ein Problem der Stufe 0. Ein Fremder mit einem Pfad zu Ihrem produktiven Zahlungskern ist es nicht – und keine Prämienauszahlung rechtfertigt es, dort auf Identität zu verzichten.

Zwei praktische Anmerkungen. Erstens: Die meisten Startups betreiben mehr als eine Stufe gleichzeitig – ein breites öffentliches Stufe-1-Programm für den Perimeter und eine Stufe-2- oder Stufe-3-Einladung für alles nahe an sensiblen Daten. Zweitens: Stufen sind eine Progression, keine lebenslange Festlegung. Eine Forscherin, die auf Stufe 1 gut meldet, ist genau die, die Sie in Ihren privaten Stufe-2-Pool befördern. Reputation ist der Weg, auf dem gutgläubige Fremde sich Vertrauen verdienen.

Was Prüfung mit rechtlicher Absicherung zu tun hat: die Sullivan-Lektion

Hier ist der Teil, den Gründer übersehen. Prüfung ist nicht nur eine Sicherheitskontrolle; sie ist die Art, wie Sie im Nachhinein belegen, dass ein bestimmter Akteur innerhalb eines autorisierten Geltungsbereichs agierte. Und 2026 trägt dieser Nachweis echtes rechtliches Gewicht.

Im Verfahren United States v. Sullivan bestätigte der Ninth Circuit (Urteil eingereicht am 13. März 2025) die Verurteilung des früheren Chief Security Officer von Uber und stellte fest, dass „ohne Autorisierung“ nach dem Computer Fraud and Abuse Act (CFAA) im Moment des Zugriffs beurteilt wird. Nachträgliche Papiere – in diesem Fall ein als Bug Bounty verkleidetes NDA – können einen Zugriff, der bei seinem Geschehen unautorisiert war, nicht rückwirkend reinwaschen. Der zugrunde liegende Sachverhalt ist für sich genommen eine Mahnung: Ein Datenleck von 2016 legte Daten von 57 Millionen Nutzern und 600.000 Führerscheinnummern offen, eine Zahlung von 100.000 $ wurde über das Bug-Bounty-Programm geleitet, und Sullivan wurde letztlich wegen Behinderung der Justiz und Verschweigens einer Straftat verurteilt.

Die Lektion für einen Programm-Verantwortlichen ist präzise. Autorisierung muss vorab, schriftlich und an eine bekannte Partei gebunden hergestellt werden. Leichtes Prüfen erzeugt für sich genommen keine CFAA-Haftung, aber es macht es schwerer, später zu belegen, dass ein bestimmter Akteur innerhalb eines gutgläubigen, autorisierten Geltungsbereichs war. Safe-Harbor-Formulierungen und das Wissen, wer Ihre Forscherin ist, sind die zwei Hälften derselben Antwort auf die Frage „War dieser Zugriff legitim?“. Deshalb sind Ihr Scope-Dokument, Ihre Safe-Harbor-Bedingungen und Ihre Prüfstufe eine Entscheidung, nicht drei. (Zur Formulierungsseite davon siehe unseren Leitfaden zu Safe Harbor und rechtlichen Drohungen gegen Sicherheitsforscher und, falls Sie nach Europa verkaufen, das umfassendere Offenlegungsgebot des EU Cyber Resilience Act.)

Nichts davon ist Rechtsberatung. Kit gibt Ihnen den Ort, um Autorisierungs- und Scope-Formulierungen zu hinterlegen; lassen Sie den finalen Richtlinientext von einer Anwältin oder einem Anwalt prüfen.

Forscher-Prüfung ist Auftragnehmer-Prüfung unter anderem Namen

Das sauberste mentale Modell, das ein Gründer ohnehin schon hat, ist das des Auftragnehmers. Eine externe Forscherin mit einem Pfad zu Produktionszugang ist das sicherheitstechnische Äquivalent eines Auftragnehmers, den Sie in Ihre Systeme lassen. Und Sie skalieren die Genauigkeit dieser Prüfung mit ziemlicher Sicherheit bereits nach Rollensensibilität: Ein Designer, der eine Figma-Datei anfasst, bekommt eine leichtere Prüfung als eine Ingenieurin mit produktiven Zugangsdaten.

Wenden Sie dieselbe abgestufte Logik an. Identität, Reputation oder Referenzen und Hintergrundprüfungen, skaliert nach dem, was die Person erreichen kann, bilden sich fast eins zu eins von Ihrer Einstellungsrichtlinie auf die Forscherstufen ab. „Wer darf die Produktion berühren“ als bewusste Richtlinienentscheidung zu behandeln, statt als nachträglichen Einfall, ist die gesamte Disziplin. Es ist auch der Grund, warum Identitätsbetrug in der Talent-Lieferkette – wie die Welle des Einstellungsbetrugs durch nordkoreanische IT-Arbeiter – in dasselbe Gespräch gehört: Ein gefälschter Auftragnehmer und ein sanktionierter pseudonymer „Forscher“ sind dasselbe KYC-Versagen, nur in anderem Gewand.

Wo Krypto-Programme den Geldhebel offenlegen

Web3-Programme legen den Zahlungs-KYC-Regler am schärfsten offen, weil die Auszahlungen groß genug sind, dass die Geldfrage alles dominiert. Immunefi verlangt standardmäßig kein KYC; jedes Projekt legt seine eigene Richtlinie fest. Wenn KYC verlangt wird, wird es über Onfido erst dann eingeholt, wenn eine Meldung als gültig bestätigt ist – kurz vor einer Auszahlung, die in den sechs- oder siebenstelligen Bereich gehen kann.

Das ist das ganze Prinzip in einem Satz: KYC steuert das Geld, nicht die Teilnahme. Sie können die Aufnahme weit offen halten und trotzdem verweigern, auch nur einen Dollar zu bewegen, bis Sie genau wissen, wer ihn erhält und dass Sie rechtlich zahlen dürfen. „Darf melden“ von „darf bezahlt werden“ zu trennen ist das Entwurfsmuster – egal, ob Ihre Prämien 500 $ oder 5 Millionen $ betragen.

Ihre gewählte Stufe aufsetzen – ohne Enterprise-Ballast

Jeder Platzhirsch hat einen Anreiz, Sie zu seiner Kerbe zu drängen. Die Marktplätze verkaufen leicht-und-skaliert; Synack verkauft schwer-und-geschlossen. Niemand Neutrales veröffentlicht ein am Geltungsbereich ausgerichtetes „Wie viel Prüfung braucht Ihr Programm wirklich“-Rahmenwerk und gibt Ihnen dann das Werkzeug an die Hand, um die Stufe zu betreiben, die Sie wählen. Genau in dieser Lücke sitzt Kits CSIRT-Vertikale.

Kit ist selbstgehostete Infrastruktur, kein gemanagter Pool. Es liefert keine geprüften Forscher, wie Synack es tut. Was es Ihnen gibt, sind die Kontrollen, um jede Stufe zu betreiben und die Vertrauensentscheidungen selbst zu kodieren:

• Konfigurieren Sie das Programm mit Geltungsbereich und Safe Harbor vorab, damit „gutgläubig“ vor dem Zugriff definiert ist – die Sullivan-Lektion, operativ gemacht. Die Scope-Validierung hält Meldungen innerhalb der Grenze, die Sie veröffentlicht haben.
• Trennen Sie „darf melden“ von „darf bezahlt werden“. Forscherprofile und ein im Finanzhauptbuch verbuchter Auszahlungsablauf lassen Sie die Aufnahme offen halten (Stufe 0/1), während Geld hinter Identität und Freigabe gesteuert wird.
• Führen Sie eine Vertrauensreise nach dem Prinzip „verdien dir den Zugang“. Karma und Reputationssignale der Forscher lassen Sie starke Stufe-1-Melder in einen kuratierten, privaten Stufe-2-Geltungsbereich befördern.
• Beschränken Sie eine hochverlässliche Gruppe. Zugriffskontrollen auf Programmebene leiten sensiblen, kronjuwelenartigen Geltungsbereich an eine private, geprüfte Gruppe (Stufe 3).
• Sichten Sie durchgängig, unabhängig davon, wer gemeldet hat. Standardisierte Bewertung, Schweregrad-Vorschläge und Duplikatprüfungen sorgen dafür, dass ein Pseudonym und ein namentlich benannter Auftragnehmer dieselbe gründliche Behandlung erhalten.

Weil Kit auch eine Hiring-Vertikale besitzt, ist es einzigartig aufgestellt, um die Forscher-Prüfung als das externe Hacker-Pendant zur Auftragnehmer-Hintergrundprüfungsrichtlinie zu behandeln – eine Identitätsdisziplin über alle hinweg, die Ihre Systeme berühren können.

Die Prüf-Checkliste eines Gründers für Tag eins

Kopieren Sie diese, passen Sie sie an Ihren Geltungsbereich an, und Sie haben eine verteidigbare Ausgangsposition.

1. Inventarisieren Sie den Geltungsbereich nach Schadensradius. Listen Sie jedes Asset in Ihrem Programm auf und markieren Sie den schlimmsten plausiblen Tag, falls ein Angreifer darin agierte. Diese Markierung ist Ihre Stufe.
2. Setzen Sie den Perimeter standardmäßig auf Stufe 1. Öffentliche, nicht kronjuwelenartige Assets bekommen pseudonyme Meldung mit Identitäts-, Steuer- und Sanktions-KYC vor jeder Auszahlung.
3. Zäunen Sie die Kronjuwelen auf Stufe 2 oder 3 ein. Alles nahe an Zahlungen, PII, PHI oder Infrastrukturschlüsseln geht an einen Pool nur auf Einladung, ID-verifiziert oder hintergrundgeprüft.
4. Schreiben Sie die Autorisierung vorab fest. Veröffentlichen Sie Geltungsbereich und Safe-Harbor-Formulierungen, bevor Sie jemanden einladen, und binden Sie die Autorisierung an eine bekannte Partei. Lassen Sie sie juristisch prüfen.
5. Steuern Sie das Geld, nicht die Aufnahme. Senden Sie nie eine Auszahlung, bevor Identität, Steuerformular und Sanktionsprüfung durch sind. Verbuchen Sie jede Freigabe, Kürzung und Ablehnung im Finanzhauptbuch.
6. Bauen Sie einen Beförderungspfad. Lassen Sie starke Stufe-1-Melder sich über Reputation ihren Weg in Ihren privaten Pool verdienen, damit Ihre vertrauenswürdige Gruppe aus belegtem Verhalten wächst.

Prüfung ist ein Regler. Stellen Sie ihn auf die Sensibilität dessen ein, was im Geltungsbereich liegt, kodieren Sie Identität und Autorisierung fest genug, um eine „War dieser Zugriff legitim?“-Frage zu überstehen, und Sie bekommen die gutgläubigen Melder ohne das rechtliche Risiko. Wählen Sie Ihre Kerbe, veröffentlichen Sie Ihre Bedingungen und betreiben Sie das Programm, das beides durchsetzt. Für die Einrichtungsmechanik beginnen Sie mit So richten Sie ein Vulnerability-Disclosure-Programm ein und unserer Sicht auf Bug-Bounty-Prämienstufen und Forschervertrauen.