Jak bardzo powinieneś weryfikować badaczy bug bounty?

Weryfikacja badaczy bug bounty to pokrętło, nie przełącznik. Dopasowujesz to, ile chcesz wiedzieć o badaczu, do wrażliwości tego, do czego ma dostęp — na czterech poziomach: przyjmowanie zgłoszeń tylko za odznaką (każdy może zgłosić, bez potwierdzania tożsamości), wypłaty po weryfikacji tożsamości (zgłaszanie pseudonimowe, ale weryfikacja tożsamości plus kontrola podatkowa i sankcyjna, zanim ruszą pieniądze), prywatny program za progiem zaufania (zaproszenia zdobyte reputacją plus obowiązkowa weryfikacja tożsamości) oraz testerzy sprawdzeni pod kątem przeszłości lub zakontraktowani (prześwietlenie kryminalne i imiennie zakontraktowani testerzy dla zasobów krytycznych). Błąd, jaki popełniają założyciele, to przyjęcie domyślnego ustawienia platformy zamiast wyboru poziomu, którego naprawdę wymaga ich model zagrożeń.

Za chwilę zaprosisz obcych ludzi, żeby grzebali w produkcji. Pod każdym programem ujawniania podatności (VDP) leży pytanie proste i niewygodne: kogo dokładnie wpuszczam i ile muszę o nim wcześniej wiedzieć? To jest odpowiedź, poziom po poziomie.

Co „weryfikacja badacza” naprawdę oznacza

Weryfikacja to nie jedno działanie. To trzy odrębne mechanizmy kontroli, które można nakładać na siebie, a które założyciele bez przerwy ze sobą mieszają — duże platformy włączają każdy z nich niezależnie.

• Weryfikacja tożsamości (IDV / KYC). Potwierdzenie, że za pseudonimem stoi prawdziwy, możliwy do zweryfikowania urzędowo człowiek — zwykle zdjęcie dokumentu plus selfie z potwierdzeniem żywotności.
• KYC płatnicze i podatkowe. Formularz podatkowy, metoda płatności i kontrola sankcyjna, których zgodnie z prawem potrzebujesz, zanim wyślesz komuś pieniądze.
• Weryfikacja przeszłości kryminalnej. Formalne sprawdzenie rejestrów, zwykle z kilkuletnim wglądem wstecz.

Większość programów publicznych korzysta tylko ze środkowego mechanizmu. Możesz pozwolić komuś zgłosić błąd pseudonimowo, a tożsamości i papierologii podatkowej wymagać dopiero wtedy, gdy należna jest wypłata. To rozdzielenie — uczestnictwo po jednej stronie, pieniądze po drugiej — jest osią, wokół której obraca się cały model zaufania. Gdy raz zobaczysz weryfikację jako trzy pokrętła zamiast jednego przełącznika, podział na poziomy wychodzi naturalnie.

Jak lekko HackerOne i Bugcrowd w rzeczywistości weryfikują?

Główne platformy weryfikują domyślnie celowo lekko, bo cała ich propozycja to skala. Zarejestrowana społeczność HackerOne to grubo ponad milion, w większości pseudonimowych kont, a argument ekonomiczny za otwartym bug bounty brzmi: wiele oczu przy niskim progu wejścia.

Na HackerOne badacze mogą uczestniczyć pseudonimowo. Tożsamość prawna jest wymagana wyłącznie po to, żeby dostać wypłatę: weryfikacja tożsamości idzie przez Veriff, pozostaje ważna przez 12 miesięcy i staje się dostępna dopiero po tym, jak badacz przyśle co najmniej jedno prawidłowe zgłoszenie. Żeby faktycznie otrzymać nagrodę, badacz potrzebuje jeszcze zatwierdzonego formularza podatkowego i metody płatności. Weryfikacja przeszłości kryminalnej jest opcjonalna i otwiera dostęp tylko do rozszerzonego poziomu HackerOne Clear, prowadzonego przez Checkr z wglądem 7 lat wstecz, powtarzanego co dwa lata i zarezerwowanego dla badaczy, którzy przekroczą progi zachowania i reputacji (w tym 15 000 dolarów łącznych nagród). Około 20 krajów zakazuje tej kontroli całkowicie.

Bugcrowd poszedł o poziom dalej. Teraz wymaga weryfikacji tożsamości — selfie na żywo plus dokument wydany przez urząd — zanim badacz może zgłosić coś do programu Managed Bug Bounty, publicznego czy prywatnego. Weryfikacja przeszłości pozostaje jednak dodatkiem dostępnym tylko na zaproszenie, dla niewielkiej, bardzo zaufanej grupy. Obie platformy nie są więc identyczne: HackerOne stawia najpierw pseudonim, z KYC otwieranym przy wypłacie, a Bugcrowd warunkuje samo uczestnictwo weryfikacją tożsamości.

Obie nakładają następnie na to ścieżkę zaufania. Badacze Bugcrowd odblokowują kolejno zaangażowania publiczne, potem prywatne, potem ograniczone, w miarę jak rośnie ich reputacja. HackerOne buduje ten sam pomysł przez swój program Pentester, w którym testerzy muszą mieć weryfikację Clear, ponad 3 lata doświadczenia i czołowe certyfikaty, przejść prześwietlenie kryminalne oraz odbyć okres próbny w postaci pierwszych trzech pentestów. Nawet „lekkie” platformy budują drabinę prowadzącą do pracy o wysokim poziomie pewności.

Ciężki koniec: zamknięty, zakontraktowany red team Synacka

Synack siedzi na przeciwległym biegunie i weryfikuje ciężko, z góry, zanim ktokolwiek dotknie klienta. Prowadzi własny Synack Red Team (SRT) liczący ponad 1500 badaczy, a każdy członek przechodzi pięcioetapowy proces weryfikacji zaprojektowany tak, by ocenić zarówno umiejętności, jak i wiarygodność. Historycznie przyjmowanych jest mniej niż 10% kandydatów, a wdrożenie to podobno proces ciągnący się miesiącami.

Kluczowa różnica nie tkwi we wskaźniku przyjęć. Chodzi o to, że członkowie SRT to zakontraktowani specjaliści, nie przypadkowe pseudonimy. Członkowie z USA są opłacani jako niezależni wykonawcy na formularzu 1099 (spoza USA — przez W-8BEN) i zarabiają na misjach, prawidłowych zgłoszeniach, weryfikacji łatek i mentoringu. Synack na bieżąco monitoruje zachowanie członków w sieci i usuwa ich, gdy zachodzi taka potrzeba. To ta zamknięta, zweryfikowana pula, którą kupują administracja publiczna i mocno regulowane przedsiębiorstwa — a jest droga właśnie dlatego, że tak twarda weryfikacja zwęża lejek.

Na tym kompromisie polega cała sprawa. Ciężka weryfikacja to podatek nałożony na twoją pulę, tempo i budżet. Nadmierna weryfikacja publicznej strony marketingowej to takie samo niedopasowanie jak niedostateczna weryfikacja rdzenia płatności. Dlatego odpowiedzią nigdy nie jest „weryfikuj maksymalnie”, lecz „weryfikuj do zakresu”.

Czteropoziomowa drabina weryfikacji i jak wybrać swój poziom

Jak bardzo powinieneś weryfikować badaczy bug bounty? Dopasuj rygor weryfikacji do wrażliwości tego, co jest w zakresie, korzystając z czterech poziomów: (1) przyjmowanie zgłoszeń tylko za odznaką, gdzie każdy może zgłosić i tożsamość nie jest wymagana — dla zasobów publicznych o niskiej wrażliwości; (2) wypłaty po weryfikacji tożsamości, gdzie zgłaszanie jest pseudonimowe, ale KYC tożsamości, podatkowe i sankcyjne są wymagane przed płatnością — domyślne ustawienie głównego nurtu; (3) prywatny program za progiem zaufania, gdzie reputacja daje zaproszenie, a weryfikacja tożsamości jest obowiązkowa; oraz (4) sprawdzeni pod kątem przeszłości lub zakontraktowani, z prześwietleniem kryminalnym i imiennie zakontraktowanymi testerami dla zasobów krytycznych, regulowanych lub niejawnych.

Oto ta drabina jako operacyjna tabela decyzyjna.

Czytaj tabelę przez pryzmat skali szkód, a nie prestiżu. Zadaj jedno pytanie na zasób: gdyby ktoś działający w złej wierze operował wewnątrz tego zakresu, jak zły byłby najgorszy realny dzień? Pseudonimowy zgłaszający dłubiący w twojej publicznej stronie z dokumentacją to problem Poziomu 0. Obcy człowiek ze ścieżką do produkcyjnego rdzenia płatności — już nie, i żadna wypłata nagrody nie jest warta pominięcia tożsamości w tym miejscu.

Dwie praktyczne uwagi. Po pierwsze, większość startupów prowadzi więcej niż jeden poziom naraz: szeroki, publiczny program Poziomu 1 dla obwodu i zaproszenie na Poziom 2 lub 3 dla wszystkiego, co jest blisko wrażliwych danych. Po drugie, poziomy to progresja, a nie dożywotni wyrok. Badacz, który dobrze zgłasza na Poziomie 1, to dokładnie ten, którego awansujesz do swojej prywatnej puli Poziomu 2. Reputacja to sposób, w jaki obcy działający w dobrej wierze torują sobie drogę do zaufania.

Co weryfikacja ma wspólnego z pozostaniem w zgodzie z prawem: lekcja ze sprawy Sullivana

Oto część, którą założyciele przeoczają. Weryfikacja to nie tylko mechanizm bezpieczeństwa — to sposób, w jaki po fakcie udowadniasz, że dany podmiot działał wewnątrz autoryzowanego zakresu. A w 2026 roku ten dowód ma realną wagę prawną.

W sprawie United States v. Sullivan Dziewiąty Okręg (wyrok wydany 13 marca 2025) podtrzymał skazanie byłego dyrektora ds. bezpieczeństwa Ubera i orzekł, że w świetle Computer Fraud and Abuse Act (CFAA) „bez autoryzacji” ocenia się w momencie dostępu. Papierologia sporządzona później — w tym przypadku NDA przebrane za bug bounty — nie może wstecznie oczyścić dostępu, który był nieautoryzowany w chwili, gdy się wydarzył. Same fakty w tle są przestrogą: naruszenie z 2016 roku ujawniło dane 57 milionów użytkowników i 600 000 numerów praw jazdy, z płatnością 100 000 dolarów przeprowadzoną przez program bug bounty, a Sullivan został ostatecznie skazany za utrudnianie postępowania i zatajenie przestępstwa.

Lekcja dla właściciela programu jest precyzyjna. Autoryzację trzeba ustalić z góry, na piśmie i powiązać ze znanym podmiotem. Lekka weryfikacja sama w sobie nie tworzy odpowiedzialności z CFAA, ale utrudnia późniejsze wykazanie, że konkretny podmiot znajdował się wewnątrz działającego w dobrej wierze, autoryzowanego zakresu. Zapisy o safe harbor plus wiedza o tym, kim jest twój badacz, to dwie połówki tej samej odpowiedzi na pytanie „czy ten dostęp był legalny?”. Właśnie dlatego twój dokument zakresu, warunki safe harbor i poziom weryfikacji to jedna decyzja, a nie trzy. (O stronie redakcyjnej tego zagadnienia piszemy w przewodniku po safe harbor i groźbach prawnych wobec badaczy bezpieczeństwa, a jeśli sprzedajesz do Europy — w szerszym omówieniu obowiązku ujawniania z unijnego Cyber Resilience Act.)

Nic z tego nie jest poradą prawną. Kit daje ci miejsce, w którym umieścisz zapisy o autoryzacji i zakresie — ostateczną treść polityki niech przejrzy radca prawny.

Weryfikacja badaczy to weryfikacja wykonawców pod inną nazwą

Najczytelniejszy model myślowy, jaki założyciel już ma, to ten dotyczący wykonawców. Zewnętrzny badacz ze ścieżką do dostępu produkcyjnego to bezpieczeństwowy odpowiednik wykonawcy, którego wpuszczasz do swoich systemów. I niemal na pewno już skalujesz przyglądanie się wykonawcom według wrażliwości roli: projektant dotykający pliku w Figmie dostaje lżejszą kontrolę niż inżynier z poświadczeniami produkcyjnymi.

Zastosuj tę samą stopniowaną logikę. Tożsamość, reputacja lub referencje oraz weryfikacja przeszłości skalowane do tego, do czego dana osoba może sięgnąć, mapują się niemal jeden do jednego z twojej polityki rekrutacyjnej na poziomy weryfikacji badaczy. Traktowanie „kto może dotknąć produkcji” jako świadomej decyzji w ramach polityki firmy, a nie czegoś dorzuconego po fakcie, to cała ta dyscyplina. To także powód, dla którego oszustwo tożsamościowe w łańcuchu dostaw talentów — jak fala oszustw rekrutacyjnych z udziałem północnokoreańskich pracowników IT — należy do tej samej rozmowy: fałszywy wykonawca i objęty sankcjami pseudonimowy „badacz” to ta sama porażka KYC w innym wcieleniu.

Gdzie programy kryptowalutowe najdobitniej pokazują rolę pieniądza

Programy Web3 wydobywają pokrętło KYC płatniczego najostrzej, bo wypłaty są na tyle duże, że kwestia pieniędzy dominuje. Immunefi domyślnie nie wymaga KYC; każdy projekt ustala własną politykę. Kiedy KYC jest wymagane, zbiera się je przez Onfido dopiero po potwierdzeniu, że zgłoszenie błędu jest prawidłowe — tuż przed wypłatą, która może iść w sześcio- lub siedmiocyfrowe kwoty.

To cała zasada w jednym zdaniu: KYC warunkuje wypłatę pieniędzy, a nie uczestnictwo. Możesz trzymać przyjmowanie zgłoszeń szeroko otwarte i wciąż odmawiać ruszenia choćby jednego dolara, dopóki nie wiesz dokładnie, kto go odbiera i że masz prawo mu zapłacić. Oddzielenie „może zgłaszać” od „może dostać wypłatę” to wzorzec projektowy, niezależnie od tego, czy twoje nagrody wynoszą 500, czy 5 milionów dolarów.

Uruchamianie wybranego poziomu bez korporacyjnego narzutu

Każdy zasiedziały gracz ma interes w tym, by popychać cię ku swojemu poziomowi. Platformy sprzedają rozwiązania lekkie i skalowalne; Synack sprzedaje ciężkie i zamknięte. Nikt neutralny nie publikuje ram opartych na zakresie — „ile weryfikacji naprawdę potrzebuje twój program” — a potem nie wręcza ci narzędzi do prowadzenia dowolnego wybranego poziomu. W tej luce siedzi obszar produktowy CSIRT od Kit.

Kit to samodzielnie hostowana infrastruktura, a nie zarządzany tłum. Nie dostarcza zweryfikowanych badaczy tak, jak robi to Synack. Daje ci za to mechanizmy kontroli, żeby prowadzić dowolny poziom i samodzielnie zakodować decyzje o zaufaniu:

• Skonfiguruj program z zakresem i safe harbor z góry, żeby „dobra wiara” była zdefiniowana przed dostępem — lekcja ze sprawy Sullivana przełożona na praktykę. Walidacja zakresu utrzymuje zgłoszenia wewnątrz opublikowanej granicy.
• Oddziel „może zgłaszać” od „może dostać wypłatę”. Profile badaczy i księgowany przepływ wypłat pozwalają trzymać przyjmowanie zgłoszeń otwarte (Poziom 0/1), jednocześnie warunkując wypłatę weryfikacją tożsamości i zatwierdzeniem.
• Prowadź ścieżkę zaufania, na którą trzeba sobie zapracować. Karma badaczy i sygnały reputacji pozwalają awansować mocnych zgłaszających z Poziomu 1 do wyselekcjonowanego, prywatnego zakresu Poziomu 2.
• Ogranicz grupę o wyższym poziomie pewności. Kontrole dostępu na poziomie programu kierują wrażliwy, krytyczny zakres do prywatnej, prześwietlonej grupy (Poziom 3).
• Triażuj spójnie, niezależnie od tego, kto zgłosił. Ustandaryzowana ocena, sugestie poziomu ważności i sprawdzanie duplikatów oznaczają, że pseudonim i imienny wykonawca dostają tę samą rygorystyczną obsługę.

Ponieważ Kit ma też obszar rekrutacyjny, jest wyjątkowo dobrze umocowany, by traktować weryfikację badaczy jako bliźniaczy odpowiednik polityki weryfikacji przeszłości wykonawców, tyle że dla zewnętrznych hakerów — jedna dyscyplina tożsamości obejmująca wszystkich, którzy mogą dotknąć twoich systemów.

Checklist założyciela na dzień pierwszy

Skopiuj to, dostosuj do swojego zakresu i masz pozycję wyjściową, której da się bronić.

1. Zinwentaryzuj zakres według skali szkód. Wypisz każdy zasób w programie i zaznacz najgorszy realny dzień, gdyby ktoś działający w złej wierze operował wewnątrz niego. Ten znacznik to twój poziom.
2. Ustaw obwód domyślnie na Poziom 1. Publiczne, niekrytyczne zasoby dostają zgłaszanie pseudonimowe z tożsamością, podatkami i kontrolą sankcyjną przed jakąkolwiek wypłatą.
3. Odgrodź zasoby krytyczne na Poziomie 2 lub 3. Wszystko, co jest blisko płatności, danych osobowych, danych medycznych czy kluczy do infrastruktury, idzie do puli tylko na zaproszenie, po weryfikacji tożsamości lub przeszłości.
4. Spisz autoryzację z góry. Opublikuj zapisy o zakresie i safe harbor, zanim kogokolwiek zaprosisz, i powiąż autoryzację ze znanym podmiotem. Niech przejrzy to radca prawny.
5. Bramkuj pieniądze, nie przyjmowanie zgłoszeń. Nigdy nie wysyłaj wypłaty, dopóki nie przejdą tożsamość, formularz podatkowy i kontrola sankcyjna. Zapisz każde zatwierdzenie, obniżenie i odrzucenie w księdze.
6. Zbuduj ścieżkę awansu. Pozwól mocnym zgłaszającym z Poziomu 1 zapracować sobie na wejście do twojej prywatnej puli reputacją, żeby twoja zaufana grupa rosła z udowodnionego zachowania.

Weryfikacja to pokrętło. Ustaw je na wrażliwość tego, co jest w zakresie, zakoduj tożsamość i autoryzację na tyle ściśle, by przetrwały pytanie „czy ten dostęp był legalny?”, a dostaniesz zgłaszających działających w dobrej wierze bez ekspozycji prawnej. Wybierz swój poziom, opublikuj warunki i uruchom program, który egzekwuje jedno i drugie. Po mechanikę konfiguracji zacznij od jak uruchomić program ujawniania podatności oraz naszego ujęcia poziomów nagród bug bounty i zaufania do badaczy.