Google wstrzymuje program nagród za błędy w open source, gdy raporty AI przytłaczają recenzentów

Google wstrzymał program nagród za błędy w oprogramowaniu open source po fali zautomatyzowanych zgłoszeń, zaznaczając, że zdecydowana większość z nich była nieprawidłowa. Zawieszenie rozpoczęło się 1 października 2026 roku i dotyczy nowych zgłoszeń luk produktowych do Open Source Software Vulnerability Reward Program.

Ta decyzja uwidacznia wyraźną sprzeczność w badaniach bezpieczeństwa wspieranych przez AI. Modele mogą dziś analizować więcej kodu i tworzyć przekonujące raporty z bezprecedensową szybkością. Mimo to każde zgłoszenie nadal wymaga człowieka, który ustali, czy opisana wada rzeczywiście istnieje, czy ma znaczenie i czy można ją odtworzyć.

Google nie jest odosobnione. Curl zakończył wypłacanie nagród pieniężnych po tym, jak odsetek potwierdzonych luk spadł poniżej 5% w 2025 roku. Opiekunowie Linuxa również zmienili praktyki ujawniania podatności po otrzymaniu fal zduplikowanych ustaleń AI. Łącznie przypadki te pokazują, że wykrywanie luk skalowało się szybciej niż ich weryfikacja.

Program nagród Google za błędy w open source przestaje przyjmować raporty dotyczące produktów

Google tymczasowo zamknął jeden z głównych kanałów przyjmowania zgłoszeń, ponieważ automatyczne przesyłanie raportów generowało więcej pracy weryfikacyjnej niż użytecznych ustaleń dotyczących bezpieczeństwa.

Google OSS VRP, czyli Open Source Software Vulnerability Reward Program, nagradza badaczy, którzy odpowiedzialnie ujawniają błędy bezpieczeństwa w kwalifikujących się projektach open source. Google uruchomił program w 2022 roku, aby objąć nim oprogramowanie utrzymywane w jego publicznych repozytoriach oraz wybrane projekty zewnętrzne.

Ten kanał zgłaszania podatności produktowych przestał przyjmować nowe raporty 1 października. Google poinformował, że spodziewa się kolejnej aktualizacji w pierwszym kwartale 2027 roku.

„Ta przerwa wynika ze znacznego wzrostu liczby zautomatyzowanych zgłoszeń, z których zdecydowana większość nie jest prawidłowa” — podał Google w komunikacie. To sformułowanie ma znaczenie, ponieważ odróżnia automatyzację od zweryfikowanych badań nad podatnościami.

Wstrzymanie nie unieważnia raportów przesłanych przed terminem granicznym. Nie zamyka też wszystkich ścieżek związanych z szerszym programem. Zgłoszenia podatności w łańcuchu dostaw nadal kwalifikują się do programu, zgodnie ze zaktualizowanymi zasadami programu.

Niektóre podatności dotyczące repozytoriów Google Cloud nadal mogą kwalifikować się poprzez Cloud VRP. Google skierował także badaczy do innych programów nagród, podczas gdy dokonuje przeglądu procesu przyjmowania zgłoszeń open source.

Ten węższy zakres sprawia, że „zamrożenie” jest trafniejszym określeniem niż „zamknięcie”. Google zawiesił nowe zgłoszenia podatności produktowych w ramach programu OSS, a nie porzucił zewnętrznych badań bezpieczeństwa w całej firmie.

Firma nie opublikowała liczby zgłoszeń, odsetka nieprawidłowych raportów ani całkowitej kolejki zgłoszeń do oceny w dotkniętym kanale. Twierdzenia, że recenzenci otrzymali konkretną liczbę złych raportów, pozostają zatem niezweryfikowane.

To, co Google ujawnił, jest jednak decydującym sygnałem. Zautomatyzowane raporty stały się wystarczająco liczne i wystarczająco niewiarygodne, by dotychczasowy proces stał się nie do utrzymania.

Proces ten wymaga czegoś więcej niż otrzymania dopracowanego dokumentu. Recenzent musi przeanalizować ścieżkę w kodzie, odtworzyć warunki, ocenić możliwość wykorzystania, wyszukać duplikaty i ustalić odpowiedzialny zespół projektowy.

Prawdopodobnie brzmiący raport może pochłonąć znaczną ilość czasu, nawet jeśli jest błędny. Duże modele językowe utrudniają ten problem, ponieważ mogą tworzyć szczegółowe wyjaśnienia, fragmenty kodu i pewne twierdzenia o poziomie zagrożenia bez udowodnienia istnienia leżącej u podstaw podatności.

Google już wcześniej zaostrzył zasady w 2026 roku, po zaobserwowaniu „masowego wzrostu” liczby raportów generowanych przez AI. Październikowa przerwa sugeruje, że same wymagania dotyczące filtrowania nie przywróciły akceptowalnego stosunku sygnału do szumu.

Program nagród Google za błędy w open source stał się zatem przypadkiem testowym dla szerszego problemu bezpieczeństwa. Wygenerowanie twierdzenia jest dziś tanie, podczas gdy jego obalenie nadal pozostaje kosztowne.

Dlaczego raporty o błędach tworzone przez AI generują asymetryczne koszty

AI zmienia ekonomię ujawniania podatności, ponieważ maszyna może generować raporty szybciej, niż opiekunowie projektów są w stanie je zweryfikować.

Tradycyjne poszukiwanie błędów nakłada na badacza istotne koszty. Człowiek musi zrozumieć bazę kodu, wyizolować nieoczekiwane zachowanie, sprawdzić, czy powoduje ono skutki dla bezpieczeństwa, oraz udokumentować możliwy do odtworzenia przypadek.

Generatywna AI redukuje część tego nakładu pracy. Agent może skanować repozytoria, śledzić funkcje, porównywać wzorce, tworzyć kod proof-of-concept i przekształcać wstępne ustalenia w profesjonalnie wyglądające raporty.

Te możliwości mogą pomagać rzetelnym badaczom. Mogą też umożliwiać niedoświadczonym użytkownikom przesyłanie twierdzeń, których nie rozumieją i których nie potrafią obronić podczas dodatkowych pytań.

Asymetria ujawnia się po przesłaniu raportu. Wygenerowanie kolejnego zgłoszenia może wymagać niewielkiego dodatkowego wysiłku, ale jego ocena nadal pochłania ograniczoną uwagę inżynierów.

Christopher Robinson, dyrektor ds. technologii Open Source Security Foundation, opisał to obciążenie w marcowym raporcie o bezpieczeństwie. Jak oszacował, popularne projekty otrzymywały kiedyś dwa lub trzy raporty w przeciętnym tygodniu. Niektóre zaczęły później otrzymywać setki naraz.

Robinson powiedział, że pojedynczy raport może wymagać od dwóch do ośmiu godzin nieplanowanej pracy opiekuna projektu. Ten koszt istnieje nawet wtedy, gdy ostateczna odpowiedź brzmi: żadna podatność nie występuje.

Fałszywe alarmy nie są jedynym problemem. Zautomatyzowane systemy mogą wysyłać zduplikowane odkrycia, błędnie interpretować udokumentowane zachowanie, ignorować modele zagrożeń lub wyolbrzymiać defekty o niewielkim wpływie.

Zmyślona podatność jest szczególnie kosztowna, ponieważ raport może brzmieć wewnętrznie spójnie. Recenzenci mogą podążać za szczegółową argumentacją techniczną, zanim odkryją, że przywołana funkcja, ścieżka sterowania lub warunek wykorzystania zostały wymyślone.

Vlad Ionescu, współzałożyciel firmy RunSybil zajmującej się bezpieczeństwem AI, opisał takie doświadczenie we wcześniejszym śledztwie dotyczącym AI slop. Powiedział, że raporty mogą wyglądać na technicznie poprawne, dopóki recenzenci nie przeprowadzą dochodzenia i nie stwierdzą, że model sfabrykował szczegóły.

Powstaje w ten sposób wąskie gardło weryfikacji. AI zwiększa podaż potencjalnych ustaleń, ale nie zwiększa automatycznie liczby zaufanych recenzentów.

Programy nagród za błędy tworzą także finansową zachętę do przesyłania niepewnych twierdzeń. Badacz może wysyłać wiele spekulacyjnych raportów, podczas gdy opiekunowie projektów ponoszą większość kosztów weryfikacji.

Systemy reputacji i limity zgłoszeń mogą ograniczać nadużycia, ale wprowadzają własne kompromisy. Surowe bramki mogą wykluczać nowych badaczy, którym brakuje historii na platformie, lecz którzy posiadają prawdziwe ustalenie.

Wymogi dotyczące tożsamości mogą zniechęcać do odpowiedzialnego ujawniania podatności osoby narażone na ryzyko prawne, zawodowe lub geograficzne. Opłaty za zgłoszenia stworzyłyby jeszcze większą barierę.

Automatyczna selekcja rodzi kolejną komplikację. Filtr odrzucający raporty, ponieważ brzmią jak wygenerowane maszynowo, może odrzucać prawdziwe podatności odkryte lub udokumentowane z pomocą AI.

Kluczowe rozróżnienie nie dotyczy tego, czy AI miała udział w raporcie. Chodzi o to, czy zgłaszający zweryfikował zachowanie i potrafi poprzeć twierdzenie możliwymi do odtworzenia dowodami.

Egzekwowanie tego standardu staje się trudniejsze, gdy agenci mogą tworzyć przekonujące dokumenty na masową skalę. Jakość tekstu przestaje być wiarygodnym sygnałem jakości badań.

Praktyczna odpowiedź będzie prawdopodobnie obejmować silniejsze wymagania dotyczące dowodów. Programy mogą wymagać minimalnych reprodukcji, szczegółów dotyczących dotkniętej wersji, śladów wykorzystania, przypadków testowych lub działających poprawek przed przydzieleniem zgłoszenia do oceny przez człowieka.

Wymagania te przenoszą część kosztów weryfikacji z powrotem na zgłaszającego. Sprzyjają też badaczom, którzy rozumieją kod i pozostają dostępni, by odpowiadać na pytania.

Problem Google z raportami o błędach AI jest także sukcesem bezpieczeństwa AI

Ta sama technologia, która tworzy niskiej jakości zgłoszenia, znajduje prawdziwe podatności przeoczone przez ludzkich badaczy.

Traktowanie każdego raportu wspieranego przez AI jako śmieci błędnie odczytywałoby dowody. Zaawansowane modele wykazały istotne możliwości analizy kodu w kontrolowanych warunkach.

Anthropic podał, że Claude Opus 4.6 znalazł podczas wewnętrznych testów ponad 500 wcześniej nieznanych podatności w projektach open source. Według firmy każde ustalenie zostało zweryfikowane przez człowieka lub zewnętrznych badaczy bezpieczeństwa przed ujawnieniem.

Mozilla otrzymała 112 raportów z tego działania w ciągu dwóch tygodni. Wydała 22 zalecenia bezpieczeństwa, w tym 14 dotyczących błędów o wysokiej wadze, a wiele pozostałych ustaleń zaklasyfikowała jako błędy niezwiązane z bezpieczeństwem.

Wyniki te ilustrują proces różniący się od masowego automatycznego przesyłania zgłoszeń. Anthropic połączył wykrywanie przez maszynę z walidacją przez człowieka, skoordynowanym ujawnianiem informacji i skoncentrowaną komunikacją z opiekunami projektów.

W jednym przypadku model miał podobno stworzyć proof of concept, aby potwierdzić, że podejrzewana wada była rzeczywista. Ten krok przekształca spekulacyjny wzorzec w dowód, który recenzenci mogą przetestować.

Ustalenia dotyczące Firefox pokazują również, dlaczego całkowity zakaz badań z użyciem AI byłby przeciwskuteczny. Modele mogą analizować dojrzały, intensywnie testowany kod i nadal ujawniać istotne w skutkach defekty.

Konflikt nie przebiega zatem między ludźmi a AI. Chodzi o zweryfikowane badania kontra nieodpowiedzialne generowanie raportów.

Wysokiej jakości proces wspierany przez AI zachowuje ludzkiego właściciela. Osoba ta sprawdza wynik, usuwa fałszywe alarmy, rozumie wpływ podatności i bierze odpowiedzialność za komunikację z opiekunami projektów.

Niskiej jakości proces traktuje punkt końcowy ujawniania jako kolejny zautomatyzowany cel. Agent identyfikuje wzorzec, tworzy opis wagi problemu i przesyła go bez niezależnego odtworzenia.

Oba procesy mogą tworzyć dopracowaną prozę. Tylko jeden z nich zmniejsza nakład pracy odbiorcy.

To rozróżnienie wyjaśnia, dlaczego przerwa Google nie dowodzi porażki polowania na błędy z wykorzystaniem AI. Pokazuje, że jego architektura przyjmowania zgłoszeń nie mogła wchłonąć obecnej mieszanki wartościowych ustaleń, duplikatów i halucynacji.

Bezpieczeństwo wspierane przez AI może z czasem usprawnić obie strony tej architektury. Programy mogą wykorzystywać modele do grupowania duplikatów, porównywania twierdzeń ze znanymi problemami, testowania ścieżek wykorzystania i identyfikowania brakujących dowodów.

HackerOne i inne platformy zaczęły wprowadzać pomoc w ocenie zgłoszeń opartą na AI. Takie narzędzia mogą ustalać priorytety raportów, lecz ich skuteczność musi być mierzona względem odsetka fałszywych odrzuceń i pominiętych podatności.

Zautomatyzowany recenzent również może halucynować. Jeśli programy umieszczają model między badaczami a opiekunami projektów, potrzebują ścieżek eskalacji dla ustaleń, których filtr nie może pewnie sklasyfikować.

Najsilniejszy model będzie prawdopodobnie wielowarstwowy. Maszyny wykonują niedrogie kontrole, doświadczeni analitycy oceniają raporty, które je przejdą, a opiekunowie projektów zajmują się wyłącznie wiarygodnymi ustaleniami.

To podejście przypomina ciągłą integrację przy tworzeniu oprogramowania. Testy odrzucają oczywiste błędy, zanim opiekun projektu poświęci czas na szczegółową ocenę.

Twierdzenia dotyczące bezpieczeństwa nadal trudniej testować niż zwykłe zmiany w kodzie. Możliwość wykorzystania zależy od kontekstu, konfiguracji, granic zaufania i możliwości atakującego, które zautomatyzowane kontrole mogą błędnie rozumieć.

Mimo to wymaganie dowodów możliwych do sprawdzenia przez maszynę może poprawić poziom bazowy. Raport z nieudanym testem, śladem wykonania lub możliwym do odtworzenia awarią daje recenzentom coś konkretnego do oceny.

Organizacje potrzebują również trwałych rejestrów tej pracy. Przeszukiwalna baza wiedzy inżynierskiej może pomóc zespołom porównywać nowe ustalenia z wcześniejszymi raportami, decyzjami i poprawkami.

Celem nie jest spowalnianie uzasadnionego wykrywania problemów. Chodzi o to, by nie dopuścić, aby nieograniczone generowanie treści pochłaniało ograniczony budżet ludzkiej weryfikacji.

Curl i Linux pokazują, że to problem całej branży

Pauza wprowadzona przez Google wpisuje się w trend, w którym projekty open source zawężają kanały zgłaszania po tym, jak AI przeciąża istniejące systemy zaufania.

Curl stanowi najczytelniejszy wcześniejszy przykład. Szeroko używany projekt transferu danych zakończył swój pieniężny program nagród za błędy 31 stycznia 2026 roku, po prowadzeniu go od 2019 roku.

Opiekun projektu Daniel Stenberg powiedział, że program doprowadził do potwierdzenia 87 podatności. Jednak trend jakościowy gwałtownie pogorszył się w 2025 roku.

Wcześniej Curl potwierdzał jako podatności ponad 15% zgłoszeń. W 2025 roku wskaźnik spadł poniżej 5%, co oznacza, że prawidłowe okazało się mniej niż jedno na dwadzieścia zgłoszeń.

Stenberg wskazał trzy powiązane trendy: śmieci generowane przez AI, spadek jakości innych zgłoszeń oraz osoby zgłaszające skupione na nagrodach zamiast na ulepszaniu projektu.

„Niekończące się zgłoszenia śmieci stanowią poważne obciążenie psychiczne w zarządzaniu nimi” — napisał, ogłaszając decyzję curl.

Curl nie przestał przyjmować zgłoszeń bezpieczeństwa. Usunął nagrody pieniężne, pozostawił HackerOne jako rekomendowany kanał i skierował badaczy do prywatnych zgłoszeń na GitHub lub przez e-mail.

Ta odpowiedź była wymierzona w zachęty, a nie w samą technologię. Stenberg argumentował, że nagrody przyciągały uzasadnione odkrycia, ale jednocześnie zbyt mocno ułatwiały spekulacyjne zgłoszenia.

Przyznał, że wiąże się to z kompromisem. Usunięcie płatności może ograniczyć szum, ale może także osłabić motywację wykwalifikowanych niezależnych badaczy, którzy poświęcają dużo czasu na trudne dochodzenia.

Społeczność jądra Linuxa zetknęła się z pokrewnym problemem dotyczącym duplikatów ustaleń. Wielu badaczy uruchamiało podobne narzędzia AI na tym samym kodzie i przesyłało te same problemy przez prywatny kanał.

Prywatne ujawnianie uniemożliwiało badaczom dostrzeżenie, że inna osoba już zgłosiła lub omówiła dane ustalenie. Opiekunowie projektu wielokrotnie przekierowywali duplikaty lub wskazywali na poprawki już dostępne publicznie.

Linus Torvalds opisał prywatną listę bezpieczeństwa jako „niemal całkowicie niemożliwą do zarządzania”. Argumentował, że ustalenia wykryte przez AI powinny zwykle trafiać przez publiczne kanały projektu, chyba że zachowanie tajności jest rzeczywiście konieczne.

Dokumentacja Linuxa podniosła również oczekiwany standard wobec zgłaszających. Badacze powinni przedstawić zwięzłe dowody, skontaktować się z odpowiednimi opiekunami i, jeśli to możliwe, dostarczyć poprawkę.

Taka polityka zachowuje ludzką odpowiedzialność. AI może pomagać w wykrywaniu, lecz człowiek musi rozumieć zgłoszenie i pozostać odpowiedzialny za jego konsekwencje.

Google, curl i Linux wybrali różne interwencje, ponieważ ich programy mają odmienne struktury. Google wstrzymał jedną kategorię zgłoszeń. Curl usunął nagrody. Linux przekierował wiele zgłoszeń i podkreślił publiczną obsługę.

Ich wspólny wniosek jest ważniejszy niż indywidualne szczegóły polityki. Otwarte przyjmowanie zgłoszeń bez istotnych kosztów ich składania nie działa, gdy zautomatyzowani agenci mogą tworzyć niemal nieograniczoną liczbę twierdzeń.

Największe ryzyko dotyczy mniejszych projektów. Google może przydzielić inżynierów i przeprojektować infrastrukturę, podczas gdy opiekunowie-wolontariusze mogą nie mieć żadnego dedykowanego zespołu triage.

Oprogramowanie open source często znajduje się wewnątrz produktów komercyjnych, usług chmurowych, narzędzi programistycznych i systemów krytycznych. Mimo to odpowiedzialność za przeglądanie zgłoszeń bezpieczeństwa może spadać na kilku nieopłacanych współtwórców.

AI wzmacnia tę nierównowagę. Pozwala osobom z zewnątrz nieustannie skanować ważny kod bez dostarczania pracy potrzebnej do zweryfikowania, załatania i skoordynowania każdego potencjalnego ustalenia.

Rezultat przypomina problem odmowy usługi, nawet gdy zgłaszający mają dobre intencje. Każdy raport wymaga od opiekunów poświęcenia uwagi, a łączna liczba może wypierać rzeczywiste podatności.

Surowsze bariery mogą również ukrywać rzeczywiste podatności

Programy muszą ograniczać liczbę zgłoszeń niskiej jakości, nie tworząc systemu bezpieczeństwa dostępnego wyłącznie dla uznanych badaczy.

Pauza Google chroni w krótkim okresie osoby dokonujące przeglądu, ale usuwa też ścieżkę zgłaszania uzasadnionych odkryć. Prawidłowa podatność produktu wykryta po 1 października może wymagać skorzystania z innego kwalifikującego się programu lub kanału ujawniania.

To utrudnienie ma znaczenie, ponieważ badacze nie zawsze rozumieją granice organizacyjne firmy. Błąd w repozytorium open source może wpływać na produkt chmurowy, zależność lub aplikację działającą dalej w łańcuchu.

Skomplikowane zasady kierowania zgłoszeń zwiększają ryzyko opóźnionego lub błędnie skierowanego ujawnienia. Mogą również zachęcać do publicznego publikowania, gdy badacze nie potrafią zidentyfikować akceptowanego prywatnego kanału.

Dostęp oparty na reputacji tworzy kolejne ryzyko. Doświadczonym badaczom łatwiej zaufać, lecz nowi uczestnicy historycznie wnosili ważne odkrycia do programów nagród.

System faworyzujący ugruntowane tożsamości może odtwarzać istniejące luki w dostępie. Może stawiać w niekorzystnej sytuacji niezależnych badaczy, studentów i osoby spoza głównych społeczności bezpieczeństwa.

Rygorystyczne wymogi dotyczące proof of concept mogą również stać się niebezpieczne. Wykazanie możliwości wykorzystania podatności może wymagać obsługi rzeczywistych danych, omijania zabezpieczeń lub przeprowadzania testów naruszających zasady programu.

Programy potrzebują zatem standardów dowodowych, które są mocne, ale bezpieczne. Minimalny reproduktor, kontrolowany test lub szczegółowa ścieżka kodu mogą potwierdzić wiarygodność bez wymagania szkodliwego wykorzystania.

Nie istnieje też wiarygodny detektor tekstu wygenerowanego przez AI. Badacze powszechnie używają modeli do tłumaczenia, redakcji, wyjaśniania kodu lub formatowania, nawet gdy podstawowa praca jest uzasadniona.

Odrzucanie raportów na podstawie stylu karałoby staranne ujawnianie i tworzyło zachęty do ukrywania użycia AI. Nie ustalałoby, czy zgłoszona wada jest rzeczywista.

Publiczne oświadczenie Google pozostawia kilka pytań bez odpowiedzi. Firma nie ujawniła, które środki przesiewowe zawiodły, ile uzasadnionych ustaleń znalazło się w fali zgłoszeń ani jaki przeprojektowany system rozważa.

Nie jest też jasne, czy pauza zakończy się większą automatyzacją, wyższymi progami dowodowymi, ograniczonym dostępem czy innym modelem nagród.

Brak liczb ogranicza zewnętrzną ocenę. „Zdecydowana większość” komunikuje skalę problemu, ale nie ujawnia, czy wskaźnik poprawności spadł nieznacznie poniżej istniejącego progu, czy załamał się niemal całkowicie.

Czytelnicy powinni również unikać traktowania doświadczeń Google jako uniwersalnych. Mozilla wcześniej informowała, że jej wskaźnik odrzucania nieprawidłowych raportów pozostał stabilny w wcześniejszym okresie, mimo szerszych obaw branży.

Projekt programu, widoczność projektu, zachęty w postaci nagród i zasady składania zgłoszeń wpływają zarówno na liczbę, jak i jakość raportów. Polityka, która działa w jednym projekcie, może zawieść w innym.

Same systemy AI również szybko się zmieniają. Lepsze modele mogą tworzyć bardziej przekonujące fałszywie pozytywne wyniki, ale mogą też generować mocniejsze dowody i ograniczać halucynacje.

Ten podwójny ruch sprawia, że statyczne zasady są kruche. Programy potrzebują mierzalnych mechanizmów kontroli jakości, które oceniają dowody, zamiast zgadywać, jakie narzędzie je stworzyło.

Dla liderów bezpieczeństwa centralną metryką nie powinna być surowa liczba raportów. Przydatne miary obejmują wskaźnik potwierdzonych podatności, wskaźnik duplikatów, medianę czasu triage, czas usunięcia problemu i obciążenie osób dokonujących przeglądu.

Program może otrzymywać więcej raportów, stając się jednocześnie mniej skuteczny. I odwrotnie, bardziej rygorystyczne przyjmowanie zgłoszeń może zmniejszyć ich wolumen, zwiększając udział poważnych ustaleń trafiających do opiekunów.

Pauza Google OSS VRP powinna być zatem oceniana przez pryzmat tego, co ją zastąpi. Zamknięcie przeciążonej kolejki jest zrozumiałe, lecz trwały rezultat dla bezpieczeństwa wymaga zaufanej ścieżki dla prawidłowych raportów.

Co wydarzy się dalej w Google Open Source Bug Bounty

Trzy sygnały pokażą, czy pauza Google przekształci się w lepszy system ujawniania, czy w trwałe wycofanie się z otwartego uczestnictwa.

Pierwszym sygnałem będzie zapowiedziana przez Google aktualizacja w pierwszym kwartale 2027 roku. Najważniejsze szczegóły będą dotyczyć kwalifikowalności, standardów dowodowych, automatycznego przesiewania i procedur odwoławczych.

Ponowne otwarcie z jasnymi wymogami reprodukcji wzmocniłoby argument, że Google wykorzystał pauzę do przeprojektowania procesu przyjmowania zgłoszeń. Bezterminowe przedłużenie sugerowałoby, że otwarte składanie zgłoszeń nadal jest ekonomicznie trudne.

Warto obserwować, czy Google będzie wymagać od zgłaszających dostarczenia wykonywalnych testów, dotkniętych zmian w kodzie, śladów wykorzystania podatności lub proponowanych poprawek. Takie zasady przesunęłyby odpowiedzialność na badaczy bez zakazywania pomocy AI.

Drugim sygnałem będzie wskaźnik potwierdzonych raportów po ewentualnym ponownym otwarciu. Google nie opublikował aktualnego punktu odniesienia, dlatego przejrzystość dotycząca przyszłych wskaźników poprawności i duplikatów pomogłaby ocenić nowy system.

Wyższy wskaźnik potwierdzeń przy stabilnym dostępie do ujawniania wspierałby bardziej rygorystyczne filtrowanie. Gwałtowny spadek uczestnictwa mógłby wskazywać, że bariery wykluczają uzasadnionych badaczy wraz ze spamem.

Znaczenie ma również czas triage. Jeśli osoby dokonujące przeglądu będą mogły szybciej oceniać wiarygodne raporty, Google uzyska dowody, że przeprojektowanie ograniczyło ukrytą pracę, a nie tylko widoczny wolumen.

Trzecim sygnałem będzie reakcja innych projektów i platform. Curl usunął nagrody, Linux przekierował zautomatyzowane ustalenia, a Google wstrzymał jedną kategorię zgłoszeń.

Jeśli więcej programów przyjmie zweryfikowane reprodukcje, wymogi dostarczania poprawek lub progi reputacyjne, praktyki te mogą stać się domyślnym standardem ujawniania wspomaganego przez AI.

Platformy mogą również budować wspólne mechanizmy obronne. Wykrywanie duplikatów między programami, ustandaryzowane dowody odczytywalne maszynowo i rozliczalne tożsamości agentów mogłyby ograniczyć powtarzalną pracę.

Najbardziej konstruktywny rezultat oddzieliłby skalę wykrywania od skali składania zgłoszeń. Badacze mogliby szeroko uruchamiać agentów, lecz do kolejek ludzkiej weryfikacji trafiałyby wyłącznie zwalidowane i pozbawione duplikatów ustalenia.

Ten model wymaga odpowiedzialności na każdym etapie przekazania. Twórcy narzędzi muszą projektować pod kątem weryfikacji, badacze muszą testować ustalenia, platformy muszą starannie filtrować, a opiekunowie potrzebują jasnych ścieżek eskalacji.

Programiści korzystający z narzędzi bezpieczeństwa AI powinni już teraz zachowywać się tak, jakby te zasady istniały. Powinni odtwarzać każde twierdzenie, rozumieć dotknięty kod, sprawdzać publiczną historię zgłoszeń i dokumentować realistyczny wpływ.

Powinni również pozostawać dostępni po wysłaniu zgłoszenia. Zgłaszający, który nie potrafi odpowiedzieć na podstawowe pytania techniczne, przenosi cały koszt dochodzenia na projekt.

Dla firm lekcja wykracza poza programy nagród za błędy. Każdy publiczny system przyjmowania zgłoszeń może zostać przeciążony, gdy AI czyni generowanie treści tanim, a ocena pozostaje kosztowna.

Kolejki wsparcia, podania o pracę, programy grantowe, pull requesty i raporty zgodności mierzą się z tą samą podstawową nierównowagą. Rzadkim zasobem nie jest już pisanie. Jest nim zaufana weryfikacja.

Pauza Google w programie nagród za błędy w open source uwidacznia tę nierównowagę w środowisku o wysokiej stawce. Fałszywy raport bezpieczeństwa marnuje czas, podczas gdy pominięta rzeczywista podatność może narazić miliony użytkowników korzystających z produktów zależnych.

Wyzwanie nie polega na wyborze między AI a ludzkimi badaczami. Polega na zaprojektowaniu systemu ujawniania, w którym automatyzacja zwiększa zweryfikowaną pracę na rzecz bezpieczeństwa, zamiast mnożyć niepoparte twierdzenia.

Google ma teraz czas do kolejnej aktualizacji, aby pokazać, jak wygląda taki system. Czy ponownie otworzy program, wprowadzając silniejsze bramki dowodowe i realny dostęp, czy też otwarte uczestnictwo będzie nadal zawężane wraz ze wzrostem liczby raportów?