Jak ustalić i zmieniać nagrody w programie bug bounty

Przy ustalaniu nagród określ sposób oceny ważności, widełki kwot i warunki wypłaty. Opublikuj zakres programu oraz zasady zmian, a do każdego zgłoszenia zachowaj warunki, które mają do niego zastosowanie. Budżet można zmieniać, ale niejasne przeliczenie wcześniej zgłoszonej pracy prowadzi do sporów.

W maju 2026 roku zmiany nagród Internet Bug Bounty (IBB) wywołały krytykę, której część dotyczyła ich zastosowania do pracy już wykonanej. Wzrost liczby zgłoszeń, także tworzonych z pomocą AI, utrudnia planowanie budżetu. Warto oddzielić koszt oceny zgłoszeń od zasad wynagradzania prawidłowo wykrytych podatności.

Spór o obniżki Internet Bug Bounty

W maju 2026 HackerOne obniżył poziomy nagród Internet Bug Bounty o około 76–89% w przedstawionych niżej kategoriach, 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 wypłacono z niej ponad 1,5 mln dolarów, z podziałem 80/20 między wykrywanie a wsparcie w naprawie (źródło: InfoWorld / CSO).

Liczby

Poniższa tabela pokazuje opisywane wówczas kwoty według stanu na 18 maja 2026 r.:

Źródło: The Register, 21 maja 2026. Znalezisko o ważności Medium, warte kiedyś prawie dwa tysiące dolarów, według tej tabeli przynosiło 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”.

Jak zmiany wpływały na wcześniej zgłoszoną pracę

Budżet programu może okazać się zbyt mały. Nie rozstrzyga to zobowiązań wobec wcześniej zgłoszonej pracy. Część krytyki dotyczyła właśnie tego problemu. 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. Swoją ocenę opisał tak: „Obniżona wypłata to objaw. Ekonomia zgłaszania podatności zmienia się bardzo szybko”. Dla właściciela programu oznacza to potrzebę jasnego określenia, które zgłoszenia obejmuje zmiana.

Liczba i jakość zgłoszeń to odrębne problemy

AI może pomagać w znajdowaniu prawdziwych podatności, ale może też ułatwiać masowe wysyłanie niepotwierdzonych raportów. Ocena wiarygodnie brzmiącego zgłoszenia nadal wymaga pracy. Mierz liczbę raportów, ich przydatność i koszt obsługi; samo użycie AI nie rozstrzyga jakości.

curl: zgłoszenia i nagrody to nie to samo

Przykładem zmieniających się warunków jest curl. Maintainer Daniel Stenberg zamknął program ze skutkiem od 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). Stenberg wskazywał na koszt obsługi zgłoszeń, które nie potwierdzały rzeczywistych problemów.

Późniejsze relacje opisywały poprawę jakości raportów wspomaganych AI oraz ponowne korzystanie z HackerOne do obsługi zgłoszeń (The New Stack). Powrót do platformy zgłoszeniowej nie jest jednak równoznaczny ze wznowieniem wypłat nagród. Przy ocenie programu trzeba rozróżnić te dwie rzeczy.

Zmiana w GitHubie: gadżety zamiast gotówki za błędy o niewielkim 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).

Takie rozróżnienie pozwala osobno określić, co kwalifikuje się do nagrody pieniężnej, a za co program oferuje inne podziękowanie. Ważne, by badacz znał te zasady przed zgłoszeniem.

Jasno określ datę wejścia nowych zasad

Zmiana kwot i zmiana zasad dla już zgłoszonej pracy to odrębne decyzje. Komunikat powinien określać obie.

GitHub zmienił zasady na przyszłość i opublikował uzasadnienie, zanim ktokolwiek zgłosił cokolwiek na nowych warunkach. Badacz może przed wysłaniem zgłoszenia sprawdzić, czy dany rodzaj poprawki kwalifikuje się do nagrody pieniężnej. Cięcie IBB uderzyło w pracę już zgłoszoną i z przypisanym autorstwem według starych liczb. Taka różnica ma znaczenie dla oczekiwań uczestników.

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”. Zmiany dotyczące wcześniejszych zgłoszeń wymagają szczególnie jasnego uzasadnienia. Platforma bug bounty dla kryptowalut Immunefi uchwyciła zasadę przeciwną w tekście pod tytułem „The Bug Bounty Program Is Law”: warunki programu powinny określać zasady rozliczenia zgłoszenia. Skutki prawne konkretnej zmiany zależą od treści tych warunków i właściwego prawa.

Zachowuj warunki właściwe dla danego zgłoszenia i wyjaśniaj każdą zmianę, która wpływa na jego rozliczenie.

Poniższe kroki pomagają uporządkować wycenę i dokumentację. Sam zapis historii nie uniemożliwia zmiany warunków; potrzebne są też zasady podejmowania decyzji.

Cztery kroki do czytelnej tabeli nagród

Porównaj dane z podobnych programów, określ własne widełki, zachowuj wersje warunków i zapisuj rozliczenia. Osobno opisz podziękowania za zgłoszenia, które nie kwalifikują się do wypłaty.

1. Porównaj stawki i własne wypłaty

Zacznij od powiązania poziomów ważności z modelem punktacji, żeby „critical” znaczyło za każdym razem to samo. CVSS to typowy wybór; model dopasowany do kontekstu sprawdzi się, jeśli CVSS nie oddaje dobrze ryzyka dla twoich zasobów. Potem wyceń każdy poziom na podstawie danych z porównywalnych programów i własnego budżetu.

Przydadzą się dwa źródła danych:

• 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 około 42 000 $, a platforma wypłaciła łącznie 81 mln $ w opisywanym roku, o 13% więcej (źródło: BleepingComputer). Nie ma uniwersalnej kwoty za krytyczną podatność; ważne są zakres programu i skutki błędu.
• Twoja własna historia, gdy już jakąś masz. Oblicz medianę, średnią, minimum i maksimum rzeczywistych wypłat według poziomu ważności i typu podatności. Porównuj zgłoszenia o podobnym charakterze.

Używaj poziomów z widełkami (min i max na poziom ważności), a nie jednej kwoty bez opisanych wyjątków. Widełki pozwalają uwzględnić różnice między zgłoszeniami w tej samej kategorii. Opisz, od czego zależy wybór kwoty w danym przedziale. Takie rozwiązanie opisują m.in. Intigriti i Bug Bounty Community of Interest.

2. Opublikuj i wersjonuj warunki

W jednej polityce opublikuj tabelę nagród, zasoby objęte i nieobjęte programem, wykluczone typy podatności, zobowiązania SLA i treść safe harbor. Potem ją zwersjonuj i traktuj wersję, na którą badacz się zgodził w chwili zgłoszenia, jako wiążącą dla tego zgłoszenia.

Zachowanie wersji pozwala sprawdzić, jakie warunki miały zastosowanie. W komunikacie o zmianie podaj datę wejścia w życie i sposób traktowania wcześniejszych zgłoszeń. Samo wersjonowanie nie blokuje technicznie zmiany kwoty.

3. Dokumentuj nagrody i wypłaty

Zapisuj każdą przyznaną nagrodę i korektę wraz z datą oraz uzasadnieniem. Rejestr pozwala porównać wypłatę z przyznaną nagrodą i właściwymi warunkami. Jeśli korygujesz kwotę, zapisz powód i osobę odpowiedzialną.

Powód korekty powinien być zrozumiały dla osoby, której dotyczy.

4. Opisz podziękowania bez nagrody pieniężnej

Znaleziska ważne, lecz o niskim wpływie zasługują na uznanie. Można je docenić w osobny, dodatkowy sposób, np. punktami reputacji lub karmy, gadżetami albo wpisem w Hall of Fame. Takie podziękowanie nie zastępuje jednak obiecanej zapłaty.

Opisz, kiedy oferujesz punkty reputacji, gadżety lub wpis w Hall of Fame. Takie podziękowanie nie powinno być przedstawiane jako wykonanie wcześniejszej obietnicy wypłaty.

Ustawienia nagród w Kit

W module CSIRT można konfigurować minimalne i maksymalne kwoty dla poziomów ważności oraz analizować własną historię nagród. To dane danego programu, nie zbiór rynkowych benchmarków HackerOne.

Ocena zgłoszenia zapisuje sugerowane widełki. W procesie wypłaty obowiązują reguły i limity zależne od konfiguracji. Nie jest to jednak automatyczne zachowanie pełnej wersji polityki i tabeli z chwili wysłania zgłoszenia. Jeśli potrzebujesz takiej dokumentacji, ustal jej prowadzenie osobno.

Rejestr zdarzeń finansowych pomaga śledzić nagrody i wypłaty. Punkty reputacji oraz Hall of Fame służą innemu celowi: uznaniu wkładu badacza.

Sposoby obsługi przeciążonej kolejki zgłoszeń opisaliśmy w poradniku o triażu w VDP, a przygotowanie programu od początku w tekście o tym, jak uruchomić program ujawniania podatności. Tutaj skupiamy się na warunkach nagradzania.

FAQ

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

Zależy to od warunków programu i właściwego prawa. Przy projektowaniu zasad zachowuj warunki dotyczące wcześniejszych zgłoszeń, a zmiany na przyszłość ogłaszaj z jasną datą. Sam fakt, że platforma umożliwia edycję kwoty, nie rozstrzyga uprawnienia do jej obniżenia.

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

Nie ma uniwersalnego standardu; to kalkulacja ryzyka. Jako punkty odniesienia: 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, ale roczny budżet programu nie wyznacza stawki za pojedynczy krytyczny błąd (źródła: MSRC; BleepingComputer). Ustaw widełki min–max na poziom ważności, na podstawie porównywalnych stawek i własnej historii, a nie pojedynczą, sztywną liczbę.

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

Oceniaj możliwość odtworzenia problemu i jego wpływ, niezależnie od tego, jak napisano zgłoszenie. Osobno zarządzaj kolejką, limitami i kosztami oceny. Zmiany budżetu ogłaszaj zgodnie z zasadami programu, bez ukrytego przeliczania wcześniejszej pracy.

Przed publikacją tabeli

Sprawdź, czy potrafisz pokryć nagrody przy zakładanej liczbie poprawnych zgłoszeń. Opisz kryteria kwoty, sposób rozpatrywania rozbieżności i datę obowiązywania warunków. Zachowuj wersje oraz historię rozliczeń.

Rozpocznij bezpłatny okres próbny Kit, jeśli chcesz skonfigurować widełki i ewidencję nagród we własnym programie.