Zgłoszenia generowane przez AI: jak obsłużyć przeciążony VDP

Przy dużej liczbie zgłoszeń bug bounty sprawdź pięć obszarów: (1) filtrowanie wstępne wspierane przez AI, które pomaga wskazać brakujące dowody i niespójności do sprawdzenia przez człowieka, (2) limit częstotliwości zgłoszeń, żeby jeden podmiot nie zalał kolejki, (3) punktację reputacji uwzględniającą potwierdzony spam, (4) monitorowanie terminów odpowiedzi oraz (5) nagrody płacone za realny wpływ, a nie za liczbę zgłoszeń. W planie pracy uwzględnij także czas na weryfikację i naprawy.

Jeśli obsługujesz adres podany w security.txt, program ujawniania podatności (VDP) albo bug bounty, możesz otrzymywać więcej zgłoszeń, niż zespół potrafi sprawdzić. W opisywanym niżej przypadku curl weryfikacja zgłoszenia zajmowała od 30 minut do trzech godzin. Nie jest to uniwersalny czas dla każdego programu. Jeśli dopiero zaczynasz, opisaliśmy osobno uruchomienie VDP. Tutaj skupiamy się na obsłudze kolejki, która przekracza możliwości zespołu.

Zmiany programów curl, HackerOne i Nextcloud w 2026 roku

W pierwszej połowie 2026 roku kilka programów ograniczyło wypłaty lub przyjmowanie zgłoszeń. Powody nie były identyczne: oprócz fałszywych raportów problemem była też liczba prawdziwych podatności wymagających naprawy.

Dlaczego curl zakończył wypłacanie nagród

curl zamknął swój program bug bounty na HackerOne z dniem 31 stycznia 2026 roku. Jego twórca, Daniel Stenberg, opisywał obciążenie zespołu od miesięcy. We wpisie z lipca 2025 roku „Death by a thousand slops” donosił, że około 20% wszystkich zgłoszeń z 2025 roku to były śmieci AI, a tylko jakieś 5% zgłoszeń z 2025 roku okazało się prawdziwymi podatnościami (wyraźnie mniej niż w poprzednich latach) (źródło: daniel.haxx.se).

Weryfikacja angażowała znaczną część małego zespołu. Weryfikacja każdego zgłoszenia zajmowała trzem do czterech osób z siedmioosobowego zespołu bezpieczeństwa od 30 minut do mniej więcej trzech godzin, niemal w całości w ramach wolontariatu. Obciążenie utrzymywało się na początku kolejnego roku: w pierwszych 21 dniach 2026 roku curl dostał około 20 zgłoszeń i potwierdził zero podatności, w tym siedem zgłoszeń na HackerOne w jednym oknie 16 godzin (źródło: daniel.haxx.se; BleepingComputer).

Od 1 lutego 2026 roku curl kieruje zgłoszenia do prywatnego zgłaszania na GitHubie oraz na [email protected]. Nie wypłaca nagród. Stenberg wyjaśnił, że chciał „odebrać ludziom motywację do wysyłania bzdur”. Od 2019 roku w ramach programu wypłacono ponad 100 000 dolarów za 87 potwierdzonych podatności. Zakończenie wypłat nie oznaczało zamknięcia kanału zgłaszania podatności.

Skok HackerOne o 76% i zamrożenie Internet Bug Bounty

HackerOne wykonał dwa odrębne ruchy. Po pierwsze, jego Internet Bug Bounty (IBB), wspólny fundusz finansujący kluczowe zależności open source, wstrzymał przyjmowanie nowych zgłoszeń pod koniec marca 2026 roku, powołując się na liczbę podatności odkrywanych z pomocą AI przekraczającą możliwości ich naprawy (źródło: Privacy Guides; InfoWorld).

Po drugie, w kwietniu 2026 roku, równolegle z uruchomieniem płatnej usługi walidacji, HackerOne podał dane o liczbie zgłoszeń: liczba zgłoszeń podatności wzrosła o 76% rok do roku, bijąc rekord w marcu 2026 roku, podczas gdy około 25% znalezisk potwierdzono jako możliwe do wykorzystania. Ten odsetek pozostawał mniej więcej stały (źródło: komunikat prasowy HackerOne). Przy stałym odsetku potwierdzeń rośnie zarówno liczba potwierdzonych, jak i niepotwierdzonych zgłoszeń. Te dane nie pokazują szybszego procentowego wzrostu fałszywych raportów. Do maja 2026 roku IBB obniżył kwoty nagród na wszystkich poziomach ważności (źródło: The Register).

To problem całego ekosystemu

Inne projekty i platformy również informowały o rosnącej liczbie zgłoszeń:

Źródła: heise; Computing.co.uk; Cointelegraph via TradingView.

Nextcloud utrzymał kanał zgłoszeń, ograniczając wypłaty. To rozdzielenie pozwala nadal przyjmować informacje o podatnościach podczas zmiany zasad programu.

Dlaczego weryfikacja zajmuje tyle czasu

W użytecznym zgłoszeniu badacz pokazuje problem, warunki jego wystąpienia i wpływ na system. Zespół musi te informacje sprawdzić, niezależnie od tego, ile pracy włożył autor raportu.

AI może szybko wygenerować przekonujący opis, którego sprawdzenie nadal wymaga pracy inżyniera. Wygenerowane zgłoszenie potrafi przytoczyć wiarygodnie wyglądający numer CVE, opisać pozornie istniejącą funkcję i stanowczo podać kroki odtworzenia, choć żaden z tych szczegółów nie jest prawdziwy. Osoba oceniająca musi zajrzeć do kodu i sprawdzić warunki opisane w raporcie. Zarówno potwierdzenie, jak i wykluczenie podatności może być czasochłonne.

Dodatkową pracę powodują osobne zgłoszenia wariantów tego samego problemu, na przykład cross-site scriptingu z dwudziestoma różnymi danymi wejściowymi. Więcej raportów nie musi oznaczać więcej odrębnych podatności. Weryfikacja takich zgłoszeń może przeciążyć zespół (źródło: Pen Test Partners).

Dla zachowania proporcji warto pamiętać: VDP i bounty historycznie miały 60 do 80% nietrafionych zgłoszeń jeszcze przed erą AI (źródło: Yogosha). Weryfikacja nietrafionych raportów była więc kosztem programu już wcześniej. AI ułatwia zwiększanie ich liczby.

Pięć elementów obsługi dużej liczby zgłoszeń

Połącz kontrolę napływu zgłoszeń, wstępną ocenę i organizację pracy zespołu. Dobierz kolejność zmian do przyczyn przeciążenia.

1. Filtrowanie wstępne wspierane przez AI na wejściu. Wskazuj zgłoszenia wymagające sprawdzenia, np. z odwołaniami do zmyślonych funkcji lub sfabrykowanych CVE, bez proof-of-concept albo napisane szablonowym językiem.
2. Limity zgłoszeń i kontrola spamu. Limit w przesuwnym oknie czasowym, żeby jeden podmiot nie zalał kolejki w 16-godzinnym zrywie.
3. Reputacja oparta na sprawdzonych zgłoszeniach. Uwzględniaj potwierdzone przypadki spamu, zachowując możliwość korekty błędnej oceny.
4. Terminy odpowiedzi i rozwiązania. Ustal terminy odpowiedzi i informuj badaczy o opóźnieniach.
5. Nagrody za wpływ, nie za ilość. Płać według poziomu ważności, ustaw znaleziska informacyjne na zero i wymagaj konsolidacji, żeby za tysiąc identycznych zgłoszeń wypłacać jedną nagrodę.

1. Filtrowanie wstępne wspierane przez AI na wejściu

Wstępna ocena przez LLM może wskazać elementy wymagające sprawdzenia: odwołania do funkcji albo elementów kodu, które nie istnieją; CVE cytowane jako nowe, choć mają już kilka lat albo są zmyślone; ogólnikowe zalecenia naprawy; oraz brak jakiegokolwiek konkretnego, uruchamialnego proof-of-concept.

Kluczowa decyzja projektowa jest taka, że to ma być wsparcie, a nie automatyczne odrzucanie. Pierwsza ocena ma zawierać rekomendację („przepuść”, „do przejrzenia” albo „oznacz”) wraz z poziomem pewności. Człowiek wciąż rozstrzyga wszystko, co graniczne. Sprawdzaj również błędy modelu, żeby nie pomijać prawdziwych podatności.

2. Limity zgłoszeń i kontrola spamu

Limit częstotliwości ogranicza krótkie serie zgłoszeń od jednego nadawcy. Przykładowe pięć zgłoszeń na pięć minut nie zatrzyma jednak siedmiu raportów rozłożonych na 16 godzin, jakie opisał curl. Potrzebujesz też obserwacji obciążenia w dłuższym okresie, kontroli duplikatów i sposobu obsługi zgłoszeń od nowych badaczy. Dobierz limit tak, żeby utrudniał spam, a nie blokował uzasadnionych raportów.

3. Reputacja oparta na sprawdzonych zgłoszeniach

Reputacja może uwzględniać wcześniejsze potwierdzone zgłoszenia i spam. Opisz zasady punktacji i możliwość odwołania. Sam niski wynik ani brak historii nie powinny przesądzać o odrzuceniu nowego raportu. Ograniczenia dla osób wielokrotnie wysyłających spam stosuj na podstawie sprawdzonych przypadków.

4. Terminy odpowiedzi i rozwiązania

Pilnuj terminu potwierdzenia odbioru i kolejnych odpowiedzi. Opóźnienia bez wyjaśnienia utrudniają współpracę i mogą skłonić badacza do publicznego opisania sprawy. Takie sytuacje omawiamy w tekście gdy badacze idą do mediów. Ustaw osiągalny termin potwierdzenia, na przykład 72 godziny, oraz cele rozwiązania zależne od ważności. Sam licznik SLA nie zapewni odpowiedzi: przypisz odpowiedzialną osobę.

5. Nagrody za wpływ, nie za ilość

Powiąż nagrody z potwierdzonym wpływem podatności i jasno opisz zasady dotyczące duplikatów. Możesz ustawić stawkę 0 $ dla zgłoszeń informacyjnych, jeśli taką politykę przyjmuje program. Warianty tej samej przyczyny należy wspólnie ocenić, zamiast automatycznie wypłacać osobną nagrodę za każdy opis. Decyzja curl o całkowitym zakończeniu wypłat była dalej idącą zmianą, a nie tylko zmianą tabeli stawek.

Oceniaj dowody, również gdy badacz używa AI

Zakaz wszystkich zgłoszeń przygotowanych z pomocą AI może wykluczyć także wartościowe raporty. Sprawdzaj ich treść i dowody.

Joshua Rogers z pomocą AI znalazł w curl około 50 prawdziwych błędów. Każdy zweryfikował przed wysłaniem, zamiast przekazywać nieprzejrzany tekst modelu. Stenberg mówił wprost, że odpowiedzialne badania wspomagane przez AI są mile widziane; przekracza możliwości jego zespołu liczba niesprawdzonych raportów.

Dlatego zadanie tej procedury jest precyzyjne: filtruj po dowodach i trafności, a nie po tym, czy w grę wchodziło AI. Zgłoszenie z działającym proof-of-concept i odwołaniem do prawdziwego kodu przechodzi niezależnie od tego, czy szkic napisał człowiek, czy model. Zgłoszenie ze zmyślonymi funkcjami i bez PoC odpada z tego samego powodu, kto by go nie napisał. O użyteczności raportu decydują dowody.

Jak Kit przekłada tę procedurę na działanie

Moduł CSIRT w Kit udostępnia ustawienia wstępnej oceny, limitów zgłoszeń, reputacji, terminów i nagród. Zespół korzysta z tych ustawień podczas weryfikacji raportów.

Wstępna ocena AI zwraca rekomendację i poziom pewności. Człowiek powinien sprawdzić zarówno zgłoszenia oznaczone jako podejrzane, jak i jako wymagające oceny. Wynik modelu nie potwierdza podatności ani jej braku. Automatyczne przypisanie dyżurnemu trzeba włączyć w konfiguracji.

Dostosuj kolejkę do możliwości zespołu

Zmiany w programach z 2026 roku pokazują ograniczenia czasu i budżetu. Same filtry nie rozwiązują problemu naprawy potwierdzonych podatności. Warto sprawdzić, jaka część pracy wynika ze spamu, duplikatów, brakujących dowodów i rzeczywistych podatności wymagających naprawy.

Jeśli uruchamiasz program, zacznij od przewodnika po VDP. Jeśli już masz zaległości, ustal priorytety, poinformuj badaczy o terminach i dobierz limity do obciążenia. Oceniaj skuteczność filtrów także po tym, czy nie pomijają wartościowych raportów.

Rozpocznij bezpłatny okres próbny Kit, skonfiguruj przyjmowanie zgłoszeń i przypisz zespołowi odpowiedzialność za ich ocenę oraz odpowiedzi.