Od 1 października 2026 roku Google nie przyjmuje w programie Open Source Software Vulnerability Reward Program (OSS VRP) zgłoszeń tzw. podatności produktowych, czyli błędów w kodzie własnych projektów open source. Firma tłumaczy to gwałtownym wzrostem automatycznych zgłoszeń, w większości nieprawdziwych. Program nie został zamknięty w całości: nadal przyjmuje zgłoszenia dotyczące łańcucha dostaw, a nowe zasady Google obiecuje przedstawić w pierwszym kwartale 2027 roku.
Co dokładnie wstrzymał Google
OSS VRP to program nagród (bug bounty), w którym Google płaci badaczom bezpieczeństwa za wykryte luki w otwartym oprogramowaniu udostępnianym przez firmę. Obejmuje publiczne repozytoria organizacji Google na GitHubie i wybrane projekty na innych platformach. Regulamin dzieli zgłoszenia na kilka kategorii, a zmiana dotyczy jednej z nich.
Według zaktualizowanego regulaminu Google od 1 października 2026 roku nie przyjmuje w OSS VRP podatności produktowych. Chodzi o błędy w samym kodzie, takie jak uszkodzenie pamięci w parserach plików, zawodne funkcje oczyszczania HTML czy błędy typu path traversal, czyli dostęp do plików spoza dozwolonego katalogu. Zgłoszenia wysłane przed tą datą zostaną rozpatrzone.
Firma zachęca badaczy do szukania skutków tych samych błędów w innych swoich programach nagród albo do udziału w Patch Rewards Program, który nagradza poprawki bezpieczeństwa w projektach open source. Błędy w repozytoriach powiązanych z produktami Google Cloud można w części przypadków zgłaszać przez Cloud VRP.
Dlaczego program został zawieszony
Google podał powód we wpisie konta Google VRP w serwisie X z 1 października 2026 roku, cytowanym przez TechCrunch i Tom's Hardware. Według firmy przerwa wynika ze znacznego wzrostu liczby automatycznych zgłoszeń, z których zdecydowana większość jest nieważna. Google nie opublikował danych o liczbie raportów ani o udziale zgłoszeń przygotowanych z pomocą modeli językowych.
Tom's Hardware opisuje, że inżynierowie i opiekunowie projektów musieli ręcznie weryfikować tysiące raportów opisujących nieistniejące lub niemożliwe do wykorzystania błędy. Ta liczba pochodzi z relacji medium, a nie z komunikatu Google. Problem jest szerszy: według tego samego serwisu opiekunowie jądra Linux skarżą się na rekordową liczbę zgłoszeń CVE wykrywanych narzędziami AI, a Intel zawiesił własny program nagród, choć nie potwierdził, że powodem były zgłoszenia generowane przez AI.
W naszej ocenie to przykład szerszego problemu z nadmiarem zgłoszeń. Od 1 października 2026 roku limit zgłoszeń od jednego autora wprowadził też arXiv, choć tam powodem była głównie rekordowa liczba słabych prac. W bug bounty narzędzia AI obniżyły koszt wysłania raportu niemal do zera, ale koszt jego sprawdzenia nadal ponoszą ludzie.
Co nadal działa w OSS VRP
Zmiana nie wyłącza programu. Poniżej zestawienie stanu kategorii według regulaminu sprawdzonego 4 października 2026 roku:
- Łańcuch dostaw - nadal przyjmowane. Chodzi m.in. o możliwość zmiany kodu w głównej gałęzi repozytorium, błędy w konfiguracji GitHub Actions, wyciek danych do publikacji pakietów i przejęcie kluczy podpisujących.
- Podatności produktowe - wstrzymane od 1 października 2026 roku, z wyjątkiem części repozytoriów Google Cloud obsługiwanych przez Cloud VRP.
- Zgłoszenia wysłane przed 1 października 2026 roku - rozpatrywane na dotychczasowych zasadach.
- Projekty niższych poziomów ważności (OT2 i OT3) - już wcześniej nie dawały prawa do nagrody pieniężnej za podatności produktowe.
Co to oznacza dla badaczy i opiekunów projektów w Polsce
Dla użytkowników bibliotek Google zmiana nie oznacza mniej bezpiecznego oprogramowania. Prawdziwe błędy nadal można zgłaszać opiekunom projektów, a Google utrzymuje nagrody za najgroźniejsze ataki na łańcuch dostaw. Zmniejsza się natomiast motywacja finansowa dla niezależnych badaczy, także z Polski, którzy szukali błędów w kodzie projektów Google.
Opiekunowie własnych projektów open source mogą wyciągnąć z tej decyzji praktyczne wnioski. Skuteczną ochroną przed zalewem zgłoszeń jest wymaganie dowodu, a nie zakaz używania AI:
- opisz w pliku SECURITY.md, że zgłoszenie musi zawierać kroki odtworzenia błędu lub działający dowód koncepcji (proof of concept),
- przy błędach pamięci wymagaj reprodukcji w fuzzerze, tak jak Google robi to dla najważniejszych projektów z użyciem OSS-Fuzz,
- poproś zgłaszających o informację, czy raport przygotowało narzędzie AI i czy człowiek sprawdził wynik,
- zamykaj bez długiej dyskusji zgłoszenia bez reprodukcji i odsyłaj do zasad w SECURITY.md.
Ograniczenia i niewiadome
Google nie podał, ile zgłoszeń otrzymał, jaki odsetek okazał się nieważny ani jak będzie wyglądał program po zmianach. Zapowiedź aktualizacji w pierwszym kwartale 2027 roku nie przesądza, czy kategoria podatności produktowych wróci w tej samej formie i z tymi samymi nagrodami.
Sam wpis w serwisie X nie był dla nas dostępny bez logowania, dlatego powód przerwy podajemy za cytatami w TechCrunch i Tom's Hardware. Zakres zmiany potwierdziliśmy bezpośrednio w regulaminie programu na stronie Google Bug Hunters.
Źródła i data sprawdzenia
- Google Open Source Software Vulnerability Reward Program RulesGoogle Bug Hunters, publikacja: 2026-10-01, sprawdzono: 2026-10-04
- Google froze its open source bug bounty program due to a 'significant rise' in AI submissionsTechCrunch, publikacja: 2026-10-04, sprawdzono: 2026-10-04
- Google freezes open-source bug bounty program amid flood of invalid AI slop submissionsTom's Hardware, publikacja: 2026-10-03, sprawdzono: 2026-10-04
Artykuł ma charakter informacyjny. Przy decyzjach prawnych, finansowych lub organizacyjnych warto zweryfikować wnioski w odniesieniu do konkretnej sytuacji.



