Wprowadzenie do problemu / definicja
Google tymczasowo wstrzymał przyjmowanie części zgłoszeń do programu Open Source Software Vulnerability Rewards Program (OSS VRP). Decyzja jest odpowiedzią na gwałtowny wzrost raportów o niskiej jakości, tworzonych lub wspomaganych przez narzędzia AI, które utrudniają skuteczny triage i wydłużają czas identyfikacji realnych podatności.
To ważny sygnał dla rynku bug bounty i społeczności bezpieczeństwa. Automatyzacja może zwiększać skalę analiz, ale bez odpowiedniej walidacji technicznej prowadzi również do wzrostu szumu informacyjnego i obciąża zespoły odpowiedzialne za weryfikację zgłoszeń.
W skrócie
- Google czasowo zawiesił część zgłoszeń w ramach OSS VRP.
- Powodem jest duża liczba raportów generowanych przez AI, które nie spełniają wymagań jakościowych.
- Zawieszenie nie obejmuje zgłoszeń związanych z kompromitacją łańcucha dostaw ani wcześniej otwartych spraw.
- Firma zapowiedziała przebudowę programu i publikację dalszych informacji w pierwszym kwartale 2027 roku.
Kontekst / historia
OSS VRP uruchomiono w sierpniu 2022 roku jako wyspecjalizowany program nagród za wykrywanie podatności w projektach open source utrzymywanych przez Google. Zakres obejmował m.in. Golang, Angular, Bazel, Fuchsia, Protocol Buffers oraz wybrane zależności zewnętrzne mające znaczenie dla bezpieczeństwa łańcucha dostaw.
Już wcześniej Google sygnalizował rosnącą presję operacyjną wynikającą z napływu zgłoszeń wspieranych przez AI. W marcu 2026 roku firma zaostrzyła kryteria akceptacji dla wybranych klas błędów, wymagając mocniejszych dowodów technicznych, takich jak powtarzalna reprodukcja w OSS-Fuzz lub dostarczenie scalonej poprawki.
Obecna decyzja wpisuje się w szerszy trend obserwowany w branży. Programy bug bounty coraz częściej mierzą się z dużą liczbą raportów opisujących hipotetyczne problemy, które nie przekładają się na rzeczywiste ryzyko bezpieczeństwa.
Analiza techniczna
Kluczowy problem nie dotyczy wyłącznie liczby zgłoszeń, ale ich struktury i jakości. Narzędzia generatywne pozwalają szybko tworzyć raporty wskazujące potencjalne ścieżki ataku, zależności między komponentami czy interpretacje przepływu danych, które w praktyce mogą być błędne, nieosiągalne albo pozbawione znaczenia z perspektywy bezpieczeństwa.
Dla zespołów triage oznacza to kilka istotnych wyzwań. Część raportów opisuje rzeczywisty defekt programistyczny, ale bez wpływu na poufność, integralność lub dostępność. Inne opierają się na halucynacjach modelu, zawierając nieistniejące zależności, błędne założenia o uprawnieniach albo nierealistyczny scenariusz exploita. Zdarza się również, że poprawnie wskazana anomalia dotyczy kodu martwego, testowego lub nieużywanego w produkcyjnych ścieżkach wykonania.
W praktyce rośnie znaczenie twardych artefaktów technicznych. Coraz większą wartość mają zgłoszenia zawierające działający proof of concept, wyniki fuzzingu, merged patch, wskazanie warunków osiągalności oraz precyzyjne uzasadnienie wpływu na model zagrożeń projektu.
Tymczasowe zatrzymanie części zgłoszeń można więc rozumieć jako próbę ochrony procesu bezpieczeństwa. Jeżeli kanał detekcji zostaje przeciążony dużą liczbą słabych raportów, realne podatności mogą zostać opóźnione lub przeoczone.
Konsekwencje / ryzyko
Dla badaczy bezpieczeństwa decyzja Google oznacza wyraźny wzrost oczekiwań wobec jakości zgłoszeń. Samo wskazanie podejrzanego fragmentu kodu przestaje być wystarczające, jeśli nie da się wykazać praktycznego wpływu, osiągalności oraz powtarzalnej ścieżki nadużycia.
Dla organizacji prowadzących własne programy bug bounty to sygnał, że AI może jednocześnie zwiększać produktywność researcherów i destabilizować proces obsługi zgłoszeń. Bez dodatkowych progów jakościowych i automatycznej walidacji rosną koszty operacyjne, wydłuża się czas reakcji i pogarsza efektywność zespołów AppSec oraz PSIRT.
Ryzyko dotyczy również łańcucha dostaw oprogramowania. Projekty open source pozostają krytycznym elementem środowisk CI/CD, dlatego przeciążenie programu nagród szumem może osłabić zdolność do szybkiego wykrywania błędów zagrażających pipeline’om buildów, repozytoriom, zależnościom i mechanizmom publikacji pakietów.
Rekomendacje
Organizacje utrzymujące programy bug bounty powinny rozważyć wielowarstwowy model walidacji zgłoszeń, w którym wymagane są minimalne dane reprodukcyjne, określenie warunków osiągalności błędu oraz jasne rozróżnienie między defektem jakości kodu a podatnością bezpieczeństwa.
- wymaganie działającego proof of concept lub innego technicznego artefaktu,
- priorytetyzowanie zgłoszeń dotyczących integralności procesu build i publikacji,
- oddzielenie ścieżek obsługi dla podatności produktowych i incydentów supply chain,
- stosowanie formularzy wymuszających opis wpływu technicznego i biznesowego,
- monitorowanie wskaźników jakości, takich jak odsetek false positives, duplikatów i czas potrzebny na potwierdzenie zgłoszenia.
Badacze bezpieczeństwa powinni natomiast traktować AI jako narzędzie wspomagające, a nie zastępujące analizę ekspercką. Każdy raport przygotowany z użyciem modelu językowego powinien zostać ręcznie sprawdzony pod kątem realistyczności założeń, osiągalności kodu i zgodności z architekturą badanego projektu.
Podsumowanie
Czasowe wstrzymanie OSS VRP przez Google pokazuje, że największym wyzwaniem ery automatyzacji nie jest samo wykrywanie anomalii, lecz ich wiarygodne potwierdzanie. Rosnąca liczba raportów generowanych przez AI może obniżać skuteczność programów bug bounty, jeśli nie towarzyszy jej odpowiedni poziom dowodów technicznych.
Najważniejszy wniosek dla branży jest prosty: wartość zgłoszenia bezpieczeństwa coraz bardziej zależy od jakości walidacji, kontekstu zagrożenia i możliwości praktycznego wykazania wpływu. To właśnie te elementy będą decydować o skuteczności nowoczesnych procesów vulnerability management.
Źródła
- Google halts open-source bug bounty program amid AI spam surge — https://www.bleepingcomputer.com/news/google/google-halts-open-source-bug-bounty-program-amid-ai-spam-surge/
- Announcing Google’s Open Source Software Vulnerability Rewards Program — https://security.googleblog.com/2023/08/Announcing-Googles-Open-Source-Software-Vulnerability-Rewards-Program%20.html
- Streamlining Google’s OSS VRP: Key Rule Updates — https://bughunters.google.com/blog/ossvrp-rule-updates-2026
- Open Source Security Patch Rewards — https://bughunters.google.com/open-source-security/patch-rewards
- Vulnerability Reward Program: 2022 Year in Review — https://security.googleblog.com/2023/02/vulnerability-reward-program-2022-year.html?hl=en_GB