Google wstrzymał część swojego programu bug bounty dla oprogramowania open source. Od 1 października 2026 r. Open Source Software Vulnerability Reward Program (OSS VRP) nie przyjmuje nowych zgłoszeń podatności w produktach. Firma tłumaczy decyzję gwałtownym wzrostem liczby automatycznych zgłoszeń, z których zdecydowana większość okazuje się nieprawidłowa.
Pauza nie obejmuje całego programu. Nadal przyjmowane są zgłoszenia dotyczące łańcucha dostaw (supply chain), a część repozytoriów Google Cloud obsługuje osobny program Cloud VRP. Raporty wysłane przed 1 października zostaną rozpatrzone. Zamrożone są natomiast nowe zgłoszenia błędów w kodzie, w logice i w projekcie publicznych repozytoriów Google. Informację o dalszych losach programu firma zapowiada na pierwszy kwartał 2027 r.
Dlaczego Google zamroził program bug bounty
TechCrunch, powołując się na Tom's Hardware, opisuje sytuację, w której inżynierowie Google i opiekunowie projektów open source przestali nadążać z weryfikacją raportów. Wiele z nich zawierało halucynacje modeli językowych albo opisywało problemy bez realnego wpływu na bezpieczeństwo. Sygnały ostrzegawcze pojawiały się wcześniej: zespół OSS VRP zwracał uwagę na zgłoszenia generowane przez AI już w marcu 2026 r. W maju Google przebudował zasady programów dla Chrome i Androida, stawiając na powtarzalne raporty z działającym proof of concept.
Google nie jest wyjątkiem. Na początku roku program nagród zamknął projekt curl. Podobny napływ raportów generowanych przez AI odnotowała Linux Foundation, a Internet Bug Bounty wstrzymał przyjmowanie nowych zgłoszeń. Mechanizm jest wszędzie ten sam. Wygenerowanie raportu kosztuje zgłaszającego niemal nic, a jego rzetelna weryfikacja zajmuje ekspertowi godziny. Gdy w grze jest nagroda pieniężna, ta asymetria zachęca do wysyłania zgłoszeń masowo i w ciemno.
Co to znaczy dla polskich firm
Problem nie dotyczy wyłącznie gigantów technologicznych. Każda organizacja, która prowadzi własny program bug bounty, udostępnia formularz zgłaszania podatności albo ma politykę coordinated vulnerability disclosure, może dostać podobną falę raportów. Warto z wyprzedzeniem określić minimalne wymagania wobec zgłoszenia: działający proof of concept, wskazanie wersji oprogramowania i kroki reprodukcji. Trzeba też ustalić, kto i w jakim czasie robi wstępną selekcję. Dla podmiotów objętych NIS2 uporządkowana obsługa podatności jest częścią zarządzania ryzykiem, a zalew fałszywych alarmów grozi tym, że prawdziwe zgłoszenie utonie w szumie.
Druga lekcja dotyczy zespołów, które same używają AI do szukania luk. Model potrafi wskazać podejrzany fragment kodu, ale bez sprawdzenia przez człowieka łatwo wysłać raport o błędzie, który nie istnieje. Zanim cokolwiek trafi do dostawcy lub opiekuna projektu, wynik warto odtworzyć w praktyce i odrzucić to, czego nie da się potwierdzić. Takie podejście chroni reputację zgłaszającego i czas osób po drugiej stronie.
Źródło: TechCrunch (EN), 4 października 2026; PBX Science (EN), 4 października 2026; zasady programu Google OSS VRP (EN).
