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

Spory o wypłaty bug bounty wybuchają wtedy, gdy program odmawia nagrody, obcina ją albo zwleka z wypłatą, nie opierając tej decyzji na regule, którą badacz mógł przeczytać z wyprzedzeniem. Najczęstsze zapalniki to: wolna naprawa bez zegara rozwiązania, decyzja „poza zakresem” wydana już po wydaniu łatki, wypłata poniżej reklamowanej macierzy i zmiany warunków programu działające wstecz. Lekarstwem nie jest płacenie więcej. Lekarstwem jest opublikowanie zegara i macierzy z góry, mierzenie czasu do naprawy względem nich oraz zapisywanie każdej decyzji o zatwierdzeniu, obniżeniu czy odmowie w księdze, którą da się audytować.

W czerwcu 2026 AMD zamieniło współpracującego badacza w publicznego krytyka, popełniając wszystkie cztery błędy naraz. To jest instrukcja, jak tego nie powtórzyć.

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

W lutym 2026 badacz Paul LaRosa (pseudonim „MrBruh”) zgłosił krytyczną lukę w narzędziu do automatycznych aktualizacji AMD. Updater pobierał listę aktualizacji po HTTPS, ale same pliki wykonywalne ściągał zwykłym HTTP, bez prawdziwej 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 przypisało lukę CVE (CVE-2026-40677, CVSS 4.0 base score 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ą.

Bohaterem tej historii nie jest sama luka. Historia jest taka, że wolny zegar plus nieprzejrzysta, podjęta po fakcie decyzja o wypłacie zamieniły badacza, który po cichu zgłosił realną lukę, w kogoś z megafonem i pretensją. Każdy element tego finału był wyborem procesowym i każdego dało się uniknąć.

Uwaga o tym, czego ten artykuł nie twierdzi: AMD nie miało prawnego obowiązku zapłaty i nikt nie zmusi firmy, by uznała dane zgłoszenie za mieszczące się w zakresie. Uczciwsza, węższa teza brzmi: zawiódł proces. Milczący zegar, nieudokumentowana decyzja o zakresie i niezaksięgowana wypłata — to one zamieniły odmowę nagrody w incydent reputacyjny.

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

Spory o wypłaty bug bounty rzadko dotyczą wyłącznie kwoty. Biorą się z rozjazdu między tym, co program reklamował, a tym, co naprawdę zrobił. Badacze tolerują niski pułap; nie tolerują przesuniętej bramki. Większość sporów wywołuje pięć zabójców zaufania:

• Brak zegara rozwiązania. Naprawa dryfuje miesiącami, bo nic nie odlicza czasu. Badacz tkwi w ciszy i zakłada złą wolę.
• „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 reklamowanej macierzy. Program obiecuje „od 1000 $ za Medium”, a płaci 200 $ bez słowa wyjaśnienia — odczuwaną niesprawiedliwością jest różnica, nie sama kwota.
• 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 wbrew jakiej regule postanowił.

Weterani bezpieczeństwa ostrzegają przed tym od lat. Jak argumentowali krytycy branży bug bounty — m.in. Katie Moussouris, Jonathan Leitschuh, Robert Graham i Tavis Ormandy — NDA i kupowanie milczenia podkopują model ujawniania; to przejrzystość sprawia, że program działa. Schemat w każdym sporze jest ten sam: decyzja nie była zakotwiczona w niczym, co badacz mógłby przeczytać z wyprzedzeniem.

Brak zegara rozwiązania sprawia, że naprawa po prostu dryfuje

Podatność bez terminu naprawy to podatność, której nikt nie jest właścicielem. Według badań nad SLA naprawy z Secure.com większość organizacji łata krytyczne podatności od 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ą. 124 dni AMD wypadły dokładnie w strefie zagrożenia, a ponieważ nie opublikowano żadnego zegara, nikt za to nie odpowiadał.

„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ę za wykraczającą poza zakres, decyzja o zakresie czyta się jak manewr unikania zapłaty — bo funkcjonalnie nim jest. Kwalifikuj zgłoszenia względem opublikowanego wcześniej dokumentu zakresu albo wcale nie powołuj się na zakres.

Wypłata poniżej reklamowanej macierzy

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 obcięcia i z długą zwłoką w wypłacie. Kwota może i dała się obronić. Cisza już nie. Obniżka bez udokumentowanego powodu względem publicznej macierzy zawsze wygląda na zaniżanie, nawet gdy nim nie jest.

Zmiany reguł działające wstecz

Zmiana warunków programu jest w porządku. Stosowanie nowych warunków do zgłoszeń złożonych według starych — już nie. Z chwilą przyjęcia zgłoszenia obowiązują je reguły, które obowiązywały w momencie zgłoszenia. Wszystko inne to zwabienie badacza obietnicą, której potem nie dotrzymujesz, a środowisko badaczy traktuje to dokładnie tak.

Jak szybko znaczy „wystarczająco szybko”? SLA rozwiązania według poziomu ważności

SLA rozwiązania to opublikowany, ustawiony per poziom ważności termin na wydanie naprawy, liczony od chwili potwierdzenia zgłoszenia. To on sprawia, że „124 dni” są obiektywnie nie do obrony, a nie kwestią opinii. Powszechnie cytowane cele branżowe są napięte:

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

Względem którejkolwiek z tych miar 124-dniowa naprawa krytycznej luki klasy RCE jest wielokrotnością celu. Konkretne granice poziomów ustalasz Ty. Liczy się to, żebyś je ustalił, opublikował na stronie polityki w kolejności od najgorszego i przypiął zegar do każdego potwierdzonego zgłoszenia — tak, by „przeterminowane” było statusem, który system sam pokazuje, a nie skargą, którą badacz musi złożyć.

Ile bounty powinno realnie płacić

Macierz nagród to opublikowana tabela widełek nagród per poziom ważności, zakotwiczona w realnych danych rynkowych, tak żeby kwoty były wyliczane, a nie wynegocjowywane w dół. Publiczne benchmarki dają Ci punkty zaczepienia:

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

To widełki, nie wyrocznia. Vulnerability Reward Program Google’a płaci znacznie więcej — krytyczne znaleziska lądują między 10 000 a 31 337 $ — a w skali całej platformy HackerOne wypłacił badaczom przez ostatnie 12 miesięcy około 81 milionów dolarów. Pokaż swoją macierz jako widełki, podaj platformę, względem której robiłeś benchmark, i nie kuś się o cytowanie jednej kanonicznej „średniej nagrody”. Sensem macierzy nie jest hojność. Jej sensem jest to, by badacz mógł oszacować swoją nagrodę, zanim kliknie „wyślij”, a Twoja ostateczna kwota wpadła w pasmo, które już widział.

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

Będziesz odmawiać. Poza zakresem, duplikat, informacyjne, ryzyko zaakceptowane — wszystko to są zasadne rozstrzygnięcia. Odmowa staje się sporem dopiero wtedy, gdy jest zaskoczeniem. Cztery praktyki chronią „nie” przed przerodzeniem się w publiczną awanturę:

1. Decyduj względem opublikowanej wcześniej reguły. Wskaż z nazwy dokument zakresu albo poziom macierzy, 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 obcinasz nagrodę, pokaż pasmo benchmarku, z którego wzięła się kwota. Udokumentowany powód bije hojną kwotę wypłaconą w ciszy.
3. Zachowaj uznanie. Odmowa wypłaty nie musi oznaczać wymazania zasług. Miejsce w Hall of Fame i punkty reputacji nic nie kosztują, a ratują dobrą wolę nawet wtedy, gdy o pieniądze trwa spór.
4. Daj możliwość odwołania. Jednostronne „nie” czyta się jak wyrok z urzędu. Decyzja, którą da się zaskarżyć, czyta się jako uczciwa, nawet gdy odpowiedź się nie zmienia.

Jeśli nie postawił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 spartaczonym ujawnieniu szczegółowo omawia mechanikę zaufania. Ten artykuł to dalszy ciąg — etap działania programu już po jego uruchomieniu: jak nie stracić badacza, gdy na szali leżą jednocześnie pieniądze i termin. (O rosnącym problemie z wolumenem zgłoszeń czytaj w śmieci AI zalewają triaż bug bounty.)

Jak Kit operacjonalizuje SLA rozwiązania i uczciwość wypłat

Wertykal CSIRT w Kit powstał niemal jako odpowiedź punkt po punkcie na wpadkę AMD: opublikuj zegar i macierz, mierz czas do naprawy względem nich i zapisuj każdą decyzję o wypłacie, tak by dało się ją obronić, a nie wyprzeć. Oto jak każdemu błędowi AMD odpowiada wbudowana funkcja.

Teza jest wąska i się broni: AMD nie straciło badacza dlatego, że błąd był trudny. Straciło go, bo żaden zegar nie chodził, a decyzję o wypłacie podjęto po ciemku, po fakcie, względem reguły, która nie istniała, gdy zgłaszał. SLA rozwiązania, które publikujesz i śledzisz, plus macierz nagród zakotwiczona w Twoich własnych danych o wypłatach i zapisana w księdze, zamieniają „poza zakresem, brak wypłaty” ze zdrady w przewidywalną, dającą się obronić decyzję. To, czy zapłacisz za dane zgłoszenie, wciąż zależy od Ciebie. Kit sprawia, że ta decyzja jest szybka, zakotwiczona w danych i audytowalna.

Wniosek: opublikuj zegar i macierz, zanim w ogóle powiesz „nie”

Każdy spór o wypłatę bug bounty sprowadza się do tej samej przyczyny: decyzji podjętej względem reguły, której badacz nigdy nie miał okazji zobaczyć. Opublikuj SLA rozwiązania uporządkowane według poziomu ważności. Zakotwicz macierz nagród w realnych danych benchmarkowych i też ją opublikuj. Przypnij zegar do każdego potwierdzonego zgłoszenia, żeby „przeterminowane” było stanem systemu, a nie skargą badacza. Zapisuj każde zatwierdzenie, obniżenie i odmowę w księdze, którą da się audytować. Zrób to, a odmowa stanie się czymś, czego badacz się spodziewał, co może zweryfikować i przy czym dalej będzie zgłaszał — zamiast czymś, co ląduje z Tobą na pierwszej stronie Tom’s Hardware.

Jeśli prowadzisz VDP albo płatny program bug bounty, a strona pieniędzy i zegara wciąż żyje w arkuszach i dobrej woli, to dokładnie tę lukę domyka moduł CSIRT w Kit. Rozpocznij darmowy okres próbny i ustaw swoje SLA oraz macierz nagród, zanim wpłynie następne krytyczne zgłoszenie.