Poziomy nagród w bug bounty, którym badacze naprawdę ufają

Żeby ustawić poziomy nagród w bug bounty, którym badacze ufają, zrób cztery rzeczy: zmapuj poziomy ważności na model punktacji (CVSS albo własny, dopasowany do kontekstu), zakotwicz każdy poziom w danych benchmarkowych z widełkami min–max zamiast pojedynczej liczby, opublikuj i zablokuj tabelę oraz zakres tak, żeby nie dało się ich po cichu zmienić po zgłoszeniu, i zarezerwuj gotówkę na realny wpływ, jednocześnie doceniając pracę o niskim wpływie w osobnym torze. To, co niszczy zaufanie, to nie zbyt niskie stawki. To zmiana wyceny ukończonej pracy po tym, jak badacz już wszystko zgłosił, błąd naprawiono, a autorstwo przypisano według starych liczb.

To rozróżnienie jest sednem pierwszej połowy 2026 roku. W maju HackerOne wziął siekierę do Internet Bug Bounty (IBB), tnąc nagrody na każdym poziomie ważności — a spora część fali krytyki dotyczyła momentu, nie kwoty. Jeśli prowadzisz program ujawniania podatności (VDP) albo młody program bug bounty i patrzysz, jak zgłoszenia generowane przez AI piętrzą się w skrzynce, boisz się dwóch rzeczy naraz: że zatoniesz w śmieciach, i że ustawisz liczby, które później będziesz musiał ściąć, podpalając przy tym swoją reputację w społeczności badaczy. Obie obawy są uzasadnione. Tylko jedną z nich rozwiązuje cięcie nagród.

HackerOne ściął nagrody w bug bounty nawet o 89% za pracę, którą badacze już wykonali

W maju 2026 HackerOne obniżył poziomy nagród Internet Bug Bounty mniej więcej o 76–89% na całej linii, a potem wstrzymał program, oceniając kolejne korekty. IBB to wspólna pula, z której wypłaca się nagrody za podatności w kluczowych zależnościach open source — od 2012 roku rozdysponowała ponad 1,5 mln dolarów, z podziałem 80/20 między wykrywanie a wsparcie w naprawie (źródło: InfoWorld / CSO).

Liczby

To nie były drobne korekty. Oto tabela poziomów „przed kontra po”, według stanu na 18 maja 2026:

Źródło: The Register, 21 maja 2026. Znalezisko o ważności Medium, warte kiedyś prawie dwa tysiące dolarów, dziś przynosi mniej niż trzysta. HackerOne tłumaczy to tak, że IBB to „unikalny, dynamiczny program, w którym poziomy nagród automatycznie dostosowują się do wkładu aktywnie uczestniczących sponsorów”. O przyczynie po stronie AI firma powiedziała: „Badania wspierane przez AI poszerzają wykrywanie podatności w całym ekosystemie, zwiększając zarówno zasięg, jak i tempo. Równowaga między liczbą znalezisk a zdolnością do ich naprawy w open source znacząco się przesunęła”.

Dlaczego to historia o zaufaniu, a nie o budżecie

Programowi wolno wyczerpać pieniądze. Programowi wolno uznać, że dany poziom był przeszacowany. Badacze zareagowali na to, że zmiana objęła pracę, która była już skończona. Jak ujął to badacz bezpieczeństwa Jakub Ciolek: „Problem z zaufaniem polega na tym, że zmianę zastosowano de facto długo po tym, jak praca została wykonana, błąd naprawiony, a autorstwo publicznie przypisane — przy zupełnie innym oczekiwaniu” (źródło: The Register).

Jeden z badaczy dostał wypłatę 297 $ wobec wcześniejszego, dużo wyższego oczekiwania. Sam Ciolek wciąż czekał na zapłatę za podatności w Argo CD zgłoszone jesienią 2025, gdy weszły nowe poziomy. Jego diagnoza szerszego momentu to teza całego tego artykułu: „Obniżona wypłata to objaw. Ekonomia zgłaszania podatności zmienia się bardzo szybko”. Wniosek nie brzmi przestań płacić. Brzmi zmieniaj zasady do przodu, nie wstecz.

Prawdziwa presja: AI nie obniżyło jakości błędów, podniosło liczbę zgłoszeń

Uczciwe odczytanie 2026 roku jest takie: presja śmieci AI jest realna i udokumentowana, ale trwałym problemem jest wolumen, a nie samo AI. Programy nie toną dlatego, że AI pisze słabe błędy. Toną dlatego, że AI pisze wiele zgłoszeń, a obalenie jednego wiarygodnego, lecz fałszywego wciąż kosztuje doświadczonego inżyniera realny czas.

Zwrot akcji w curl: ubić program, a potem go wskrzesić

curl to najczystszy udokumentowany przypadek — i działa w obie strony. Maintainer Daniel Stenberg zamknął program z dniem lutego 2026, mówiąc: „Obecna lawina zgłoszeń mocno obciąża zespół bezpieczeństwa curl i to próba ograniczenia szumu” (źródło: The Register, 21 stycznia 2026). Przez lata zgłoszenia do curl wspierane przez AI nie wykryły praktycznie niczego prawdziwego w erze śmieci.

Potem trend się odwrócił. Do marca 2026 curl wrócił na HackerOne, bo jakość zgłoszeń AI poprawiła się na tyle, że „prawie wszystkie” jego teraz-dobre zgłoszenia były wspierane przez AI — mimo że surowy wolumen w skali roku mniej więcej się podwoił (źródło: The New Stack). Wniosek: AI nie jest na trwałe wrogiem jakości zgłoszeń. Trwałą zmianą jest wolumen. Twoja struktura nagród musi przetrwać skrzynkę zalaną zgłoszeniami, nie karząc przy tym badaczy, którzy dostarczają prawdziwe błędy.

Cichszy ruch GitHuba: gadżety zamiast gotówki za błędy o niskim wpływie

15 maja 2026 GitHub ogłosił, że znaleziska ważne, lecz o niskim wpływie, będą nagradzane uznaniem zamiast wypłatą: „Zgłoszenia, które nie wykazują istotnego wpływu na bezpieczeństwo, ale prowadzą do poprawki w kodzie lub dokumentacji, będą doceniane gadżetami GitHuba, a nie wypłatą nagrody”. Uzasadnienie było jednoznaczne: „Wolimy, żeby badacze inwestowali czas w głębsze badania o dużym wpływie i byli za nie odpowiednio wynagradzani, niż żeby optymalizowali pod wolumen znalezisk o niskim ryzyku” (źródło: GitHub Blog).

To ten sam instynkt ekonomiczny co przy cięciu IBB: zarezerwuj gotówkę na realny wpływ, stłum zachętę do wolumenu. Ale odebrano to zupełnie inaczej — i ta różnica jest całą grą.

Jak wygląda „dobrze”: różnica między GitHubem a IBB

Ruch konstruktywny i ten kontrowersyjny są mechanicznie podobne. Oba zmniejszają to, co zarabia praca o niskim wpływie. Różnica tkwi w momencie i uprzedzeniu.

GitHub zmienił zasady na przyszłość i opublikował uzasadnienie, zanim ktokolwiek zgłosił cokolwiek na nowych warunkach. Badacz, który zgłasza coś dziś, wie, że znalezisko klasy „poprawka w dokumentacji” daje gadżety, nie gotówkę — i godzi się na to świadomie. Cięcie IBB uderzyło w pracę już zgłoszoną i z przypisanym autorstwem według starych liczb. Ten sam kierunek, odwrotny efekt dla zaufania.

To nie jest nowa lekcja. Jeszcze w 2020 Bountysource ogłosił, że „zatrzyma” nieodebrane nagrody poprzez cichą zmianę regulaminu, wycofał się po fali krytyki i patrzył, jak projekty takie jak elementary OS publikują wpisy zatytułowane „Goodbye, Bountysource”. Wsteczne zmiany umowy o nagrodę to wzorcowy ruch niszczący zaufanie. Platforma bug bounty dla kryptowalut Immunefi uchwyciła zasadę przeciwną w tekście pod tytułem „The Bug Bounty Program Is Law”: opublikowana strona programu jest wiążąca, a projekt nie może wstecznie renegocjować zgłoszenia, które już na jej podstawie złożono.

Oczekiwanie w chwili zgłoszenia musi być równe oczekiwaniu w chwili wypłaty. Wszystko inne podlega negocjacji. To jedno — nie.

Dlatego poniższy framework tak naprawdę nie dotyczy liczb. Dotyczy tego, jak sprawić, by twoje opublikowane warunki były strukturalnie niezdolne do zdradzenia badacza po fakcie.

Jak ustawić poziomy nagród w bug bounty, które przetrwają zalew śmieci AI

Ustaw poziomy w czterech krokach: zakotwicz je w danych, opublikuj i zablokuj, spraw, by każda wypłata była audytowalna, i nagradzaj wysiłek uznaniem, a nie ukrytą obniżką stawki. Żaden z tych kroków nie wymaga budżetu rzędu HackerOne. Wymagają dyscypliny — i to one odróżniają program, któremu badacze ufają, od kolejnego ostrzegawczego nagłówka.

Krok 1: Zakotwicz poziomy w danych, nie w przeczuciach

Zacznij od zmapowania poziomów ważności na model punktacji, żeby „critical” znaczyło za każdym razem to samo. CVSS to typowy wybór; model dopasowany do kontekstu sprawdzi się, jeśli twoje zasoby nie wpasowują się czysto w CVSS. Potem wyceń każdy poziom na podstawie realnych danych o rozkładzie, a nie okrągłej liczby, którą zgadłeś.

Liczą się dwa punkty zakotwiczenia:

• Zewnętrzne benchmarki, zwłaszcza gdy zaczynasz. Opublikowane tabele nagród Microsoftu sięgają od 500 do 30 000 $ za aplikacje i wdrożenia on-prem oraz od 1 250 do 19 500 $ za M365, a w latach 2024–2025 wypłacono rekordowe 17 mln $ (źródło: MSRC). W całym HackerOne średnia roczna wypłata na aktywny program to mniej więcej 42 000 $, a platforma wypłaciła łącznie 81 mln $ w ciągu minionego roku — o 13% więcej (źródło: BleepingComputer). Powszechna branżowa zasada kciuka mówi, że organizacje są gotowe płacić ponad 7 000 $ za krytyczną podatność — choć nie ma tu uniwersalnego standardu.
• Twoja własna historia, gdy już jakąś masz. Mediana, średnia, minimum i maksimum, które faktycznie wypłaciłeś na poziom ważności i na typ podatności, mówią, gdzie naprawdę leży rozkład — więc kolejny poziom wycenisz na podstawie dowodów, a nie cięcia na całej linii.

Używaj poziomów z widełkami (min i max na poziom ważności), a nie pojedynczej, kruchej liczby. Widełki pozwalają nagrodzić wyjątkowe krytyczne znalezisko górą pasma, a marginalne dołem — bez przepisywania tabeli. To praktyka rekomendowana zarówno przez Intigriti, jak i Bug Bounty Community of Interest, i dokładnie tego brakuje cięciom na całej linii w stylu IBB.

Krok 2: Opublikuj i zablokuj warunki oraz zakres

Spisz matrycę nagród, zasoby w zakresie i poza zakresem, wykluczone typy podatności, swoje zobowiązania SLA i zapisy o safe harbor w jedną opublikowaną politykę. Potem ją zwersjonuj i traktuj wersję, na którą badacz się zgodził w chwili zgłoszenia, jako wiążącą dla tego zgłoszenia.

To strukturalna odpowiedź na zarzut wobec IBB. Jeśli warunki są opublikowane i zablokowane w chwili zgłoszenia, nie istnieje mechanizm, którym skończona praca dostałaby po cichu nową wycenę. Badacz godzi się na znaną umowę. Jeśli chcesz zmienić umowę, zmieniasz ją dla przyszłych zgłoszeń i to ogłaszasz — w stylu GitHuba.

Krok 3: Spraw, by każda wypłata była audytowalna

Każda nagroda i każda korekta powinna być jawnym, zalogowanym i możliwym do obrony zdarzeniem ze znacznikiem czasu i powodem. Audytowalna księga finansowa robi dwie rzeczy. Dowodzi badaczowi, że kwota, którą dostał, odpowiada poziomowi, który mu obiecano. A w tych rzadkich sytuacjach, gdy naprawdę korygujesz nagrodę, pokazuje, że korekta była świadomą, zapisaną decyzją, a nie nieprzejrzystym automatycznym przeszacowaniem.

To formuła IBB „poziomy nagród automatycznie się dostosowują” jest dokładnie tym, czemu zapobiega księga. Automatyczne i niewidoczne to to, co eroduje zaufanie. Świadome i zalogowane to to, co je zachowuje — nawet gdy liczba się zmienia.

Krok 4: Nagradzaj wysiłek uznaniem, a nie ukradkową obniżką stawki

Znaleziska ważne, lecz o niskim wpływie zasługują na uznanie. Właściwy sposób, by je dać, to osobny, dodatkowy tor uznania: punkty reputacji albo karmy, gadżety, wpis w Hall of Fame. Niewłaściwy to ubranie obniżki gotówki w „uznanie” za pracę, która powinna zostać opłacona.

Polityka GitHuba „gadżety za niski wpływ” to wersja czysta, bo jest ogłoszona z wyprzedzeniem i działa obok gotówki za błędy o dużym wpływie, nigdy nie zastępując obiecanej gotówki za pracę już zgłoszoną. Uznanie jest uzupełnieniem twoich zablokowanych poziomów gotówkowych. Nigdy nie jest furtką do zmiany wyceny.

Jak zrobić to w Kit

Zestaw narzędzi CSIRT w Kit jest zbudowany dokładnie wokół tych czterech nawyków — i o to chodzi: dyscyplinę wymusza narzędzie, a nie dobre intencje. Dla jasności: Kit to młody produkt do zarządzania programami, a nie marketplace z wolumenem wypłat czy zbiorem benchmarków HackerOne. Wyróżnikiem jest struktura, którą narzuca, a to właśnie do struktury sprowadza się w dużej mierze zaufanie.

• Poziomy zakotwiczone w benchmarkach. Agreguj własne historyczne nagrody (mediana, średnia, min, max, niedawne przykłady) filtrowane po poziomie ważności i typie podatności, żeby wyceniać każdy poziom na podstawie realnych danych o rozkładzie i móc pokazać badaczowi medianę dla jego klasy błędu. Nowe programy zaczynają od zewnętrznych benchmarków, jak opublikowane pasma Microsoftu, dopóki nie zbudują własnej historii.
• Poziomy z widełkami, opublikowane. Skonfiguruj matrycę nagród jako min i max na poziom ważności w zakresie informational, low, medium, high, critical oraz poziomu super-critical, a potem opublikuj ją razem z zakresem, SLA i warunkami safe harbor jako zwersjonowaną politykę, na którą badacze godzą się w chwili zgłoszenia.
• Audytowalna księga finansowa. Każde zatwierdzenie, korekta i wypłata nagrody to typowane, zalogowane zdarzenie finansowe, filtrowalne po zgłoszeniu i dacie, tak by wypłata odpowiadała obietnicy, a każda korekta była zapisaną decyzją, a nie cichym przeszacowaniem.
• Osobny tor karmy. Uznanie bezgotówkowe działa obok zablokowanych poziomów gotówkowych z ustalonymi, przejrzystymi presetami, tak by znalezisko ważne, lecz o niskim wpływie zostało docenione, a nikt nie przebierał obniżki gotówki za podziękowanie.

Sposoby na utrzymanie programu przy życiu, gdy skrzynka się przelewa, rozłożyliśmy na części w poradniku o triażu w VDP, a stawianie programu od zera w tekście o tym, jak uruchomić program ujawniania podatności. Ten artykuł to warstwa projektowania nagród nałożona na oba.

FAQ

Czy program bug bounty może zmienić nagrody po zgłoszeniu?

Może, ale nie powinien. Fala krytyki wobec IBB w maju 2026 wynikała mniej z rozmiaru cięcia, a bardziej z tego, że objęło ono pracę już zgłoszoną, naprawioną i z przypisanym autorstwem według starych poziomów. Wzorzec możliwy do obrony, pokazany przez GitHuba, to zmiana nagród wyłącznie na przyszłość, z opublikowanym uprzedzeniem, tak by badacze świadomie godzili się na nowe warunki. Traktuj opublikowaną stronę programu jako wiążącą dla każdego zgłoszenia złożonego na jej podstawie.

Ile powinienem płacić za krytyczny błąd w bug bounty?

Nie ma uniwersalnego standardu; to kalkulacja ryzyka. Jako orientacyjne punkty zakotwiczenia: Microsoft płaci do 30 000 $ za najwyższej klasy znaleziska aplikacyjne, średni program HackerOne płaci około 42 000 $ rocznie w sumie na wszystkich poziomach, a powszechna zasada kciuka każe organizacjom płacić ponad 7 000 $ za krytyczny błąd (źródła: MSRC; BleepingComputer). Ustaw widełki min–max na poziom ważności, zakotwiczone w tych benchmarkach i twojej własnej historii, a nie pojedynczą, sztywną liczbę.

Jak radzić sobie ze zgłoszeniami bug bounty generowanymi przez AI?

Nie tnij nagród, żeby je zniechęcić — to karze badaczy, którzy dostarczają prawdziwe błędy. Trwałym problemem jest wolumen, nie AI. curl udowodnił, że jakość zgłoszeń AI potrafi przejść od bezwartościowej do „prawie wszystkie dobre” w ciągu roku. Wolumen ogarniaj triażem (filtrowanie, rate limiting, ocena reputacji, ochrona SLA), a projektowanie nagród prowadź tak, by płacić za realny wpływ i osobno doceniać pracę o niskim wpływie — tak by zachęta nagradzała jakość, a nie liczbę zgłoszeń.

Podsumowanie

Gdy AI zalewa twoją skrzynkę, instynkt podpowiada, by ochronić budżet, tnąc to, ile płacisz. IBB pokazuje, dokąd to prowadzi, gdy cięcie uderza w skończoną pracę: w dziurę w wiarygodności, której żadne pieniądze szybko nie zasypią. Trwała odpowiedź jest strukturalna. Zakotwicz poziomy w realnych danych, opublikuj i zablokuj warunki oraz zakres, loguj każdą wypłatę, żeby korekty były świadome i widoczne, i nagradzaj wysiłek uznaniem, które stoi obok gotówki, a nie ją zastępuje. Zrób to, a twój VDP zachowa wiarygodność, gdy nadejdzie fala AI, zamiast stać się kolejnym ostrzegawczym nagłówkiem.

Jeśli projektujesz matrycę nagród, którą chcesz opublikować dziś i nie żałować jej za pół roku, rozpocznij darmowy okres próbny Kit i skonfiguruj benchmarkowany, zablokowany, audytowalny program od samego początku.