Wygląda jak łatka

Przez dwa miesiące opisywaliśmy teksturę zdolności AI z dwóch stron. Najpierw znajdowanie: model wykrył błąd w serwerze proxy tkwiący tam od 1997 roku, ale przeoczył bliźniaczy wyścig w jądrze, bo ten istniał wyłącznie w czasie. Potem pisanie: modele nauczyły się kodu odpornego na iniekcje, a wciąż nie umieją odpowiedzieć, czy ten użytkownik ma prawo do tych danych.

Za każdym razem granica biegła w tym samym miejscu: między tym, co da się rozstrzygnąć lokalnie, a tym, co wymaga rozumowania o całości.

6 sierpnia 1Password opublikował badanie trzeciej strony tego samego zagadnienia — naprawiania. Wynik potwierdza tę granicę po raz trzeci, ale przy okazji odbiera pewną nadzieję, którą można było mieć po dwóch poprzednich.

Bo naturalna odpowiedź na to, że znajdowanie luk kosztuje dwadzieścia pięć dolarów, brzmiała: skoro odkrywanie tanieje, zautomatyzujmy naprawianie i przepaść się zamknie. Badanie mówi, że ta droga jest na razie zamknięta — i pokazuje dlaczego.

Sześć tysięcy łatek, jedna czwarta udanych

Badacze wygenerowali i ocenili 6080 łatek dla sześciu świeżo ujawnionych podatności. Około jednej czwartej naprawiło błąd czysto, bez skutków ubocznych. Mniej więcej 46 procent zamknęło samą podatność, ale znaczna część zrobiła to, wprowadzając przy okazji nowe problemy.

Trzeba przy tym rozumieć, na czym polega różnica między tymi dwiema liczbami, bo to ona jest sednem. Łatka może zamknąć zgłoszony błąd i jednocześnie otworzyć inny w tej samej funkcji pomocniczej. Formalnie działa. Praktycznie przenosi problem gdzie indziej.

Do tego dochodzi kategoria, którą badacze nazwali kruchością. Ponad jedna trzecia łatek ocenionych jako udane została dodatkowo tak oznaczona: blokowały zademonstrowany atak wąskim sprawdzeniem, zostawiając podatny kod dokładnie tam, gdzie był — osiągalny w chwili, gdy ktoś znajdzie inną drogę dojścia.

Najbardziej wymowny jest jednak przypadek jednego z serwerów WWW użytego w badaniu. Wygenerowano do niego 270 łatek. Sto czternaście uznano za zamykające pierwotny błąd. I wszystkie sto czternaście wprowadziło nowe problemy.

Warto dodać, że opiekunowie tego projektu odrzucili zaproponowaną łatkę i napisali własną, która naprawiała wszystkie trzy wystąpienia błędu — nie jedno. A potem okazało się, że również ta poprawka, autorstwa ludzi, otworzyła nowy sposób na przewrócenie serwera, znaleziony później przez inny zespół. To jest szczegół, który warto zapamiętać, zanim wyciągniemy z tego badania zbyt proste wnioski o wyższości człowieka.

Ten sam podział, po raz trzeci

Dlaczego modele zawodzą akurat w ten sposób? Wyjaśnienie podane przez badaczy jest krótkie i domyka naszą tezę precyzyjniej, niż mogliśmy sami sformułować.

Gdy modelowi poda się dowód działania podatności — konkretne złośliwe wejście, które demonstruje problem — łata ścieżkę kodu tego konkretnego wejścia. Człowiek czyta ten sam dowód inaczej: jako jeden przykład ogólniejszego problemu, który zapewne występuje też gdzie indziej. Modele tego nie robiły.

Zatrzymajmy się przy tym, bo to jest dokładnie ta sama granica, którą opisywaliśmy dwukrotnie.

Przy Bad Epoll model znalazł błąd zapisany wprost w kodzie i przeoczył ten, który istniał wyłącznie w splocie zdarzeń w czasie — bo jednego dało się zobaczyć lokalnie, a drugiego nie. Przy badaniu kodu generowanego przez AI modele opanowały iniekcje, bo poprawność zapytania da się rozstrzygnąć w jednej linijce, a zawodziły przy autoryzacji, bo odpowiedź na pytanie „czy ten użytkownik ma prawo do tego obiektu" wymaga trzymania w głowie całej aplikacji.

Tutaj jest to samo: załatanie pokazanej ścieżki jest zadaniem lokalnym, a rozpoznanie, że ta ścieżka jest jednym z trzech wystąpień tej samej klasy błędu, wymaga spojrzenia na całość.

Trzy różne zadania — znajdowanie, pisanie, naprawianie — i za każdym razem ta sama linia demarkacyjna. To już nie jest obserwacja z pojedynczego badania. To jest właściwość, którą można planować.

Nic nie wygląda źle

Jest w tym badaniu element, który czyni je groźniejszym, niż wynikałoby z samych procentów, i który wraca u nas raz za razem w zupełnie różnych kontekstach.

Badacze formułują to jednym zdaniem: nic w łatce, która zostawia błąd otwarty, nie sygnalizuje, że coś jest nie tak.

Łatka wygenerowana przez model czyta się jak łatka, którą napisałby opiekun projektu. Jest w stylu tego kodu, ma sensowną strukturę, komentarze na miejscu. Gdy istnieje test, zwykle go przechodzi. Nie ma żadnego elementu, który wzbudziłby podejrzenie recenzenta — poza tym, że w trzech przypadkach na cztery coś w niej jest zepsute albo niedokończone.

To jest ta sama klasa problemu, którą opisywaliśmy przy kompromitacji łańcucha dostaw, gdzie zatruty pakiet miał ważny podpis i poprawne poświadczenie pochodzenia, i przy sekretach wyniesionych w czterdzieści minut, o których dwa i pół tysiąca firm do dziś nie wie. Za każdym razem mechanizm był ten sam: awaria bez sygnału. Wszystko wygląda poprawnie, kontrole przechodzą, nic się nie zapala.

Przy łataniu konsekwencja jest szczególnie niewygodna, bo koszt weryfikacji przewyższa oszczędność. Żeby odróżnić działającą łatkę od przekonująco wyglądającej, trzeba zrozumieć podatność na tyle dobrze, żeby samemu ocenić, czy zamknięto klasę, czy tylko przypadek. A jeśli ktoś to potrafi, to nie potrzebował modelu, żeby napisać poprawkę.

Zdanie, które jest najmocniejsze w całym badaniu

Dyrektor badań bezpieczeństwa 1Password podsumowuje jeden aspekt tych wyników w sposób, który wart jest osobnego akapitu.

Dla błędów nowych, spoza zbioru treningowego modeli, skuteczność łatania — jak to ujmuje — zeszła poniżej zera. Czyli w tej kategorii łatanie przez model nie jest po prostu mniej skuteczne. Jest szkodliwe: częściej pogarsza stan kodu, niż go poprawia.

To rozróżnienie jest istotne, bo wskazuje, gdzie ta technologia realnie działa, a gdzie nie. Model dobrze radzi sobie z klasami błędów, które widział tysiące razy, w projektach, których kod zna. Załamuje się przy tym, co świeże i nietypowe — czyli dokładnie przy tym, do czego chcielibyśmy go użyć, bo znanych, powtarzalnych błędów i tak łapią statyczne analizatory.

Uczciwie: ograniczenia i kontekst

Kilka rzeczy trzeba postawić rzetelnie, bo ta liczba — trzy na cztery — będzie krążyć w oderwaniu od warunków.

Najważniejsze zastrzeżenie podnoszą sami komentatorzy: testowano modele ogólnego przeznaczenia, konkretnie ChatGPT 5.5 i Claude Opus 4.8. Nie testowano nowszych modeli wyspecjalizowanych w cyberbezpieczeństwie, którymi producenci chwalą się od lipca. To ogranicza wnioski — możliwe, że model trenowany pod tę konkretną pracę wypada lepiej. Choć warto pamiętać, że przy każdym z tych ogłoszeń nagłówkowa liczba mierzyła coś węższego, niż sugerowała, więc do deklaracji o poprawie należy podchodzić z tą samą ostrożnością.

Badanie pochodzi od firmy zajmującej się bezpieczeństwem, co jest standardowym zastrzeżeniem — choć trudno wskazać, w jaki sposób producent menedżera haseł zarabia na tezie, że AI źle łata. Wyniki są przy tym zbieżne z niezależnym pomiarem Veracode dotyczącym kodu generowanego przez AI: średnia zdawalność bezpieczeństwa około 56 procent, czyli 44 procent zawiera lukę z listy najczęstszych klas podatności, z ogromnym rozrzutem między językami — Python przechodzi w 63 procentach, Java w 30.

Trzeba też zachować proporcję w drugą stronę. To nie jest argument za rezygnacją z AI przy pracy nad kodem. Jest argumentem przeciwko konkretnemu założeniu — że łatkę wygenerowaną przez model można traktować jak łatkę napisaną przez kompetentnego inżyniera i przepuścić przez ten sam, pobieżny przegląd.

Co z tego wynika dla obrońcy

Rzecz pierwsza jest praktyczna i dotyczy procesu przeglądu. Jeśli twój zespół używa modeli do generowania poprawek bezpieczeństwa, przegląd musi odpowiadać na inne pytanie niż zwykle. Nie „czy ta łatka wygląda poprawnie" — bo wygląda — tylko „czy zamyka klasę problemu, czy tylko pokazany przypadek". W praktyce oznacza to sprawdzenie, czy ten sam wzorzec nie występuje gdzie indziej w kodzie, i czy poprawka nie jest wąskim sprawdzeniem postawionym przed nietkniętym, podatnym fragmentem.

Rzecz druga wynika z kruchości. Łatka, która blokuje konkretny ładunek, a zostawia podatny kod osiągalny inną drogą, przechodzi wszystkie testy regresji i wszystkie sprawdzenia oparte na dowodzie działania podatności. Test odtwarzający zgłoszony atak nie jest dowodem, że luka została zamknięta — jest dowodem, że zamknięto tę jedną ścieżkę. To rozróżnienie warto wpisać w kryteria akceptacji poprawek.

Rzecz trzecia jest kalibracyjna i wynika z podziału na błędy znane i nowe. Tam, gdzie masz do czynienia z powtarzalną, dobrze udokumentowaną klasą podatności, wsparcie modelu ma sens i oszczędza czas. Tam, gdzie łatasz coś świeżo odkrytego, nietypowego albo we własnym, niepublicznym kodzie — traktuj wygenerowaną poprawkę jako punkt wyjścia do analizy, nie jako propozycję do zatwierdzenia.

Jedna myśl na koniec

Przez cały ten rok obserwowaliśmy, jak przepaść między odkrywaniem a naprawianiem się poszerza. Państwo przyznało to formalnie, uchylając nakaz łatania wszystkiego. Prognozy mówią o sześćdziesięciu sześciu tysiącach nowych podatności rocznie. Cena znalezienia łańcucha w najpopularniejszym oprogramowaniu świata spadła do dwudziestu pięciu dolarów.

Przez cały ten czas istniała nadzieja, która brzmiała rozsądnie: skoro ta sama technologia poszerza przepaść po jednej stronie, to zapewne zamknie ją po drugiej. Automatyczne łatanie wydawało się naturalnym domknięciem — jeśli maszyna znajduje szybciej, niech też naprawia szybciej.

Te sześć tysięcy łatek mówi, że tak się nie stanie w najbliższym czasie. I mówi też dlaczego, w sposób, który zgadza się ze wszystkim, co widzieliśmy przy znajdowaniu i pisaniu kodu. Znajdowanie błędu jest zadaniem lokalnym — trzeba zobaczyć jedno miejsce. Naprawienie go jest zadaniem globalnym: trzeba zrozumieć, do jakiej klasy należy, gdzie jeszcze występuje i co się zepsuje, gdy się go usunie.

Maszyna przyspieszyła tę połowę pracy, która polega na patrzeniu. Ta druga, która polega na rozumieniu, wciąż jest tam, gdzie była.

Źródła

Help Net Security — omówienie badania z opisem metodologii, kategorii kruchych łatek, kluczowej obserwacji o braku widocznych oznak awarii oraz analizą przypadku podatności w Chromium: https://www.helpnetsecurity.com/2026/08/06/1password-ai-generated-vulnerability-patches/

CyberScoop — zestawienie wyników z niezależnym badaniem Veracode dotyczącym kodu generowanego przez AI, wskazanie testowanych modeli oraz zastrzeżenie, że nie objęto nowszych modeli wyspecjalizowanych w cyberbezpieczeństwie: https://cyberscoop.com/ai-code-patching-security-risks/

Dark Reading — dane o odsetku łatek zamykających podatność, opis kruchości poprawek oraz wypowiedź dyrektora badań 1Password o skuteczności łatania błędów spoza zbioru treningowego: https://www.darkreading.com/application-security/ai-generated-patches-fail-half-time

News4Hackers — szczegóły przypadku serwera WWW, w którym sto czternaście łatek uznanych za zamykające pierwotny błąd wprowadziło nowe problemy, oraz opis odrzucenia propozycji przez opiekunów projektu: https://www.news4hackers.com/75-of-ai-generated-vulnerability-patches-introduce-new-security-flaws

ComplianceHub — zestawienie obu badań z danymi Veracode o zdawalności w podziale na języki programowania: https://compliancehub.wiki/ai-generated-code-patch-failure-rates-secure-development-governance-2026/