Spory o wypłaty bug bounty: SLA i uczciwość w twoim VDP

Spór o nagrodę może dotyczyć zakresu programu, oceny podatności, kwoty lub czasu wypłaty. Badacz powinien znać zasady przed wysłaniem zgłoszenia, a później dostać uzasadnienie decyzji. Pomagają w tym opublikowana tabela nagród, terminy odpowiedzi i zapis zmian.

Sprawa AMD z czerwca 2026 roku pokazuje, dlaczego warto oddzielać potwierdzenie podatności od jej kwalifikacji do nagrody.

124 dni, a potem „poza zakresem”: spór o nagrodę z AMD

W lutym 2026 badacz Paul LaRosa (pseudonim „MrBruh”) zgłosił lukę o wysokim poziomie zagrożenia w narzędziu do automatycznych aktualizacji AMD. Updater pobierał listę aktualizacji po HTTPS, ale same pliki wykonywalne ściągał zwykłym HTTP, bez skutecznej weryfikacji podpisu. Atakujący w tej samej sieci mógł przeprowadzić atak man-in-the-middle i podsunąć ofierze złośliwy kod.

AMD łatało lukę przez 124 dni. Potem odmówiło wypłaty nagrody 10 000 $, uznając ataki man-in-the-middle na „opcjonalne narzędzia” za wykraczające poza zakres. Stało się tak, mimo że AMD opublikowało CVE-2026-40677 z oceną CVSS 4.0 7.7, High i publicznie wymieniło LaRosę z nazwiska we własnym biuletynie bezpieczeństwa. Ostateczna łatka dodała jedynie sprawdzanie CRC32, czyli sumę kontrolną integralności, a nie podpis kryptograficzny. Kilka serwisów donosiło też, że AMD zmieniło warunki programu, dodając wymóg pisemnej zgody przed ujawnieniem, a następnie zastosowało tę zmianę do sprawy LaRosy z mocą wsteczną.

Dla osoby prowadzącej program istotne są dwa pytania: kiedy oceniono zakres i jak wyjaśniono odmowę wypłaty. Samo nadanie numeru CVE nie oznacza automatycznie przyznania nagrody.

Ten artykuł nie rozstrzyga zobowiązań prawnych AMD wobec badacza. Zwraca uwagę na sposób komunikowania zakresu, terminów i decyzji o nagrodzie.

Dlaczego dochodzi do sporów o wypłaty bug bounty

Spory o wypłaty bug bounty rzadko dotyczą wyłącznie kwoty. Mogą wynikać z różnicy między zapowiedzianymi zasadami a praktyką programu. Jasno podany niski budżet stawia badacza w innej sytuacji niż obietnica, której program później nie wyjaśnia. Sprawdź pięć częstych źródeł nieporozumień:

• Brak terminu naprawy. Badacz nie wie, kiedy spodziewać się kolejnego kroku ani dlaczego praca się opóźnia.
• „Poza zakresem”, ogłoszone po wydaniu łatki. O kwalifikacji decyduje się z mocą wsteczną, gdy firma ma już poprawkę w ręku.
• Wypłata poniżej opublikowanej tabeli nagród. Program obiecuje „od 1000 $ za Medium”, a płaci 200 $ bez wyjaśnienia, dlaczego zastosowano taką kwotę.
• Zmiany reguł działające wstecz. Warunki zmieniają się w trakcie obsługi zgłoszenia, a nowe warunki nakłada się na zgłoszenie złożone według starych.
• Nieprzejrzyste, niezapisane decyzje. Nikt nie jest w stanie odtworzyć, kto, co, kiedy i na podstawie jakiej reguły postanowił.

Weterani bezpieczeństwa ostrzegają przed tym od lat. Katie Moussouris, Jonathan Leitschuh, Robert Graham i Tavis Ormandy krytykowali między innymi używanie NDA do ograniczania ujawniania podatności. Odwołanie do wcześniej opublikowanych zasad ułatwia wyjaśnienie konkretnej decyzji.

Termin naprawy i osoba odpowiedzialna

Przypisz do podatności osobę odpowiedzialną i termin kolejnego przeglądu. Według badań nad SLA naprawy z Secure.com większość organizacji usuwa krytyczne podatności w ciągu 60 do 150 dni. Tymczasem atakujący wykorzystują krytyczne luki już 5 dni po publicznym ujawnieniu, a około 60% naruszeń w 2024 wiązało się ze znaną, niezałataną podatnością. Dane z różnych badań nie wyznaczają bezpiecznego czasu naprawy konkretnej podatności. Termin dobierz do ryzyka i możliwości wdrożenia poprawki.

„Poza zakresem”, ogłoszone po wydaniu łatki

Zakres to obietnica, którą składasz, zanim nadejdzie zgłoszenie, a nie werdykt, do którego dochodzisz po zdobyciu łatki. Gdy program przyjmuje zgłoszenie, przypisuje CVE, wymienia badacza z nazwiska, a potem ogłasza tę samą sprawę jako wykraczającą poza zakres, badacz może uznać późną odmowę za próbę uniknięcia zapłaty. Przy ocenie wskaż konkretny punkt zakresu i wersję zasad obowiązującą dla zgłoszenia.

Wypłata poniżej opublikowanej tabeli nagród

Inny, szeroko komentowany spór dotyczył badacza, któremu zaproponowano 50 000 $ za krytyczny błąd przy deklarowanym przez program maksimum 500 000 $, bez szczegółowego wyjaśnienia różnicy i z długą zwłoką w wypłacie. Maksimum programu nie oznacza kwoty należnej za każde krytyczne zgłoszenie. Różnicę trzeba jednak wyjaśnić. Bez uzasadnienia badacz nie może sprawdzić, skąd wzięła się kwota niższa niż w opublikowanej tabeli.

Zmiany reguł działające wstecz

Zmiana warunków programu jest w porządku. Osobno trzeba ustalić, które zgłoszenia obejmuje nowa wersja. Zachowuj wersje zasad i jasno opisuj datę ich zastosowania. Nie przedstawiaj nowego wyłączenia jako warunku, który badacz znał wcześniej.

Jak ustalić terminy naprawy

SLA naprawy określa cel czasowy dla danego poziomu zagrożenia. Opisz także zdarzenie rozpoczynające odliczanie. Poniższe wartości są przykładami praktyk, nie uniwersalnym standardem:

Źródła: przewodnik po SLA naprawy Secure.com; podręcznik zarządzania podatnościami GitLab.

124 dni przekracza pokazany tu 30-dniowy cel dla poziomu High, przypisanego luce AMD. Nie oznacza to jednak, że AMD zobowiązało się do tego właśnie celu. W swoim programie opublikuj terminy, mierz ich dotrzymanie i wyjaśniaj opóźnienia.

Jak ustalić tabelę nagród

Tabela nagród określa przedziały kwot i kryteria ich przyznawania. Publiczne zestawienia pomagają w porównaniu budżetu, ale zakres programu i wpływ podatności nadal wymagają oceny:

Źródła: bug-bounties.as93.net (mediany HackerOne); wytyczne wypłat Bugcrowd.

Kwoty zależą od programu i rodzaju podatności. Vulnerability Reward Program Google’a w przytoczonym zestawieniu płaci więcej: krytyczne zgłoszenia mieszczą się między 10 000 a 31 337 $. W skali całej platformy HackerOne wypłacił badaczom przez ostatnie 12 miesięcy około 81 milionów dolarów. Pokaż tabelę nagród w postaci przedziałów, podaj platformę, z której stawkami porównywałeś swój program, i nie przedstawiaj jednej „średniej nagrody” jako standardu dla wszystkich programów. Tabela ma pomóc badaczowi ocenić możliwą nagrodę przed zgłoszeniem. Wyjaśnij też warunki, od których zależy ostateczna kwota.

Jak odmówić nagrody, nie tracąc badacza

Program może odmówić nagrody między innymi ze względu na zakres, duplikat lub ocenę wpływu. Uzasadnienie powinno wynikać z zasad i faktów dotyczących zgłoszenia:

1. Oprzyj decyzję na opublikowanej wcześniej regule. Wskaż z nazwy dokument zakresu albo poziom z tabeli nagród, na którym opiera się decyzja. Jeśli reguła nie istniała w chwili złożenia zgłoszenia, nie możesz jej użyć.
2. Pokaż dane. Gdy obniżasz nagrodę, pokaż przedział porównawczy, na którym opierasz kwotę. Wyjaśnij, jak ustalono kwotę dla tego zgłoszenia.
3. Odnotuj wkład badacza. Odmowa wypłaty nie musi oznaczać wymazania zasług. Hall of Fame i punkty reputacji pozwalają odnotować wkład badacza również wtedy, gdy trwa spór o pieniądze.
4. Daj możliwość odwołania. Opisz, gdzie złożyć dodatkowe dowody i kto ponownie oceni sprawę.

Jeśli nie uruchomiłeś jeszcze strony przyjmowania zgłoszeń, zacznij od naszego przewodnika jak uruchomić program ujawniania podatności. A jeśli martwi cię raczej relacja niż pieniądze, towarzyszący tekst gdy badacze idą do mediów po źle przeprowadzonym ujawnieniu szczegółowo omawia wpływ komunikacji na zaufanie. Ten artykuł dotyczy pracy po uruchomieniu programu: jak nie stracić badacza, gdy na szali leżą jednocześnie pieniądze i termin. (O rosnącym problemie z liczbą zgłoszeń czytaj w tekście jak zgłoszenia generowane przez AI obciążają wstępną ocenę bug bounty.)

Terminy, nagrody i odwołania w Kit

Moduł CSIRT pozwala prowadzić zgłoszenie razem z terminami i dokumentacją nagrody:

• SLA potwierdzenia i rozwiązania. Cele czasowe oraz ich stan są widoczne przy zgłoszeniu.
• Zakres i tabela nagród. Program publikuje zasady, ale kwalifikację konkretnego zgłoszenia ocenia zespół.
• Historia nagród. Własne wypłaty służą do obliczania statystyk. To dane twojego programu, nie rynkowa wycena każdej podatności.
• Księga finansowa. Zapisy nagród i rozliczeń pozwalają sprawdzić przebieg wypłaty. Nie zastępują uzasadnienia oceny technicznej.
• Odwołania. Badacz może przesłać uzasadnienie ponownego przeglądu, w granicach ustawionego limitu odwołań. Zespół zapisuje wynik. Przyjęcie odwołania nie zwiększa automatycznie nagrody.
• Uznanie wkładu. Karma i Hall of Fame pozwalają odnotować udział badacza. Zasady przyznawania uznania warto opisać osobno od zasad wypłaty.

Przed uruchomieniem programu ustal zakres, terminy i kryteria nagród. Przy każdej decyzji wskaż zastosowaną regułę oraz fakty ze zgłoszenia. Te zapisy ułatwiają przegląd sporu.

Rozpocznij darmowy okres próbny, żeby przygotować program i sprawdzić obsługę zgłoszenia w module CSIRT.