AI pomogło Chrome naprawić 1072 luki. Teraz wyzwaniem jest dostarczenie poprawek

Google poinformowało, że Chrome 149 i 150 naprawiły łącznie 1072 błędy bezpieczeństwa — więcej niż poprzednie 23 główne wydania razem. Skala nie oznacza nagłego załamania jakości. Jest skutkiem użycia agentów AI do wyszukiwania podatności, automatyzacji triage, generowania kandydatów poprawek i pisania testów.

Odkrycie błędu to jednak początek wyścigu. Poprawka musi przejść review, testy, wydanie, pobranie i aktywację na urządzeniu użytkownika. Google pilotażowo zwiększa częstotliwość aktualizacji bezpieczeństwa do dwóch tygodniowo i pracuje nad dynamicznym podmienianiem procesów przeglądarki bez pełnego restartu.

1072 naprawy nie są 1072 aktywnymi zero-day

W raporcie zespołu Chrome Security liczba dotyczy błędów bezpieczeństwa naprawionych w dwóch stabilnych kamieniach milowych. Nie mówi, że każdy błąd był:

znany atakującym;
możliwy do wykorzystania zdalnie;
krytyczny;
używany w rzeczywistych atakach;
znaleziony wyłącznie przez AI.

Do wykrywania nadal służą fuzzing, badacze zewnętrzni, Project Zero, DeepMind i wewnętrzne zespoły. AI zwiększa przepustowość systemu, ale nie zastępuje wszystkich metod. Google zaznacza, że klasyczny fuzzing pozostaje szczególnie skuteczny w błędach wynikających z długich interakcji między odległymi częściami kodu.

Właściwa interpretacja liczby brzmi: zespół potrafi teraz przetworzyć znacznie większy strumień potencjalnych problemów. To sukces dopiero wtedy, gdy walidacja zachowa jakość, a poprawki dotrą do użytkowników.

Trzynastoletni sandbox escape znaleziony przez Gemini

Na początku 2026 roku Google zbudowało harness agentowy wykorzystujący Gemini do analizy szerszej bazy kodu Chrome. Jednym z wyników był błąd istniejący przez ponad 13 lat. Skompromitowany renderer mógł nakłonić proces przeglądarki do odczytu lokalnych plików, czyli przekroczyć granicę sandboxu.

Ten przypadek pokazuje wartość analizy semantycznej. Podatność może nie polegać na oczywistym niebezpiecznym wywołaniu. Może powstać na styku założeń kilku komponentów, gdzie każdy fragment osobno wygląda poprawnie.

Google wzbogaciło harness o:

możliwość używania modeli własnościowych i open-weight;
bazę wcześniejszych CVE oraz pełną historię Git Chrome;
pliki SECURITY.md opisujące granice zaufania;
osobnego agenta-krytyka z niezależnym kontekstem;
wielokrotne przebiegi uwzględniające niedeterministyczność modelu.

To ważna wskazówka dla firm budujących własne skanery AI: model potrzebuje mapy granic bezpieczeństwa. Bez niej może znaleźć anomalię składni, ale źle ocenić realny wpływ.

Harness nie dostał swobodnego internetu

Zespół Chrome opisuje także zabezpieczenia samego procesu. Modele analizują kod w spoczynku na zablokowanych maszynach bez ogólnego dostępu do internetu. Ruch sieciowy jest przechwytywany i dopuszczany na podstawie ścisłej allowlisty aplikacji oraz celu.

Subagenci nie mogą dowolnie zmieniać systemu ani czytać plików poza wyznaczonymi katalogami źródłowymi. To praktyczne zastosowanie zasady, że agent bezpieczeństwa nadal jest uprzywilejowanym programem i wymaga egzekwowanej izolacji.

Kontrole te są szczególnie istotne, bo narzędzie analizuje niepubliczny kod i informacje o niewydanych podatnościach. Wyciek wyniku skanowania mógłby skrócić napastnikowi drogę do exploita przed dostarczeniem poprawki.

Cztery etapy automatycznej triage

Wąskim gardłem po odkryciu setek kandydatów jest ocena. Historycznie triage jednego zgłoszenia zajmowała od 5 do ponad 30 minut pracy eksperta. Google dzieli zautomatyzowany proces na cztery fazy:

Filtrowanie szumu — spam, duplikaty i zgłoszenia niespełniające kryteriów odpadają.
Reprodukcja — system sprawdza PoC na właściwym systemie i wersji, dodając m.in. stack trace.
Wzbogacenie — ustala moment wprowadzenia błędu, komponent i proponowaną ważność.
Przypisanie — kieruje problem do właściwego właściciela-człowieka.

Deweloper może zmienić ocenę ważności i dodać kontekst. To rozsądny podział: automatyzacja przygotowuje powtarzalne dowody, ale decyzja o granicy zaufania i ryzyku nie jest nieodwołalną odpowiedzią modelu.

Google szacuje oszczędność na setki godzin deweloperskich miesięcznie. Jest to szacunek firmy, nie niezależny pomiar.

Agent tworzy poprawkę, krytyk ją podważa

W procesie naprawy pierwszy agent generuje kilka kandydatów zmiany. Osobny agent-krytyk porównuje je z konwencjami Chromium, stylem i oczekiwanym zachowaniem. Oba systemy pracują iteracyjnie, a kolejne agenty tworzą testy dla wspieranych platform.

Na końcu nadal występuje review dewelopera. Ten układ ma przewagę nad jedną odpowiedzią LLM: rozdziela tworzenie od oceny i zmusza system do pokazania alternatyw.

Sama liczba wygenerowanych patchy nie jest metryką bezpieczeństwa. Lepszy zestaw obejmuje:

odsetek poprawnych reprodukcji;
false positive i false negative;
regresje po wdrożeniu;
czas od zgłoszenia do poprawki;
czas od poprawki do aktywacji u użytkownika;
ponownie otwarte błędy;
podatności wynikające z samej poprawki.

Ponad 20 błędów zatrzymanych przed produkcją

Narzędzia Big Sleep i CodeMender są zintegrowane z CI i uruchamiane co 24 godziny na zmianach kodu. Według Google w samym maju zatrzymały ponad 20 podatności przed wejściem do produkcji, w tym jeden problem oznaczony jako krytyczny S1+.

To bardziej wartościowy punkt kontroli niż okresowy skan całego repozytorium. Im bliżej momentu wprowadzenia zmiany wykryto problem, tym mniejszy koszt diagnozy i mniejsza szansa, że podatność zostanie skopiowana do kolejnych gałęzi.

Model ma też szukać ryzyka złożonego: kod bezpieczny w izolacji może stać się niebezpieczny po zmianie logiki w innym komponencie. Tradycyjna analiza statyczna oparta na znanych regułach często ma trudność z takim znaczeniem między modułami.

Patch gap: publiczny kod wyprzedza aktualizację użytkownika

Po włączeniu poprawki do publicznego Chromium napastnicy mogą porównać kod i odtworzyć przyczynę błędu. Stabilny Chrome może otrzymać zmianę później, a użytkownik aktywuje ją dopiero po restarcie. Ten czas to patch gap.

Google przechodzi w kierunku dwutygodniowych głównych wydań i tygodniowych aktualizacji bezpieczeństwa, a dodatkowo pilotażowo testuje dwie poprawki bezpieczeństwa tygodniowo. Większa częstotliwość ogranicza okno, ale zwiększa presję na automatyczne testy i kontrolę regresji.

Dla administratora ważna jest wersja działającego procesu, nie informacja, że pakiet został pobrany. Fleet może raportować „aktualizacja dostępna”, podczas gdy wrażliwa instancja przeglądarki pozostaje otwarta przez wiele dni.

Dynamiczne łatanie bez pełnego restartu

Chrome ma architekturę wieloprocesową. Google rozwija mechanizm, który kolejno podmienia w tle procesy potomne, takie jak renderer i GPU, na nowe binaria. Większość poprawek mogłaby zacząć działać bez zamknięcia całej przeglądarki.

To funkcja badawczo-rozwojowa, nie obietnica, że każda aktualizacja już dziś działa bez restartu. Niektóre zmiany nadal mogą wymagać wymiany procesu głównego, migracji stanu albo pełnego ponownego uruchomienia.

Chrome 150 na macOS wykorzystuje już moment, gdy wszystkie okna są zamknięte, ale aplikacja pozostaje w tle, aby automatycznie wykonać oczekujący restart. Google bada też dokładniejsze przywracanie sesji i inne „dogodne momenty”.

Bezpieczeństwo pamięci nadal jest fundamentem

AI znajduje błędy szybciej, ale najtrwalszym celem jest usunięcie całych klas podatności. Chrome rozwija zabezpieczenia C++ takie jak MiraclePtr, MiracleObject, std::span, sprawdzaną arytmetykę i dodatkową segmentację sterty.

Według Google 97% kodu Chrome tworzonego bezpośrednio przez projekt kompiluje się już bez ostrzeżeń ścisłego trybu unsafe-buffer. Długofalowo nowe i szczególnie ryzykowne komponenty, takie jak parsery, kodeki obrazów i fonty, mają być przenoszone do Rust.

Skala zależności pozostaje ogromna: ponad 2300 projektów zewnętrznych w Chromium i projektach satelitarnych, z czego około 1700 trafia w jakiejś formie do użytkowników. Dlatego automatyzacja aktualizacji zależności i sygnały o ryzyku dostawców są równie ważne jak naprawa własnego C++.

Co powinien zrobić zespół IT

Google zaleca administratorom m.in. politykę RelaunchNotification, która stopniowo przechodzi od przypomnienia do wymuszonego restartu. W środowiskach wymagających dłuższej walidacji dostępny jest kanał Extended Stable, a dashboard Chrome Enterprise pomaga śledzić wersje.

Praktyczna polityka powinna definiować:

maksymalny czas od publikacji poprawki do wdrożenia;
krótszy termin dla aktywnie wykorzystywanych luk;
sposób objęcia urządzeń poza biurem;
widoczność działającej wersji, nie tylko stanu instalatora;
wymuszony restart po okresie ostrzegawczym;
wyjątki z właścicielem, uzasadnieniem i datą końcową;
oddzielną kontrolę uprzywilejowanych stacji administratorów.

Fakty a wnioski Breachroad

Google potwierdza 1072 naprawione błędy w Chrome 149 i 150, trzynastoletni sandbox escape, architekturę agentów, zabezpieczenia harnessu, ponad 20 błędów zatrzymanych w maju oraz rozwój częstszych wydań i dynamicznego patchingu.

Breachroad wnioskuje, że najważniejszą metryką programu AI nie jest liczba znalezionych błędów, tylko czas do bezpiecznej aktywacji poprawki. Automatyzowanie wyłącznie odkrywania tworzy kolejkę. Dojrzały system skaluje także reprodukcję, review, testy, release i aktualizację urządzeń — z człowiekiem odpowiedzialnym za decyzje wysokiego wpływu.

Szkolenia z bezpiecznego wdrażania AI pokazują, jak izolować agentów, oceniać wyniki i budować kontrolę człowieka. Szkolenia cyberbezpieczeństwa dla zespołów technicznych pomagają przełożyć szybkie wydania na działający proces aktualizacji i reagowania.