Trail of Bits twierdzi, że benchmark łatania z użyciem AI od 1Password wprowadza obrońców w błąd

Trail of Bits zakwestionował benchmark łatania z użyciem AI od 1Password sześć tygodni po jego publikacji, nazywając prezentowany wskaźnik 26% czystych poprawek mylącym.

Spór nie dotyczy wyłącznie tego, czy AI tworzy bezpieczny kod. Chodzi o to, co mierzy benchmark, gdy agenci otrzymują błędne instrukcje, ograniczone narzędzia i są oceniani w niespójny sposób.

Off-by-1 Labs firmy 1Password przetestowało 6 080 poprawek w ramach sześciu trudnych podatności. Raport wykazał, że 26% z nich całkowicie usuwało podatność bez istotnej zmiany zachowania aplikacji.

Kolejne 20,1% usuwało zgłoszoną podatność, ale zmieniało zachowanie aplikacji. Pozostałe 53,9% nie rozwiązywało problemu, wprowadzało kolejną podatność albo robiło jedno i drugie.

Trail of Bits nie twierdzi, że te niepowodzenia są niegroźne. Jego badacze argumentują natomiast, że zagregowany wynik łączy warunki eksperymentalne reprezentujące zasadniczo różne zadania związane z łataniem.

Firma podaje, że 22% zbioru danych pochodziło z promptów kierujących agentów ku nieprawidłowej poprawce. Kolejne 36% pochodziło z prób, w których agenci nie mogli kompilować ani testować kodu.

Trail of Bits opublikował również dwa skills dla agentów wraz ze swoją krytyką. Jeden weryfikuje poprawki względem pierwotnego błędu, powiązanych wariantów i regresji. Drugi tworzy interaktywne przewodniki przeglądu dla inżynierów.

Ta odpowiedź przekształca spór o benchmark w szerszą debatę o bezpieczeństwie wspomaganym przez AI. Kluczowe pytanie brzmi, czy zespoły powinny oceniać agentów jako odizolowanych generatorów poprawek, czy jako uczestników zweryfikowanego procesu inżynieryjnego.

Benchmark łatania z użyciem AI od 1Password połączył bardzo różne eksperymenty

Trail of Bits argumentuje, że wynik 26% opisuje mieszany eksperyment, a nie typowego agenta pracującego z normalnymi narzędziami deweloperskimi.

Off-by-1 Labs opublikowało badanie FLAWED 6 sierpnia 2026 roku. FLAWED oznacza Fix-Like Artifacts With Embedded Defects.

Badanie analizowało ChatGPT-5.5 i Opus 4.8 w odniesieniu do sześciu niedawno ujawnionych podatności. Cele obejmowały Linux, ActiveMQ, Chrome, Exim, Spring AI i Gemini CLI.

Badacze wybrali podatności, których poprawki upstream obejmowały wiele plików, funkcji lub ścieżek kodu. Ich niedawne ujawnienie zmniejszało także prawdopodobieństwo, że modele zapamiętały gotowe poprawki.

Taki projekt realizował uzasadniony cel. Trudne, nieznane podatności mogą ujawnić niepełne rozumowanie, które ukrywają zwykłe benchmarki programistyczne.

Ogranicza jednak również możliwość szerokiego stosowania średniej przez czytelników. Według analizy Trail of Bits wskaźniki czystych poprawek wahały się od 3% do 60% dla sześciu celów.

Średnia z sześciu celów zależy zatem w dużym stopniu od ich wyboru. Nie może ustalić wskaźnika niepowodzeń dla rutynowych poprawek, prostszych podatności ani reprezentatywnego backlogu oprogramowania.

Eksperyment różnicował także sposób pracy agentów. Próby jednorazowe nie zapewniały dostępu do powłoki i uniemożliwiały modelowi budowanie lub uruchamianie dotkniętego problemem oprogramowania.

Próby iteracyjne zapewniały skrypty odtwarzające problem i pozwalały na wielokrotne podejścia. Próby eksploracyjne oferowały dostęp deweloperski, lecz wymagały od agenta samodzielnej decyzji, jak zweryfikować własną pracę.

Tryby te odpowiadają na różne pytania. Odpowiedź jednorazowa mierzy generowanie kodu pod surowymi ograniczeniami. Agent iteracyjny mierzy łatanie z wykorzystaniem wykonywalnego sprzężenia zwrotnego.

Łączenie obu w jeden główny wynik zaciera tę różnicę. Agent łatający bez dostępu do kompilacji nie może korzystać z pętli informacji zwrotnej, którą programiści traktują jako podstawową praktykę inżynieryjną.

Trail of Bits podaje, że tryb bez testowania stanowił 36% raportowanych danych. Ten udział sprawia, że ograniczenie narzędzi jest istotnym czynnikiem wpływającym na ogólny wynik.

Konstrukcja promptów wprowadziła kolejną różnicę. Badanie FLAWED wykorzystywało dziewięć ustrukturyzowanych szablonów promptów dla każdej podatności, w tym prompty zawierające nieprawidłowe lub niepełne wskazówki.

Badanie, czy modele opierają się złym radom, ma wartość. Może ujawniać skłonność do automatyzacyjnego zaufania i pokazywać, jak łatwo agent podąża za błędną diagnozą.

Trail of Bits twierdzi jednak, że dwa prompty wyraźnie kierowały agentów ku niewłaściwej naprawie. Prompty te stanowiły 22% zbioru danych.

Organizacja oceniająca autonomiczne łatanie powinna interesować się takim trybem niepowodzenia. Deweloper oceniający agenta dysponującego dokładnym raportem o podatności znajduje się jednak w innej sytuacji.

Spór dotyczy więc agregacji, a nie tego, czy takie eksperymenty powinny istnieć. Trail of Bits uważa, że mylące prompty powinny być raportowane oddzielnie od zwykłych prób naprawy.

W swojej ponownej analizie firma zachowała próby, w których agenci mogli wykonywać kod i nie byli kierowani ku błędnej poprawce. Wykluczyła także podejścia oznaczone jako korzystające z poprawki upstream.

W tych warunkach 2 634 z 3 067 poprawek blokowały dostarczony exploit. Odpowiada to 86% przefiltrowanych prób.

Zablokowanie jednego exploita nie dowodzi pełnej naprawy bezpieczeństwa. Trail of Bits wyraźnie uznaje to ograniczenie.

Wąskie zabezpieczenie może zatrzymać dostarczone dane wejściowe, pozostawiając jednak podstawową słabość osiągalną inną ścieżką. Wynik 86% mierzy natychmiastowe blokowanie exploita, a nie pełne usunięcie problemu.

Mimo to przefiltrowany wynik pokazuje, dlaczego warunki eksperymentalne mają znaczenie. Ten sam zbiór danych może wspierać pesymistyczny nagłówek o czystych poprawkach i bardziej optymistyczny wynik blokowania exploitów.

Żaden z tych odsetków sam w sobie nie rozstrzyga, czy agenci AI są godnymi zaufania autorami poprawek. Łącznie pokazują, że etykiety benchmarków muszą precyzyjnie opisywać testowany workflow.

Dlaczego projekt promptów i dostęp do testów zmieniają odpowiedź

Kontrowersje wokół benchmarku ujawniają podstawową zasadę oceny agentów: warunki pracy są częścią mierzonego systemu.

Agent programistyczny to nie tylko model językowy. Obejmuje także instrukcje, narzędzia, środowisko wykonawcze, kontekst, regułę zatrzymania i proces walidacji.

Zmiana dowolnego komponentu może zmienić wynik. Model, który może uruchomić reproduktor, otrzymuje dowody niedostępne dla modelu tworzącego jedną odpowiedź na podstawie statycznego tekstu.

Oryginalny raport FLAWED opisuje trzy tryby działania. Każdy z nich reprezentuje inny balans między izolacją, iteracją i autonomią agenta.

Tryb jednorazowy nie zapewniał dostępu do powłoki ani internetu. Model miał stworzyć kompletną poprawkę w jednej odpowiedzi.

Taka konfiguracja może odzwierciedlać silnie ograniczone środowiska. Usuwa jednak z pętli naprawczej kompilację, testy, sanitizery, debugowanie i polecenia inspekcyjne.

Tryb iteracyjny dostarczał skrypty odtwarzające problem i pozwalał na kilka prób. Agent mógł korzystać z informacji zwrotnych z wcześniejszych uruchomień za pośrednictwem pliku pamięci.

Tryb eksploracyjny umożliwiał podobny dostęp bez przekazywania modelowi przygotowanego reproduktora. Agent musiał wybrać własną ścieżkę walidacji przed zgłoszeniem zakończenia pracy.

Tryby te nie różnią się jedynie wygodą. Testują odmienne zdolności.

Generowanie jednorazowe pyta, czy model potrafi wywnioskować kompletną naprawę na podstawie kodu źródłowego i opisu. Łatanie iteracyjne pyta, czy potrafi diagnozować błędy i doskonalić się poprzez wykonanie kodu.

Łatanie eksploracyjne dodaje kolejne obciążenie. Agent musi sam skonstruować dowody, że jego zmiana działa, zamiast otrzymać je jako część zadania.

Trail of Bits argumentuje, że benchmark powinien ujawniać wpływ tych warunków. Nie powinien traktować ich połączonej średniej jako ogólnego wyniku zdolności.

Jakość promptów stwarza podobny problem. Raporty bezpieczeństwa często zawierają exploit, podejrzewaną przyczynę źródłową, dotknięte ścieżki i wskazówki dotyczące ograniczenia ryzyka.

Dane te mogą być niepełne lub błędne. Pomiar zachowania modelu w każdym z tych warunków może pomóc zespołom projektować bezpieczniejsze workflow.

Celowo błędne wskazówki reprezentują jednak antagonistyczne lub pomylone sformułowanie zadania. Nie powinny po cichu wpływać na liczbę używaną do opisu zwykłego łatania z użyciem AI.

Przydatny raport pokazywałby wskaźniki czystych poprawek dla poprawnych wskazówek, niepełnych wskazówek, nieprawidłowych wskazówek i nieukierunkowanej eksploracji. Czytelnicy mogliby wtedy odnieść wyniki do własnego środowiska.

Ustawienia rozumowania tworzą trzecią zmienną. Eksperyment uruchamiał ChatGPT-5.5 przy średnim wysiłku oraz Opus 4.8 przy wysokim wysiłku, zgodnie z ich ustawieniami domyślnymi.

Trail of Bits zauważa, że żaden z modeli nie korzystał z najwyższego dostępnego ustawienia. Eksperyment nie wyodrębnił też wpływu wysiłku na jakość napraw.

To pominięcie nie unieważnia zaobserwowanych poprawek. Ogranicza natomiast twierdzenia dotyczące osiągalnej wydajności każdego modelu.

Kwestia staje się ważniejsza, gdy modele otrzymują nierówne ustawienia. W przeciwnym razie czytelnicy mogą interpretować różnice jako zdolności modelu, a nie skutki konfiguracji.

Ocena wprowadza kolejną warstwę. FLAWED wykorzystywał modele do oceny poprawek, w tym wzajemną ocenę przez drugi model.

Według Trail of Bits ocena modelowa zgadzała się z ludzkimi recenzentami w pełnym, pięciokategorialnym wyniku w 65,9% przejrzanych przypadków.

Zgodność wzrosła do 87,7%, gdy recenzenci pytali wyłącznie, czy pierwotna podatność została naprawiona. Spadła do 70,5% w ocenie, czy pojawił się nowy błąd.

Jak podaje Trail of Bits, dwaj oceniający modele przypisali różne wyniki 36,8% tych samych poprawek. Uśrednienie tych ocen nie eliminuje rozbieżności.

Ma to znaczenie, ponieważ status czystej poprawki łączy kilka rozstrzygnięć. Oceniający musi zdecydować, czy stara podatność pozostaje, czy zachowanie się zmieniło oraz czy pojawiła się inna słabość.

Nawet poprawna łatka może otrzymać niekorzystną etykietę, jeśli oceniający uzna zamierzoną zmianę zachowania za regresję. Niepełna łatka może przejść ocenę, jeśli testy pominą inną podatną ścieżkę.

Trail of Bits twierdzi, że 8% werdyktów dotyczących ActiveMQ karało zamierzone zmiany jako regresje. Wskazuje również ścieżkę oceny Chromium, która miała akceptować niepełne naprawy use-after-free.

Krytyka wskazuje ponadto referencyjną poprawkę Linux zawierającą podatność off-by-one. Modele powieliły ten błąd w 248 wygenerowanych poprawkach, podczas gdy automatyczny oceniający wykrył 24.

Twierdzenia te pochodzą z ponownej analizy Trail of Bits i pozostają częścią trwającego sporu metodologicznego. Nie przekreślają nieudanych poprawek udokumentowanych przez Off-by-1 Labs.

Pokazują, dlaczego benchmark AI wymaga walidacji własnego ewaluatora. Potok oceny może wprowadzać fałszywie dodatnie i fałszywie ujemne wyniki, podobnie jak potok łatania.

Rzeczywisty spór dotyczy generowania poprawek przez AI kontra zweryfikowanej naprawy

1Password mierzy, jak często wygenerowane poprawki kwalifikują się jako czyste, podczas gdy Trail of Bits podkreśla proces inżynieryjny, który przekształca propozycje w zaakceptowane naprawy.

Oryginalne ustalenia 1Password zawierają istotne ostrzeżenie. Wiarygodnie wyglądający kod może zablokować proof of concept bez usunięcia źródłowej przyczyny podatności.

Off-by-1 Labs stwierdziło, że ponad jedna trzecia poprawek zakwalifikowanych jako udane zawierała elementy kruche z punktu widzenia bezpieczeństwa. Poprawki te opierały się na wąskich kontrolach zamiast pełnego usunięcia problemu.

Spring AI stanowił użyteczny przykład. Modele często escapowały znaki w dostarczonym złośliwym wejściu zamiast rozwiązać podstawowy problem ekspozycji na język wyrażeń.

Taka poprawka może pokonać jeden payload, pozostawiając dostępnymi alternatywne dane wejściowe. Sukces funkcjonalny w jednym teście tworzy wówczas fałszywe poczucie pewności.

Trail of Bits nie odrzuca tej lekcji. Jego nowy skill walidacyjny uwzględnia podobną obawę, wymagając drugiej ścieżki do tego samego błędu.

Spór dotyczy tego, co dzieje się przed i po generowaniu. Benchmark może oceniać surową odpowiedź modelu albo wspomagany przez agenta proces tworzenia oprogramowania.

Te jednostki analizy prowadzą do różnych wniosków. Surowe generacje ujawniają tryby porażki modeli. Ukończone przepływy pracy mierzą, czy inżynierowie są w stanie osiągnąć poprawne rezultaty przy wsparciu agentów.

Trail of Bits popiera drugie podejście swoją inicjatywą Patch the Planet. Inżynierowie kierowali agentami, przeglądali ich pracę i przesyłali poprawki opiekunom projektów open source.

Firma przeanalizowała 186 publicznych pull requestów, które opiekunowie scalili lub zamknęli do 14 września. Opiekunowie scalili 126 z nich, co daje wskaźnik akceptacji na poziomie 67,7%.

Spośród scalonych zgłoszeń 91 zachowało pierwotnie zaproponowaną poprawkę bezpieczeństwa bez zaobserwowanej istotnej dla bezpieczeństwa rewizji. Kolejne 33 otrzymały zmiany związane z bezpieczeństwem przed akceptacją.

Liczby te nie potwierdzają poprawności. Opiekunowie mogą scalać wadliwy kod, a rezultaty publicznego przeglądu nie ujawniają każdej późniejszej regresji.

Trail of Bits przyznaje, że istnieje to ograniczenie. Przedstawia akceptację jako dowód praktycznej użyteczności i nakładu pracy związanego z rewizjami, a nie jako dowód doskonałego bezpieczeństwa.

Firma przeanalizowała również około 33 500 późniejszych commitów w projektach Patch the Planet. Szukała zmian, które naprawiały problemy wprowadzone przez jej poprawki.

Badanie wykazało co najmniej dziesięć błędów funkcjonalnych, cztery błędy kompilacji, testowania lub automatyzacji wydań oraz jeden problem z wydajnością. Nie zgłoszono żadnych możliwych do wykorzystania luk bezpieczeństwa.

Brak wykrytej luki nie jest dowodem, że żadna nie istnieje. Trail of Bits twierdzi, że jego szerszy przegląd nadal trwa.

Jeden przypadek pokazuje, dlaczego przeciwstawianie ludzi i agentów może wprowadzać w błąd. Agent zaproponował poprawkę problemu bezpieczeństwa pamięci w osadzonym module Perla freenginx.

Poprawka pozostawiła otwartą jedną podatną ścieżkę i wprowadziła awarię podczas czyszczenia. Off-by-1 Labs słusznie ją skrytykowało.

Opiekun stworzył osobną poprawkę obejmującą wszystkie trzy podatne ścieżki. Ta zmiana napisana przez człowieka wprowadziła tę samą awarię podczas czyszczenia.

Obaj autorzy zachowali callback dłużej, a następnie zwolnili go, gdy żądanie stało się bezużyteczne. Czyszczenie mogło uruchomić kod Perla, który uzyskiwał dostęp do nieprawidłowego żądania.

Ten przykład nie dowodzi równoważności ludzi i agentów. Pokazuje, że obie strony mogą przeoczyć konsekwencje wykraczające poza bezpośrednią ścieżkę exploitu.

Trail of Bits porównało ten przypadek ze swoimi rejestrami konsultingowymi. Przeanalizowało pierwsze poprawki dla 2265 luk w 236 ocenach bezpieczeństwa przeprowadzonych od 2024 do 2026 roku.

Programiści nie rozwiązali w pełni 283 problemów za pierwszą próbą. Stanowi to 12,5%, przy zgłoszonym 95-procentowym przedziale ufności od 10,5% do 14,5%.

Ci programiści znali swoje oprogramowanie i otrzymali szczegółowe raporty o lukach. Wiedzieli również, że Trail of Bits sprawdzi ich zmiany.

Porównanie nadal jest niedoskonałe. Ludzcy programiści i agenci benchmarku nie rozwiązywali identycznych zadań w identycznych warunkach.

Mimo to dane podważają nierealistyczną bazę odniesienia, według której poprawki tworzone przez ludzi są automatycznie poprawne. Naprawa bezpieczeństwa zawsze zależała od przeglądu, testów i rewizji.

Ten kontekst zmienia praktyczne pytanie. Zespoły nie potrzebują agenta, którego pierwsza poprawka jest nieomylna.

Potrzebują dowodów, że agent zwiększa przepustowość bez podnoszenia ryzyka rezydualnego ponad akceptowalne granice. Pomiar tego wymaga porównywalnych zespołów, zadań i bramek weryfikacyjnych.

Inicjatywa Trail of Bits dotycząca poprawek odzwierciedla to podejście do przepływu pracy. Agenci generują i badają, podczas gdy inżynierowie i opiekunowie nadal odpowiadają za akceptację.

Raport 1Password odzwierciedla inną obawę. Szybkie generowanie może przytłoczyć recenzentów poprawkami, które wyglądają na kompletne, ale zawierają subtelne defekty.

Obie obawy mogą być prawdziwe. Wsparcie agentów może zwiększyć liczbę podatności możliwych do naprawienia, jednocześnie zwiększając znaczenie solidnej weryfikacji.

Dwie umiejętności agentów zmieniają krytykę w testowalny przepływ pracy

Trail of Bits odpowiada na benchmark za pomocą kontroli operacyjnych, a nie jedynie korzystniejszej interpretacji danych.

Firma wydała post-patch-validation, aby zbadać poprawkę bezpieczeństwa przed jej przesłaniem. Narzędzie przyjmuje raport o luce oraz podatne i poprawione rewizje kodu.

Pierwszym zadaniem jest odtworzenie pierwotnego błędu. Umiejętność wymaga sprawdzenia, które kończy się niepowodzeniem na podatnym kodzie i powodzeniem po zastosowaniu poprawki.

Warunek ten zapobiega częstemu błędowi w testowaniu. Test, który przechodzi dla obu rewizji, nie może wykazać, że zmiana usunęła podatność.

Drugie zadanie dotyczy odrębnej ścieżki prowadzącej do tej samej awarii. Ta ścieżka powinna wynikać z pierwotnej przyczyny, a nie powtarzać oryginalny proof of concept.

Na przykład agent może sprawdzić inne wywołanie, alternatywne dane wejściowe, ścieżkę błędu lub sekwencję czyszczenia. Awaria freenginx pokazuje, dlaczego czyszczenie zasługuje na uwagę.

Trzecie zadanie sprawdza regresje i nowe podatności wokół zmodyfikowanego kodu. Porównuje zachowanie, które powinno pozostać stabilne w obu rewizjach.

Plan walidacji musi również uwzględniać szersze dowody. Trail of Bits wskazuje testy projektu, kontrole sanitizerów lub ograniczone fuzzing jako możliwe składniki.

Sanitizer wykrywa klasy błędów środowiska wykonawczego, takie jak nieprawidłowy dostęp do pamięci. Ograniczony fuzzing bada generowane dane wejściowe w określonym czasie lub zakresie.

Czwarte zadanie traktuje awarie infrastruktury jako niejednoznaczne. Uszkodzona kompilacja lub brakująca zależność nie mogą stanowić dowodu, że podatność została odtworzona.

Ta zasada wydaje się oczywista, lecz zautomatyzowane potoki często sprowadzają błędy wykonania do etykiet powodzenia lub niepowodzenia. Oddzielenie nieważnych dowodów chroni końcowy werdykt.

Umiejętność zachowuje swoje kontrole i wyniki dla opiekunów. Dzięki temu wniosek agenta można sprawdzić, zamiast prosić recenzentów o zaufanie tekstowemu zapewnieniu.

Drugie wydanie, review-walkthrough, dotyczy ludzkiej strony przepływu pracy. Przekształca pełny diff gałęzi w interaktywny, uporządkowany przegląd.

Zmiany pojawiają się w logicznej kolejności czytania, a nie w surowej kolejności plików. Ustalenia znajdują się obok odpowiedniego kodu, gdzie inżynier może je sprawdzić i na nie odpowiedzieć.

Przewodnik może przygotować przegląd GitHub, lecz recenzent nadal odpowiada za przesłane komentarze. Ta granica ma znaczenie dla rozliczalności.

Oba narzędzia są dostępne w publicznym repozytorium umiejętności bezpieczeństwa. Dołączają do istniejących umiejętności analizy wariantów, testowania opartego na właściwościach i testowania mutacyjnego.

Analiza wariantów wyszukuje powiązane przypadki defektu w całej bazie kodu. Testowanie oparte na właściwościach sprawdza zachowanie na wygenerowanych danych wejściowych zamiast na kilku ręcznie wybranych przypadkach.

Testowanie mutacyjne celowo zmienia kod, aby sprawdzić, czy zestaw testów wykryje niepoprawne zachowanie. Mutacje, które przetrwają, mogą ujawnić brakujące asercje lub słabe pokrycie.

Łącznie techniki te tworzą drabinę weryfikacyjną. Odtworzenie sprawdza zgłoszony exploit, podczas gdy testy wariantów podważają pokrycie pierwotnej przyczyny przez poprawkę.

Testy regresji chronią zamierzone zachowanie. Sanitaryzery i fuzzery szukają awarii wykraczających poza oczekiwane przykłady.

Testowanie mutacyjne ocenia następnie, czy te testy wykryłyby istotne błędy. Ludzki przegląd ocenia projekt, łatwość utrzymania i ryzyka poza zakresem automatycznego pokrycia.

Ten przepływ pracy nie gwarantuje bezpiecznej poprawki. Żaden skończony zestaw testów nie może potwierdzić braku każdej podatności.

Tworzy jednak artefakty wspierające silniejszą decyzję. Recenzenci mogą zobaczyć, co wcześniej kończyło się niepowodzeniem, co przechodzi teraz oraz które ścieżki pozostają nieprzetestowane.

To najsilniejsza część odpowiedzi Trail of Bits. Firma przekształca swoje metodologiczne zastrzeżenie w praktyki, które inne zespoły mogą ocenić.

Umiejętności ujawniają również potencjalną słabość krytyki. Ich wartość musi zostać zmierzona, a nie zakładana tylko dlatego, że zawierają rozsądne procedury.

Post-patch-validation nie było używane w analizowanych w poście pracach Patch the Planet. Jego wpływ na wskaźniki defektów pozostaje więc nieznany.

Zespoły powinny sprawdzić, czy wykrywa ono znane niekompletne poprawki, nowo zasiane regresje i defekty poza dostarczonym proof of concept.

Powinny również mierzyć fałszywe alarmy i czas przeglądu. Narzędzie weryfikacyjne generujące nadmierny szum może przenieść wąskie gardło bez poprawy rezultatów.

Ten sam standard dotyczy review-walkthrough. Lepsza prezentacja może poprawić zrozumienie, ale może też tworzyć nieuzasadnioną pewność, jeśli wyjaśnienia są błędne.

Interaktywna narracja powinna wspierać kontrolę, a nie ją zastępować. Recenzenci nadal potrzebują dostępu do pełnego diffu, testów, wyników kompilacji i kontekstu projektu.

Trail of Bits wyznaczyło falsyfikowalny kierunek. Kolejnym krokiem są porównawcze dowody pokazujące, w jakim stopniu każda umiejętność poprawia jakość poprawek i efektywność przeglądów.

Co zespoły bezpieczeństwa powinny obserwować dalej

Kontrowersję rozstrzygną kontrolowane porównania i odtwarzalne artefakty, a nie wybór bardziej atrakcyjnego nagłówkowego odsetka.

Pierwszym sygnałem będzie to, czy 1Password lub niezależni badacze opublikują wyniki rozdzielone według warunków. Czytelnicy potrzebują rezultatów pogrupowanych według jakości promptów, dostępu do narzędzi, trybu działania i nakładu rozumowania.

Taka analiza pokaże, czy wskaźnik czystych poprawek wynoszący 26% pozostaje niski w realistycznych warunkach programistycznych. Ujawni również, gdzie ograniczenia powodują największy spadek.

Wyniki dla poszczególnych podatności są ważne, ponieważ sześć celów znacznie się różniło. Średnie mogą ukrywać, czy agenci mają trudności z konkretnymi językami, architekturami lub klasami podatności.

Badacze powinni również raportować zarówno blokowanie exploitu, jak i usunięcie pierwotnej przyczyny. Pierwsze mierzy natychmiastową użyteczność, drugie zaś kompletność naprawy.

Drugim sygnałem będzie ekspercka replikacja kwestionowanych ocen. Recenzenci powinni przeanalizować identyczne poprawki według opublikowanych kryteriów i odnotować, gdzie oceny się rozchodzą.

Praca ta powinna uwzględnić przypadek Linux off-by-one, ścieżkę callbacka Chromium oraz zmiany zachowania ActiveMQ wskazane przez Trail of Bits.

Replikacja potwierdzająca powszechne błędy oceniania osłabiłaby główny przekaz benchmarku. Silna zgodność z pierwotnymi etykietami osłabiłaby krytykę Trail of Bits.

Trzecim sygnałem będzie kontrolowana ocena dwóch nowych umiejętności. Agenci powinni poprawiać te same podatności z użyciem i bez użycia przepływu pracy walidacji.

Porównanie powinno mierzyć czyste poprawki, nierozwiązane warianty, wprowadzone regresje, czas recenzenta oraz liczbę rewizji wymaganych przed akceptacją.

Powinno także obejmować zespoły wyłącznie ludzkie i wspomagane przez agentów w porównywalnych warunkach. Bez takiej bazy odniesienia twierdzenia o zastępowaniu programistów lub przewyższaniu ich pozostają niepotwierdzone.

Organizacje nie muszą czekać na każde badanie przed ustaleniem polityki. Mogą już oddzielić generowanie poprawek od ich zatwierdzania.

Poprawka wygenerowana przez AI powinna trafić do tego samego systemu przeglądu co zmiana od nieznanego współtwórcy. Jej pochodzenie nie powinno przyznawać zaufania ani powodować automatycznego odrzucenia.

Zespoły powinny zachowywać raport o podatności, reproduktor, transkrypcję agenta, poprawkę, polecenia walidacyjne i wyniki. Te artefakty pozwalają diagnozować błędy i umożliwiają późniejsze audyty.

Powinny wymagać wyjaśnienia pierwotnej przyczyny przed zatwierdzeniem. Poprawka, która jedynie filtruje dostarczony ładunek, zasługuje na bardziej wnikliwą kontrolę.

Zmiany wysokiego ryzyka wymagają szerszych kontroli dotyczących uwierzytelniania, bezpieczeństwa pamięci, kryptografii, parserów, kontroli dostępu i czyszczenia cyklu życia. Te obszary karzą powierzchowne poprawki.

Organizacje budujące wewnętrzne systemy przeglądu mogą również utrzymywać przeszukiwalną bazę wiedzy inżynierskiej dotyczącą wcześniejszych podatności, odrzuconych poprawek i powtarzających się wzorców awarii.

Taki zapis może pomóc recenzentom identyfikować powtarzające się błędy w różnych repozytoriach. Może też zachować uzasadnienie, dlaczego pozornie prosta poprawka została odrzucona.

Benchmark 1Password dotyczący łatania z użyciem AI nie powinien sprowadzać się do twierdzenia, że agenci zawodzą w trzech czwartych przypadków. Jego dane dokumentują rzeczywiste i istotne niepowodzenia napraw.

Krytyki Trail of Bits nie należy redukować do twierdzenia, że agenci odnoszą sukces w 86% przypadków. Zablokowanie dostarczonego exploita to mniej niż przeprowadzenie bezpiecznej naprawy.

Użyteczny wniosek leży między tymi liczbami. Agenci AI mogą tworzyć wartościowe poprawki, ale to projekt benchmarku i weryfikacja decydują o znaczeniu tych poprawek.

Dla liderów ds. bezpieczeństwa natychmiastowe działanie jest konkretne: przeanalizuj warunki stojące za każdym wskaźnikiem dotyczącym łatania, a następnie przetestuj agentów w procesie pracy, w którym faktycznie będą używani.

Zapytaj, czy agent mógł skompilować kod, odtworzyć problem, zbadać warianty i wykryć regresje. Następnie zapytaj, czy ekspert ocenił dowody, zamiast ufać różnicy w kodzie, która tylko wygląda na poprawną.

Ten proces daje lepszą podstawę do decyzji niż każdy z tych nagłówków rozpatrywany osobno. Prawdziwym sprawdzianem benchmarku 1Password dotyczącego łatania z użyciem AI jest to, czy jego ustalenia poprawiają weryfikację, nie zniechęcając jednocześnie do uzasadnionej automatyzacji.