Zawieszenie Google OSS VRP pokazuje, że zgłoszenia błędów AI mają problem z weryfikacją

Google zawiesił 1 października jedną kategorię swojego programu nagród za luki w oprogramowaniu open source, ponieważ nieprawidłowe zgłoszenia generowane przez AI miały podobno przeciążyć proces ich weryfikacji.

Zawieszenie Google OSS VRP wstrzymuje przyjmowanie nowych zgłoszeń „Product Vulnerability”, podczas gdy firma przeprojektowuje tę część programu. Google spodziewa się przekazać aktualizację w pierwszym kwartale 2027 roku.

Decyzja nie zamyka wszystkich programów Google dotyczących luk w zabezpieczeniach. Nie zabrania też badaczom wykorzystywania sztucznej inteligencji do analizowania kodu.

Ujawnia natomiast narastający konflikt między automatycznym wykrywaniem a ludzką weryfikacją. AI potrafi generować potencjalne odkrycia znacznie szybciej, niż opiekunowie projektów są w stanie je odtworzyć, ocenić i naprawić.

Działanie Google następuje po miesiącach rosnącej presji w całym obszarze bezpieczeństwa open source. Opiekunowie Linuksa i innych projektów mierzyli się z podobnymi falami zduplikowanych, spekulatywnych lub słabo przetestowanych zgłoszeń.

Ten szerszy schemat ma większe znaczenie niż jeden wstrzymany formularz zgłoszeniowy. Programy bezpieczeństwa tradycyjnie nagradzają badaczy za znajdowanie problemów przeoczonych przez wewnętrzne zespoły. AI zmienia ten model, ponieważ sprawia, że generowanie potencjalnych kandydatów staje się wyjątkowo tanie.

Deficytowym zasobem nie jest już początkowe podejrzenie. Jest nim uwaga ekspertów potrzebna do udowodnienia, że wada jest osiągalna, możliwa do wykorzystania i istotna dla rzeczywistego modelu zagrożeń.

Co faktycznie zmienia zawieszenie Google OSS VRP

Google wstrzymał jedną kategorię zgłoszeń, a nie porzucił badań nad lukami w oprogramowaniu open source ani nie zamknął całej działalności związanej z nagrodami.

Open Source Software Vulnerability Reward Program, znany jako OSS VRP, obejmuje kwalifikujące się problemy bezpieczeństwa w należących do Google repozytoriach open source. Google uruchomił ten program w 2022 roku.

Zgłoszenia luk w produkcie wskazują wady w kodzie, logice lub projekcie danego projektu. Prawidłowe zgłoszenie musi robić więcej niż tylko wskazywać podejrzany fragment kodu.

Badacze zasadniczo muszą wykazać wersję, której dotyczy problem, osiągalną ścieżkę wykonania, kroki reprodukcji oraz istotną konsekwencję dla bezpieczeństwa. Wymagania te odróżniają luki możliwe do wykorzystania od zwykłych błędów programistycznych.

Według szczegółów zawieszenia, przerwa weszła w życie, gdy Google ogłosił ją 1 października. Zgłoszenia luk w produkcie przesłane przed tą datą nadal mogą zostać rozpatrzone.

Otwarte pozostają również zgłoszenia dotyczące łańcucha dostaw. Dotyczą one naruszeń wpływających na sposób, w jaki zależności programowe, kod źródłowy, kompilacje lub wydania trafiają do użytkowników.

Niektóre luki dotyczące produktów Google Cloud mogą nadal kwalifikować się w ramach odrębnego Cloud VRP. Kwalifikacja zależy od repozytorium i jego związku z objętym programem produktem chmurowym.

Badacze mogą także uczestniczyć w innych programach nagród Google. Obejmują one programy dotyczące Chrome, Androida, urządzeń Google, usług chmurowych oraz wyspecjalizowanych problemów bezpieczeństwa AI.

To rozróżnienie zakresu jest istotne. Opisywanie tego kroku jako całkowitego zamknięcia wyolbrzymiałoby wydarzenie i zaciemniałoby bardziej precyzyjną reakcję Google.

Firma faktycznie zamyka kanał przyjmujący dużą liczbę zgłoszeń, pozostawiając dostępne węższe ścieżki. Planuje przeformatować ten kanał, zanim omówi jego przyszłość.

Dokładny model zastępczy pozostaje nieznany. Google nie podał publicznie, czy wprowadzi silniejsze wymogi dotyczące tożsamości, reprodukcji, limitów zgłoszeń lub dowodów.

Google zaostrzył zasady programu już przed zawieszeniem. Jego zasady OSS VRP wymagały od badaczy weryfikacji odkryć wspomaganych przez AI oraz wykazania rzeczywistego wpływu na bezpieczeństwo.

Zasady opisywały kilka powtarzających się problemów. Niektóre raporty generowane przez AI zawierały błędne warunki wyzwalające lub wymyślone szczegóły techniczne.

Inne zgłoszenia identyfikowały rzeczywiste błędy w kodzie, lecz nie wykazywały konsekwencji dla bezpieczeństwa. Na przykład przepełnienie bufora może istnieć wyłącznie w nieosiągalnym kodzie lub za skuteczną granicą bezpieczeństwa.

Google zakończył także wypłacanie nagród pieniężnych i przyznawanie publicznego uznania za niektóre luki w produktach niższego poziomu oraz inne problemy bezpieczeństwa. Ta zmiana z kwietnia 2026 roku miała usunąć zachęty do zgłoszeń o niewielkim wpływie.

Późniejsze zawieszenie sugeruje, że te węższe mechanizmy kontroli nie zmniejszyły wystarczająco obciążenia związanego z weryfikacją. Google przeszedł od zniechęcania do słabych zgłoszeń do czasowego odmawiania przyjmowania tej kategorii.

Zawieszenie Google OSS VRP jest więc decyzją operacyjną. Recenzenci programu nie mogli już traktować każdej zgłoszonej możliwości jako przystępnego punktu wyjścia.

Zgłoszenia błędów AI zmieniły koszt wysunięcia twierdzenia

AI obniża koszt twierdzenia, że istnieje luka, nie obniżając kosztu jej udowodnienia.

Tradycyjne badania nad lukami wymagały znacznego wysiłku ręcznego, zanim badacz mógł przygotować wiarygodne zgłoszenie. Musiał przeanalizować kod, zrozumieć ścieżki wykonania i zbudować test.

Nowoczesne modele językowe i autonomiczni agenci kodowi potrafią znacznie szybciej skanować repozytoria i generować hipotezy. Mogą też tworzyć dopracowane raporty przypominające staranną analizę człowieka.

Ten pozór tworzy niebezpieczną asymetrię. Wygenerowanie przekonującego dokumentu może zająć sekundy, podczas gdy obalenie jego twierdzeń może pochłonąć godziny pracy specjalistów.

Raport może wskazać podejrzaną operację pamięci i przewidzieć zdalne wykonanie kodu. Model może następnie stworzyć szczegółową narrację ataku wokół tej prognozy.

Jednak funkcja, której dotyczy problem, może nigdy nie przetwarzać danych kontrolowanych przez atakującego. Kompilator może wyeliminować tę ścieżkę albo istniejąca walidacja może zablokować proponowany wyzwalacz.

Model zagrożeń projektu może także wykluczać zakładane uprawnienia atakującego. W każdym z tych przypadków zgłoszenie brzmi poważnie, lecz nie dowodzi istnienia luki.

Opiekunowie projektów nie mogą bezpiecznie odrzucać na pierwszy rzut oka każdego zautomatyzowanego zgłoszenia. Słabo napisane zgłoszenie może nadal zawierać rzeczywistą wadę, podczas gdy dopracowane może być całkowicie spekulatywne.

Recenzenci muszą przeanalizować kod, odtworzyć środowisko, przetestować deklarowane dane wejściowe i ocenić istniejące zabezpieczenia. Mogą również potrzebować skontaktować się ze zgłaszającym w sprawie brakujących dowodów.

Obciążenie to rośnie wraz z każdym raportem, w tym nieprawidłowym. Zautomatyzowane zgłoszenia przenoszą zatem koszt walidacji ze zgłaszających na opiekunów projektów.

Efekt przypomina bardziej spam e-mailowy niż tradycyjne badania bezpieczeństwa. Wysłanie kolejnej wiadomości niemal nic nie kosztuje, lecz odbierające ją organizacje nadal muszą filtrować każde potencjalnie istotne twierdzenie.

Nagrody finansowe mogą nasilać tę nierównowagę. Jeśli jeden zaakceptowany wynik pokrywa koszt wygenerowania tysięcy zgłoszeń, duży wolumen staje się racjonalną strategią dla słabszych uczestników.

Takie zachowanie szkodzi badaczom wykonującym staranną pracę. Ich odkrycia trafiają do tej samej kolejki i konkurują o uwagę tych samych recenzentów.

Szkodzi też użytkownikom, gdy opiekunowie projektów poświęcają mniej czasu na naprawianie potwierdzonych luk. Triage staje się wąskim gardłem, zanim naprawa w ogóle może się rozpocząć.

Problem nie polega wyłącznie na tym, że modele halucynują. Ludzcy badacze także popełniają błędy, wyolbrzymiają wpływ i przesyłają duplikaty.

AI zmienia skalę, tempo i formę prezentacji tych błędów. Pozwala jednej osobie tworzyć więcej wiarygodnie brzmiących twierdzeń, niż jest ona w stanie osobiście zweryfikować.

To rozróżnienie wyjaśnia, dlaczego zakaz prozy generowanej przez AI niewiele by rozwiązał. Badacz mógłby przeredagować nieweryfikowany wynik modelu i przesłać to samo niepoparte dowodami twierdzenie.

Programy potrzebują zamiast tego bramek opartych na dowodach. Istotne pytanie brzmi, czy zgłaszający przetestował wynik, a nie czy model przyczynił się do jego wykrycia.

Przerwa ogłoszona przez Google sygnalizuje, że istniejące zasady firmy nie były w stanie skutecznie egzekwować tego rozróżnienia. Pisemne wymagania łatwiej było opublikować niż stosować wobec uprzemysłowionej skali zgłoszeń.

Strategia bezpieczeństwa AI Google staje wobec własnego kompromisu

Google promuje wspomagane przez AI wykrywanie problemów bezpieczeństwa, lecz jego program nagród nie jest w stanie przyjąć każdego odkrycia powstałego w tej samej fali automatyzacji.

Zawieszenie Google OSS VRP nie oznacza, że firma uważa AI za bezużyteczną w bezpieczeństwie. Google nadal inwestuje w automatyczne wykrywanie luk i ich naprawianie.

Zespoły bezpieczeństwa firmy korzystają z narzędzi takich jak OSS-Fuzz, Big Sleep i CodeMender. Systemy te łączą zautomatyzowaną analizę z kontrolowanymi testami i ekspercką oceną.

Google przeprojektował także programy nagród dotyczące Androida i Chrome z myślą o tym, co nazywa erą AI. Firma oczekuje, że automatyzacja ujawni luki pomijane przez konwencjonalne badania.

To sprawia, że zawieszenie jest znaczącym zwrotem. Google nie wycofuje się z badań nad bezpieczeństwem AI, lecz ogranicza zewnętrzny kanał dotknięty niższymi kosztami przesyłania zgłoszeń dzięki AI.

Kluczowy podział nie przebiega między badaniami ludzi a badaniami maszyn. Chodzi o automatyzację zweryfikowaną wewnętrznie oraz zewnętrznie przesyłane twierdzenia o nierównym poziomie walidacji.

Google kontroluje środowisko własnych systemów. Inżynierowie mogą definiować cele, uruchamiać testy, zbierać awarie i mierzyć, czy wygenerowane poprawki zachowują działanie systemu.

Otwarty program nagród nie zapewnia takiej kontroli. Uczestnicy korzystają z różnych narzędzi, promptów, modeli, wersji kodu i definicji wpływu na bezpieczeństwo.

Recenzenci otrzymują końcowe twierdzenie, nie widząc każdego kroku, który do niego doprowadził. Muszą odtworzyć brakujące założenia, zanim zdecydują, czy odkrycie ma znaczenie.

Ta różnica sprawia, że pochodzenie staje się praktycznym problemem bezpieczeństwa. Zespoły muszą wiedzieć, która wersja została przetestowana, jakie dane wejściowe wywołały wynik i czy człowiek go odtworzył.

Szerszy system nagród Google nadal jest znaczący. Firma podała, że jej programy wypłaciły w 2025 roku ponad 17 mln dolarów ponad 700 badaczom.

Jej coroczny przegląd VRP opisał tę sumę jako najwyższą w historii. Kwota wzrosła o ponad 40 procent względem 2024 roku.

Liczby te pokazują, że Google nadal ceni badania zewnętrzne. Dowodzą też, dlaczego utrzymanie wiarygodnych kanałów zgłoszeniowych ma znaczenie.

Program nagród zależy od wzajemnego zaufania. Badacze muszą wierzyć, że prawidłowe odkrycia otrzymają sprawiedliwą uwagę, podczas gdy firmy muszą ufać, że zgłaszający testują swoje twierdzenia.

Niefiltrowana automatyzacja osłabia obie strony. Opóźnienia w weryfikacji frustrują kompetentnych badaczy, a powtarzające się nieprawidłowe zgłoszenia zwiększają sceptycyzm recenzentów wobec nieznanych współpracowników.

Reakcja Google chroni zdolność do triage, ale ogranicza też dostęp. Niezależni badacze nie mogą obecnie przesyłać zwykłych luk w produktach poprzez zawieszoną kategorię OSS VRP.

To ograniczenie może stłumić cenne odkrycia wraz z szumem. Nowy badacz z prawidłowo zidentyfikowanym problemem może nie mieć oczywistego alternatywnego programu.

Wyzwanie jest więc kompromisem między otwartością a weryfikacją. Szeroki dostęp zwiększa możliwości wykrywania, podczas gdy rygorystyczne bramki chronią ograniczony czas recenzentów.

Każdy przeprojektowany program musi zachować oba cele. Jeśli wymagania wejściowe staną się zbyt uciążliwe, Google ryzykuje skoncentrowanie udziału wśród uznanych badaczy i wyspecjalizowanych firm.

Jeśli wymagania pozostaną zbyt luźne, kolejka zgłoszeń może ponownie zostać przeciążona. Aktualizacja w pierwszym kwartale 2027 roku pokaże, gdzie Google wyznaczy tę granicę.

Zalew raportów AI jest problemem całej branży

Decyzja Google wpisuje się w szerszą zmianę, w której społeczności bezpieczeństwa przepisują zasady ujawniania informacji wokół automatycznego wykrywania.

HackerOne odnotował ponad 100-procentowy wzrost liczby raportów branżowych po pojawieniu się bardziej zaawansowanych narzędzi AI w lutym 2026 roku.

Jego analiza wolumenu raportów wykazała, że część zgłoszeń zawierała wartościowe odkrycia. Inne były duplikatami, twierdzeniami niemożliwymi do zweryfikowania lub raportami pozbawionymi użytecznej szczegółowości.

Platforma nie zareagowała zakazem odpowiedzialnego korzystania z pomocy AI. Zamiast tego wzmocniła obowiązek badacza dotyczący weryfikacji ustaleń i wykazania rzeczywistego wpływu.

Zasady HackerOne wymagają odtwarzalnego proof of concept, prawidłowej oceny istotności oraz uwzględnienia istniejących mechanizmów ochronnych. Duże partie niezweryfikowanych raportów mogą skutkować egzekwowaniem zasad.

Takie podejście przypisuje odpowiedzialność operatorowi, a nie narzędziu. Badacz nadal odpowiada za każdy wygenerowany endpoint, krok ataku i twierdzenie o wpływie.

Społeczność jądra Linuxa przyjęła podobne podejście skoncentrowane na dowodach. Jej zasady zgłaszania problemów bezpieczeństwa obecnie bezpośrednio odnoszą się do przeglądu kodu wspomaganego przez AI.

Dokumentacja wskazuje, że raporty AI często stają się nadmiernie długie i zaciemniają kluczowe fakty. Prosi zgłaszających o zwięzłe opisy, dotknięte rewizje, warunki wyzwalające oraz przetestowane reproduktory.

Linux ostrzega również, że narzędzia mogą wymyślać teoretyczny wpływ bez zrozumienia modelu zagrożeń jądra. Zamiast tego prosi zgłaszających o przedstawienie weryfikowalnych konsekwencji.

Projekt traktuje szeroko odtwarzalne, zautomatyzowane ustalenia inaczej niż tradycyjnie prywatne odkrycia. Wielu badaczy często znajduje ten sam problem, ponieważ używają podobnych narzędzi.

Tworzy to powieloną pracę w kanałach ujawniania podatności, które zaprojektowano z myślą o rzadkich, niezależnie odkrytych lukach. Automatyzacja zmienia założenia stojące za tymi kanałami.

Opiekun Curl, Daniel Stenberg, opisał inną wersję tego problemu w 2025 roku. Jego argument „death by a thousand slops” skupiał się na skumulowanym koszcie przeglądania słabych zgłoszeń.

Pojedynczy zły raport może wydawać się możliwy do opanowania. Powielanie tego kosztu w setkach wygenerowanych twierdzeń może jednak wyczerpać projekt utrzymywany przez wolontariuszy.

W tych przypadkach działa ten sam mechanizm. AI zwiększa podaż hipotez dotyczących podatności szybciej niż podaż wykwalifikowanej pracy triage.

Wpływ różni się między organizacjami. Google może przydzielić opłacanych inżynierów bezpieczeństwa, podczas gdy mniejsze projekty często zależą od wolontariuszy dysponujących ograniczonym czasem.

Opiekunowie projektów open source stoją przed szczególnie trudną strukturą bodźców. Publiczny kod łatwo trafia do zautomatyzowanych skanerów, lecz opiekunowie nie otrzymują proporcjonalnych zasobów.

Nagrody za błędy mogą wprowadzać kolejną nierównowagę. Firma może wynagradzać zaakceptowane ustalenia, podczas gdy opiekunowie społeczności obsługują początkowe dyskusje lub naprawy upstream bez wynagrodzenia.

Nie oznacza to, że zautomatyzowane badania są z natury szkodliwe. AI może analizować mało znane komponenty, tłumaczyć nieznany kod i pomagać badaczom tworzyć testy.

Może również poprawiać jakość raportów, gdy jest używana po weryfikacji. Model może uporządkować kroki reprodukcji lub wyraźniej wyjaśnić złożony przepływ sterowania.

Te same możliwości stają się destrukcyjne, gdy zastępują weryfikację. Wygenerowanie wiarygodnej narracji nie jest równoznaczne z wykazaniem warunku możliwego do wykorzystania.

Wyłaniający się konsensus branżowy zakłada więc warunkową akceptację. Pomoc AI pozostaje mile widziana, gdy człowiek może odtworzyć i obronić każde istotne twierdzenie.

Tymczasowe zamknięcie przez Google jest bardziej restrykcyjne niż ta zasada. Odzwierciedla jednak ten sam osąd dotyczący tego, gdzie musi spoczywać odpowiedzialność.

Osoba składająca raport musi ponieść wystarczający koszt walidacji, aby chronić odbiorcę. W przeciwnym razie program staje się zewnętrzną kolejką testową dla spekulacyjnych wyników maszynowych.

Silniejsze bramki mogą pomóc, ale wprowadzają nowe ryzyka

Przeprojektowany program musi uwzględniać koszt weryfikacji w każdym zgłoszeniu, nie wykluczając przy tym legalnych niezależnych badaczy.

Google nie ujawniło ostatecznego zastępstwa dla zgłoszeń podatności w produktach. Kilka mechanizmów kontroli pasowałoby do problemów wskazanych w jego wcześniejszych zasadach.

Pierwszym jest obowiązkowy, przetestowany reproduktor. Reproduktor dostarcza mały program, dane wejściowe lub procedurę, która konsekwentnie wywołuje deklarowane zachowanie.

Google mogłoby wymagać od zgłaszających podania dokładnej rewizji repozytorium i środowiska. Informacje te ograniczyłyby czas tracony na testowanie nieaktualnego lub niezgodnego kodu.

Raporty mogłyby również wymagać wyraźnego uzasadnienia osiągalności. Zgłaszający musiałby wykazać, w jaki sposób dane kontrolowane przez atakującego docierają do podatnej operacji.

Ustrukturyzowane pole modelu zagrożeń mogłoby zmusić badaczy do wskazania wymaganych uprawnień, granic zaufania i istniejących mechanizmów ograniczających ryzyko. Łatwiej byłoby wykrywać niepoparte twierdzenia o istotności.

Inną opcją są limity liczby zgłoszeń. Google mogłoby ograniczyć liczbę nierozstrzygniętych raportów, które jedno konto może przesłać w określonym okresie.

Zniechęciłoby to do zgłoszeń składanych na oślep, przy zachowaniu dostępu dla starannych badaczy. Wyższe limity mogłyby wynikać z historii zaakceptowanej pracy.

Depozyty lub wymogi reputacyjne mogłyby zapewnić silniejsze filtrowanie, lecz niosą większe ryzyko niesprawiedliwości. Nowi badacze mogliby mieć trudności z wejściem do programu.

Kolejnym prawdopodobnym elementem jest automatyczne wstępne filtrowanie. Google mogłoby wykorzystywać analizę statyczną, wykonywanie w sandboxie lub przegląd oparty na modelach do oznaczania duplikatów i brakujących dowodów.

Automatyczne filtrowanie nie może jednak bezpiecznie stać się ostatecznym autorytetem. Może odrzucać nietypowe, lecz prawidłowe badania albo faworyzować znane wzorce podatności.

Model oceniający raport innego modelu może także powielać te same błędne założenia. Niezależne dowody z wykonania pozostają cenniejsze niż zgodność tekstowa.

Prywatność i poufność tworzą dodatkowe komplikacje. Badacze mogą ujawniać niezałatane szczegóły zewnętrznym usługom AI, prosząc modele o analizę.

Zmieniony program mógłby wymagać ujawnienia użycia zewnętrznych modeli w związku z poufnymi ustaleniami. Mógłby także ograniczyć, jakie wrażliwe materiały trafiają do systemów hostowanych.

Google musi również wyjaśnić, jak opiekunowie open source uczestniczą w triage. Raport może dotyczyć repozytorium Google, jednocześnie nakładając pracę na szerszą społeczność współtwórców.

Firma powinna unikać rozwiązywania problemu własnej kolejki przez przenoszenie obowiązków weryfikacyjnych upstream. Przeniosłoby to ciężar, zamiast go zmniejszyć.

Przejrzystość będzie istotna podczas przerwy. Google nie opublikowało szczegółowego zestawienia zaakceptowanych, zduplikowanych, nieważnych i wspomaganych przez AI raportów.

Tom’s Hardware opisał inżynierów i opiekunów mierzących się z tysiącami słabych zgłoszeń. Opublikowane przez Google zawiadomienie nie podało jednak dokładnego wolumenu ani wskaźnika akceptacji.

To rozróżnienie ogranicza wnioski, jakie mogą wyciągać osoby z zewnątrz. Dostępne dowody potwierdzają poważny problem jakościowy, lecz nie zapewniają pełnego obrazu ilościowego.

Google powinno opublikować wystarczającą ilość danych zbiorczych, aby wyjaśnić przeprojektowane progi. Użyteczne miary obejmują medianę czasu przeglądu oraz udział raportów bez działających reproduktorów.

Istotne są także wskaźniki fałszywych odrzuceń. Szybsza kolejka nie jest sukcesem, jeśli wartościowe ustalenia znikają, ponieważ automatyczne filtry błędnie je klasyfikują.

Program powinien rozróżniać pomoc w odkrywaniu od autonomicznego składania zgłoszeń. Ustalenie AI sprawdzone przez człowieka może być wartościowe, podczas gdy nienadzorowany potok raportów tworzy niezarządzane ryzyko.

Najlepszy projekt Google sprawiłby, że dowód byłby tańszy do oceny niż proza. Testy odczytywalne maszynowo, ograniczone szablony i odtwarzalne środowiska mogłyby wspierać ten cel.

Firma powinna także zachować ścieżkę eskalacji dla niekonwencjonalnych ustaleń. Niektóre ważne podatności opierają się prostym przypadkom testowym lub obejmują złożone łańcuchy.

Żadna pojedyncza bramka nie zrównoważy tych wymagań. Prawdopodobną odpowiedzią jest warstwowy dostęp oparty na jakości dowodów, historii badacza i wykazanym wpływie na bezpieczeństwo.

Na co zwracać uwagę przed aktualizacją Google w I kwartale 2027 roku

Kolejny etap pokaże, czy Google zdoła ponownie otworzyć zgłoszenia z lepszymi standardami dowodowymi, zamiast po prostu przyjmować mniej badaczy.

Pierwszym sygnałem jest zakres programu zastępczego. Google musi wyjaśnić, czy zgłoszenia podatności w produktach zostaną w pełni ponownie otwarte, czy powrócą przez węższy kanał.

Pełne ponowne otwarcie sugerowałoby, że nowe filtry przywróciły zaufanie do procesu przeglądu. Ograniczony system zaproszeń wskazywałby, że zdolność triage nadal pozostaje ograniczona.

Drugim sygnałem są dowody wymagane od zgłaszających. Przetestowane reproduktory, dotknięte commity i konkretne ścieżki ataku byłyby odpowiedzią na słabości już zidentyfikowane przez Google.

Wymagania te wzmocniłyby program, jeśli pozostałyby dostępne. Osłabiłyby go, gdyby jedynie uznani badacze mogli spełniać niejasne standardy przeglądu.

Trzecim sygnałem jest reakcja innych programów bezpieczeństwa. HackerOne, Linux i najwięksi dostawcy eksperymentują z zasadami składania zgłoszeń uwzględniającymi AI.

Jeśli zbiegną się wokół odtwarzalności i ludzkiej odpowiedzialności, branża może wypracować wspólny punkt odniesienia. Mogłoby to ograniczyć dezorientację badaczy działających w różnych programach.

Jeśli natomiast programy przyjmą niezgodne ograniczenia, ujawnianie podatności stanie się trudniejsze. Badacze mogą potrzebować różnych pakietów dowodowych, polityk AI i praktyk poufności dla każdego celu.

Programiści powinni również obserwować same narzędzia. Lepsze agenty mogą tworzyć działające testy, lecz mogą też z większą pewnością generować nieważne dowody.

Kluczowym miernikiem nie jest liczba ostrzeżeń znalezionych przez agenta. Jest nim liczba niezależnie odtwarzalnych, istotnych dla bezpieczeństwa ustaleń, które przechodzą ekspercki przegląd.

Opiekunowie powinni śledzić czas poświęcony na każdą zaakceptowaną podatność, a nie surową liczbę zgłoszeń. Ta miara pokazuje, czy automatyzacja poprawia bezpieczeństwo, czy jedynie powiększa kolejkę.

Zespoły badawcze mogą przygotować się, dokumentując każdy etap pracy wspomaganej przez AI. Należy zapisywać przetestowany commit, konfigurację, logi, dane wejściowe i nieudane próby reprodukcji.

Zespoły potrzebują również przeszukiwalnego rejestru wcześniejszych ustaleń. Ustrukturyzowana baza wiedzy inżynierskiej może pomóc identyfikować duplikaty, zanim trafią one do opiekunów.

Badacze powinni umieć wyjaśnić błąd bez polegania na wygenerowanej prozie. Powinni wiedzieć, dlaczego ścieżka kodu jest osiągalna i który istniejący mechanizm kontroli zawodzi.

Jeśli brakuje takiego wyjaśnienia, ustalenie nadal jest hipotezą. Nie jest gotowe na program nagród za podatności.

Zawieszenie Google OSS VRP jest więc ostrzeżeniem dotyczącym projektowania przepływu pracy, a nie werdyktem przeciwko badaniom bezpieczeństwa AI. Odkrywanie przyspieszyło, lecz weryfikacja nie zniknęła.

Aktualizacja Google w I kwartale 2027 roku sprawdzi, czy duży dostawca może odbudować otwarty program wokół tej rzeczywistości. Najlepszy wynik nie zmaksymalizuje liczby zgłoszeń.

Zmaksymalizuje zweryfikowaną wartość bezpieczeństwa na godzinę uwagi recenzenta. Ten standard daje poważnym badaczom jasny cel i chroni opiekunów przed spekulacyjnym wolumenem.

Przed zgłoszeniem gdziekolwiek ustalenia wspomaganego przez AI zadaj trzy pytania. Czy inna osoba może je odtworzyć, czy przekracza ono rzeczywistą granicę bezpieczeństwa oraz czy przetestowano każde główne twierdzenie?

Jeśli na którekolwiek pytanie odpowiedź brzmi „nie”, kontynuuj badanie. Raport najtańszy do wygenerowania może stać się dla opiekuna najdroższym do obalenia.