Audyt Miden Trail of Bits wykrył błąd Falcon po tym, jak agenci stworzyli brakujące narzędzia

Trail of Bits spędziło sześć miesięcy na przygotowaniach do audytu Miden, a następnie odkryło lukę o wysokim poziomie krytyczności przy użyciu narzędzi, które jego agenci AI zbudowali od podstaw. Audyt Miden Trail of Bits obejmował znacznie więcej niż skierowanie modelu na kod źródłowy. Przed rozpoczęciem formalnego przeglądu agenci stworzyli serwer LSP, dekompilator, silnik analizy statycznej i model Lean.

Przygotowania te ujawniły niedostatecznie ograniczoną wartość, która według doniesień mogła pozwolić złośliwemu proverowi fałszować podpisy Falcon i opróżniać dotknięte problemem konta. Analizatory wskazały także ponad 400 miejsc, w których można było poprawić walidację typów. Tymczasem wysiłek związany z weryfikacją formalną przyniósł 95 sprawdzonych maszynowo dowodów poprawności i ujawnił dwa błędy pominięte przez istniejące testy jednostkowe.

Najważniejsza rywalizacja nie toczy się między agentami AI a ludzkimi audytorami. Chodzi o bezpośredni przegląd kodu przez AI kontra wspomagane przez agentów budowanie infrastruktury, która umożliwia trudny przegląd kodu. Trail of Bits nadal polegało na ludzkim nadzorze, ręcznym przeglądzie twierdzeń i tradycyjnym osądzie bezpieczeństwa. Agenci zmienili to, które projekty pomocnicze stały się ekonomicznie uzasadnione.

Audyt Miden Trail of Bits rozpoczął się sześć miesięcy wcześniej

Decydujące prace rozpoczęły się, zanim audytorzy otrzymali gotowy cel do zbadania.

Zespół Miden zwrócił się do Trail of Bits pod koniec 2025 roku, zgodnie ze szczegółowym opisem audytu Miden opublikowanym przez firmę. Miden chciał przed premierą poddać przeglądowi części swojej maszyny wirtualnej zero-knowledge. Jeden z obszarów obejmował podstawową bibliotekę zawierającą prymitywy kryptograficzne napisane w Miden Assembly, czyli MASM.

Maszyna wirtualna zero-knowledge, często skracana do zkVM, dowodzi, że program wykonał się poprawnie, bez konieczności powtarzania tych obliczeń przez każdego weryfikatora. Miden wykorzystuje architekturę maszyny stosowej. Instrukcje pobierają wartości ze stosu i odkładają na nim swoje wyniki.

Ta architektura ma znaczenie, ponieważ wejścia i wyjścia są często niejawne w kodzie MASM. Recenzent musi śledzić, jak każda instrukcja zmienia stos, a następnie przenosić ten stan przez gałęzie, pętle i wywołania procedur. Znajome wskazówki obecne na poziomie kodu źródłowego mogą zniknąć.

MASM nie posiadał także dużej części narzędzi, których audytorzy zwykle oczekują. Wsparcie edytorów było ograniczone, nie istniał dojrzały serwer językowy dostosowany do przeglądów, a zautomatyzowane analizy podstawowej biblioteki były nieliczne. Trail of Bits wiedziało, że implementacja nie była jeszcze kompletna funkcjonalnie, lecz wiedziało również, że do przeglądu pozostało sześć miesięcy.

Firma wykorzystała ten czas na zbudowanie własnego środowiska przeglądu. Jak podaje Trail of Bits, Claude stworzył w ciągu kilku dni pierwszy prototyp serwera językowego. Powstały serwer językowy MASM zapewnia nawigację, wyszukiwanie referencji, dokumentację po najechaniu kursorem, diagnostykę składni, opisy instrukcji i informacje o wpływie na stos.

Te funkcje brzmią jak zwykłe udogodnienia dla programistów. W nieznanym języku asemblerowym stają się częścią metody bezpieczeństwa. Nawigacja pomaga audytorom śledzić wartość przez granice procedur. Wbudowane informacje o stanie stosu ograniczają potrzebę wielokrotnej ręcznej rekonstrukcji. Diagnostyka ujawnia założenia, zanim staną się ustaleniami audytu.

Trail of Bits następnie rozszerzyło projekt o dekompilację, analizę statyczną, narzędzia wiersza poleceń i modelowanie formalne. Claude realizował zadania planowania i implementacji, a Codex uczestniczył w przeglądzie kodu. Agenci zmieniali również role, zapewniając wygenerowanej pracy osobny etap przeglądu.

Nie był to proces jednorazowego generowania. Po wdrożeniu funkcji zespół prosił agentów o dekompilację losowo wygenerowanych procedur i porównanie wyników z oryginalnym MASM. Regresje stawały się testami, a model następnie pracował w oparciu o te testy.

Ta pętla sprzężenia zwrotnego jest kluczowa dla tej historii. Agenci nie byli traktowani jako autorytety, których wyniki zasługują na automatyczne zaufanie. Działali w ramach rozrastającego się systemu weryfikacji zawierającego testy, etapy przeglądu, analizatory, a później także sprawdzacz dowodów.

Audyt rozpoczął się więc od pytania innego niż zwykle. Trail of Bits nie pytało wyłącznie, czy agent potrafi znaleźć luki. Pytało, które brakujące instrumenty uniemożliwiały audytorom, w tym agentom, zrozumienie kodu już na samym początku.

Ta zmiana zakresu stworzyła warunki dla późniejszych ustaleń. Wywarła też presję na zespoły bezpieczeństwa, które promują przegląd AI przede wszystkim jako szybsze skanowanie kodu źródłowego. Podejście Trail of Bits wymagało więcej przygotowań, ale przekształciło je w wielokrotnego użytku infrastrukturę techniczną.

Dekompilator stał się cenniejszy niż jego wynik

Dekompilator był najważniejszy przede wszystkim dlatego, że jego reprezentacja wewnętrzna dała innym analizom niezawodne miejsce do działania.

Dekompilacja MASM nie polegała po prostu na zastępowaniu instrukcji asemblera czytelnymi wyrażeniami. Większość procedur podstawowej biblioteki nie miała zadeklarowanych sygnatur, dlatego narzędzia często musiały wywnioskować ich wejścia i wyjścia z kontekstu. Procedury nie miały też jednolitej konwencji wywoływania.

Pętle stworzyły kolejny problem. Pętla while w MASM nie musi zachowywać tego samego kształtu stosu między iteracjami. Jej warunek może zostać przeniesiony na inną pozycję stosu, co niweczy proste próby przypisywania stabilnych nazw wejściom instrukcji.

Gałęzie warunkowe także mogą wywoływać różne skutki dla stosu. Jeśli jedna gałąź dodaje element, a druga go usuwa, dekompilator nie może bezrefleksyjnie scalać ich stanów. Błędy w wnioskowaniu o wpływie na stos mogą następnie rozprzestrzeniać się przez każdą procedurę wywołującą dotknięty kod.

Trail of Bits odpowiedziało, ograniczając swoje obietnice. Jego dekompilator MASM obsługuje dobrze zdefiniowany podzbiór, zamiast twierdzić, że perfekcyjnie odtwarza każdą procedurę. Wybór ten stawiał poprawność ponad powierzchowne pokrycie.

Dekompilator stał się największym wysiłkiem narzędziowym w projekcie. Trail of Bits informuje o ponad 100 commitach wygenerowanych przez AI w ciągu kilku miesięcy. Jednak ukończony pseudokod nie był jego najbardziej znaczącym rezultatem.

Projekt stworzył reprezentację pośrednią, czyli IR, która przedstawiała wejścia i wyjścia procedur jako wyrażenia możliwe do analizowania. IR to ustrukturyzowana wersja kodu zaprojektowana na potrzeby transformacji lub analizy. Gdy instrukcje MASM znalazły się w tej postaci, zespół mógł zastosować ugruntowane techniki przepływu danych i analizy statycznej.

Analizator mógł sprawdzać, czy wartości dostarczane przez provera były walidowane przed użyciem. Mógł śledzić, czy kod wymuszał oczekiwane typy, takie jak 32-bitowe liczby całkowite czy wartości logiczne. Mógł też ustalić, czy zmienne lokalne były inicjalizowane na każdej możliwej ścieżce wykonania.

Trail of Bits wykorzystało do części tej pracy interpretację abstrakcyjną. Interpretacja abstrakcyjna ocenia kategorie możliwych wartości zamiast wykonywać program dla jednego konkretnego wejścia. Wartość może być reprezentowana jako poprawna 32-bitowa liczba całkowita, wartość logiczna albo wartość nieznana.

Analiza powtarza się, aż osiągnie stabilny stan, w którym nie pojawiają się nowe informacje. Jeśli została zaprojektowana w sposób poprawny, nadmiernie przybliża to, co mogą zrobić rzeczywiste wykonania. Może to generować fałszywe alarmy, ale nie powinno po cichu wykluczać rzeczywistego zachowania objętego modelem.

To pokazuje, dlaczego audyt Miden Trail of Bits różni się od ogólnej demonstracji programowania z AI. Wygenerowany przez agenta dekompilator nie był uznawany za wiarygodne źródło opinii, że kod jest bezpieczny. Pomógł stworzyć podłoże, na którym mogły działać jawne, możliwe do zbadania analizy.

Przepływ pracy przyniósł także korzyści ludziom. Zdekompilowane procedury ułatwiały przegląd wysokopoziomowego przepływu sterowania i danych w edytorze. Adnotacje stosu ograniczały obciążenie pamięci roboczej. Interfejsy wiersza poleceń udostępniały te same możliwości automatycznym procesom przeglądu.

Dla zespołów oceniających agentów programistycznych płynie z tego szersza lekcja. Najcenniejszy wygenerowany artefakt może nie być tym, który widzą użytkownicy. Częściowo ograniczony dekompilator może nadal uzasadniać swój koszt, jeśli jego parser, model przepływu sterowania i IR odblokowują kilka kontroli o wyższej wartości.

Wniosek ten zmienia też sposób, w jaki zespoły powinny zachowywać kontekst projektu. Prompty agentów, przypadki regresji, decyzje architektoniczne i komentarze recenzentów stają się trwałymi elementami pracy inżynieryjnej. Baza wiedzy z możliwością wyszukiwania może pomóc zachować dostęp do tych materiałów przez długie projekty bezpieczeństwa.

Bezpośredni przegląd AI zazwyczaj zaczyna od kodu docelowego i poszukuje defektów. Trail of Bits wykorzystało natomiast agentów, aby zmienić powierzchnię przeglądu. Kolejny wynik pokazał, dlaczego to rozróżnienie miało znaczenie.

Jedna brakująca kontrola dotarła do uwierzytelniania Falcon

Pojedyncza niezwalidowana reszta miała rzekomo przekształcić pomocniczą funkcję arytmetyczną w ścieżkę do sfałszowanego uwierzytelnienia.

Podczas audytu analizy statyczne wskazały ponad 400 unikalnych miejsc, w których można było poprawić walidację typów. Trail of Bits twierdzi, że wszystkie były osiągalne z publicznego API podstawowej biblioteki. Wiele z nich wynikało z faktu, że publicznie udostępnione procedury można było wywoływać bez założeń, których oczekiwali ich pierwotni autorzy.

Publiczna procedura nie może bezpiecznie zakładać, że każdy wywołujący dostarczy wartość zamierzonego typu. W systemie dowodowym szczególnie ważne jest rozróżnienie wartości dostarczonej przez provera od wartości ograniczonej przez dowód. Samo umieszczenie danych w obliczeniu nie dowodzi, że reprezentują one deklarowaną liczbę całkowitą lub wartość logiczną.

Ustalenie o wysokiej krytyczności koncentrowało się na mod_12289, procedurze redukującej 64-bitową wartość modulo 12 289. Prover dostarczał iloraz i resztę poprzez mechanizm advice. Wartości advice są wskazówkami wykonawczymi obliczanymi poza VM, często używanymi, aby uniknąć kosztownych operacji wewnątrz VM.

Iloraz otrzymał kontrolę potwierdzającą, że mieści się w oczekiwanej 64-bitowej reprezentacji. Reszta nie otrzymała równoważnej walidacji przed przekazaniem do u32overflowing_sub, instrukcji 32-bitowego odejmowania.

Trail of Bits twierdzi, że atakujący mógł zmieniać iloraz i resztę, nadal spełniając ograniczenia odejmowania. Pozwalało to mod_12289 zwracać coś innego niż matematycznie poprawną resztę.

Zasięg błędu wykraczał poza niepoprawny wynik arytmetyczny. Procedura wspierała weryfikację podpisów Falcon. Falcon to postkwantowy schemat podpisów cyfrowych, a Miden wykorzystywał jego wariant w uwierzytelnianiu kont.

Według Trail of Bits złośliwy prover mógł wykorzystać niedostatecznie ograniczoną wartość do sfałszowania podpisu Falcon i opróżnienia konta kontrolowanego przez parę kluczy Falcon. Jest to techniczne twierdzenie firmy, a nie niezależnie odtworzony exploit przedstawiony w publicznym artykule.

Poziom krytyczności wynika z modelu wykonania Miden. Projekt Miden VM obsługuje niedeterministyczne wejścia dostarczane podczas generowania dowodu. Takie wejścia mogą zwiększać wydajność, lecz program musi je starannie ograniczać.

Weryfikator nie wyprowadza intencji programisty. Sprawdza, czy przedstawiony dowód spełnia zakodowane ograniczenia. Jeśli te ograniczenia akceptują nieprawidłową resztę, dowód może pozostawać ważny, nawet gdy deklarowana relacja arytmetyczna jest fałszywa.

To jest zasadnicze odwrócenie perspektywy. Dowody zero-knowledge mogą potwierdzać wierne wykonanie określonego systemu, ale nie mogą naprawić niepełnej specyfikacji. Kryptograficzny dowód programu z niedostatecznymi ograniczeniami może wzbudzać zaufanie do niewłaściwej właściwości.

Niezależny kontekst z późniejszego audytu kontraktów Miden wzmacnia ogólną tezę. OpenZeppelin opisał transakcje Miden jako ważne, gdy istnieje odpowiadający im dowód, co sprawia, że każda kontrola MASM jest częścią ograniczeń, które musi spełnić generator dowodu.

To odrębne zlecenie obejmowało inny zakres repozytorium i nie należy go utożsamiać z przeglądem Trail of Bits. Oba opisy pokazują jednak, dlaczego logika uwierzytelniania, dane wejściowe kontrolowane przez generator dowodu oraz założenia on-chain wymagają jednoznacznego ujęcia.

Ponad 400 miejsc walidacji typów również należy interpretować ostrożnie. Nie zostały one opisane jako 400 podatności możliwych do wykorzystania. Oznaczały miejsca, w których walidację można było ulepszyć, przy czym zgłoszono wśród nich jeden problem o wysokim stopniu ważności.

To rozróżnienie ma znaczenie, ponieważ analiza statyczna często wykrywa warunki wymagające weryfikacji. Rzetelny analizator może celowo zgłaszać więcej przypadków, niż ostatecznie okaże się defektami bezpieczeństwa. Jego wartość polega na systematycznym lokalizowaniu założeń, które zasługują na sprawdzenie.

Dla zespołów bezpieczeństwa rezultat ten podważa popularny skrót myślowy: używanie agenta do streszczania podejrzanych funkcji bez uprzedniego zamodelowania reguł wartości języka docelowego. Model może wyjaśnić, co kod pozornie robi. Analizator może zapytać, czy każde dozwolone wykonanie rzeczywiście przestrzega wymaganego typu.

Ustalenie Falcon wynikało z połączenia obu możliwości. Agenci przyspieszyli budowę, podczas gdy semantyka statyczna przekształciła intuicję dotyczącą danych kontrolowanych przez generator dowodu w powtarzalną kontrolę.

Dowody Lean wykryły to, co przeoczyły testy jednostkowe

Weryfikacja formalna nie zastąpiła testowania, ale zmusiła zespół do wystarczająco precyzyjnego określenia zachowania, aby ujawnić dwa nieprzetestowane błędy.

Trail of Bits kontynuował formalne modelowanie nawet po zbudowaniu edytora i narzędzi analizy statycznej. Pytanie było celowo inne: jeśli procedura biblioteczna nie zawierała oczywistego defektu, czy zespół mógł udowodnić, że jej implementacja odpowiada zamierzonemu zachowaniu arytmetycznemu?

Firma zbudowała minimalny wykonawca Miden VM w Lean. Lean jest interaktywnym systemem dowodzenia twierdzeń, którego niewielkie zaufane jądro sprawdza, czy przedstawiony dowód wynika z jego definicji i założeń. Claude pomógł również stworzyć translator procedur MASM do reprezentacji Lean.

Następnie wiele agentów pracowało równolegle nad dowodami dla procedur. Powstały model MASM Lean zawiera wykonywalną semantykę VM, przetłumaczone procedury, wspólną obsługę dowodów oraz indywidualne twierdzenia o poprawności.

Repozytorium wymienia 95 sprawdzonych dowodów procedur: 31 dla operacji 64-bitowych, 36 dla operacji 128-bitowych, 17 dla operacji 256-bitowych oraz 11 dla operacji na słowach. Łącznie obejmują one części arytmetyki binarnej opisane przez Trail of Bits.

Nie były to dowody, że każda część Miden jest bezpieczna. Dotyczyły określonych właściwości poprawności dla konkretnych procedur. Ta granica jest kluczowa, ponieważ system dowodzenia twierdzeń weryfikuje dostarczone mu twierdzenie, a nie niewypowiedziany zamiar w głowie programisty.

Trail of Bits twierdzi, że recenzenci skupili się zatem na audycie sformułowań twierdzeń. Jeśli agent udowodnił twierdzenie, które pomijało krytyczny warunek wstępny lub wyrażało niewłaściwy wynik, sama akceptacja przez jądro nie czyniłaby oprogramowania poprawnym.

Na wysokim poziomie wiele twierdzeń miało rozpoznawalny wzorzec. Dla stosu zawierającego określone dane wejściowe wykonanie procedury powinno się zakończyć i pozostawić na jego szczycie matematycznie oczekiwany wynik. Niezwiązane z procedurą wartości stosu należące do wywołującego powinny pozostać w oczekiwanych miejscach.

Presja wynikająca z takiej specyfikacji ujawniła dwa defekty pominięte przez istniejące testy jednostkowe. Pierwszy dotyczył 64-bitowej procedury rotacji w prawo o nazwie rotr. Działała ona niepoprawnie dla dużych danych wejściowych powyżej liczby pierwszej Goldilocks, gdy liczba obrotów była wielokrotnością 32.

Liczba pierwsza Goldilocks definiuje ciało używane przez VM, dlatego wartości bliskie tej granicy lub ją przekraczające wymagają ostrożnej reprezentacji. Podczas prac nad dowodem pożądane twierdzenie nie dawało się wykazać bez dodania założenia wykluczającego problematyczny przypadek przesunięcia.

Nieudany dowód nie jest automatycznie dowodem błędu w kodzie. Błędne mogą być również twierdzenie, model lub pomocnicze lematy. W tym przypadku ręczny przegląd przeszkody doprowadził zespół do skrajnego przypadku w implementacji.

Drugi błąd pojawił się w 256-bitowej procedurze wrapping_mul. Trail of Bits podaje, że przed zwróceniem wyniku usuwała ona ze stosu wartości należące do wywołującego. Zwykłe testy wyniku mnożenia mogły przejść pomyślnie, nie sprawdzając przy tym zachowania otaczającego stanu stosu.

Ten defekt pokazuje, dlaczego precyzyjne warunki końcowe są ważne. Procedura może obliczyć poprawną odpowiedź liczbową, jednocześnie naruszając kontrakt wywołania. W maszynie stosowej uszkodzenie sąsiedniego stanu może wpłynąć na późniejsze wykonanie, nawet gdy element na szczycie wygląda poprawnie.

Testy jednostkowe nadal odgrywają centralną rolę. Wykonują się szybko, chronią przed znanymi regresjami i obejmują zachowanie integracyjne, które może jeszcze nie mieć modelu formalnego. Prace w Lean zapewniły inny rodzaj pewności dla jasno określonych właściwości.

Kluczowa przewaga miała charakter kompozycyjny. Agenci mogli tworzyć próby dowodów na dużą skalę, podczas gdy jądro Lean odrzucało nieprawidłowe wyprowadzenia. Ludzie nie musieli ufać pewności wyrażanej w prozie przez model. Musieli badać definicje i potwierdzać, że zaakceptowane twierdzenia reprezentują zamierzone gwarancje.

To silniejsza granica kontroli niż pytanie innego modelu językowego, czy wygenerowany kod wygląda poprawnie. Nie eliminuje ludzkiego osądu, lecz przesuwa go w stronę specyfikacji i założeń.

Dla liderów inżynierii ten przypadek sugeruje praktyczny podział pracy. Agenci mogą generować powtarzalną infrastrukturę dowodów, translatory i kandydackie lematy. Ludzcy specjaliści decydują, co musi zostać udowodnione, oraz badają, dlaczego ważne stwierdzenia zawodzą.

Wynik nie czyni autonomicznych audytów wiarygodnymi

Projekt wspiera inżynierię audytu wspomaganą przez agentów, a nie nadzorowaną przez nikogo certyfikację bezpieczeństwa.

Trail of Bits bezpośrednio przedstawia zmianę ekonomiczną. Kilka lat wcześniej firma z trudem uzasadniłaby miesiące eksploracyjnego tworzenia narzędzi dla jednego zlecenia. Takie projekty poboczne miały niepewne wyniki i trudno było je sprzedać, zanim ich wartość stała się widoczna.

Firma twierdzi, że agenci obniżyli koszt eksploracji na tyle, by zmienić tę kalkulację. Nieudane eksperymenty coraz częściej kosztują tokeny i czas nadzoru, zamiast pełnego zaangażowania specjalistycznej pracy inżynierskiej.

Twierdzenie to zasługuje na ostrożną interpretację. Przed audytem nadal minęło sześć miesięcy, a sam dekompilator zgromadził ponad 100 commitów wygenerowanych przez AI. Publiczny opis nie zawiera kontrolowanego porównania godzin pracy personelu, łącznych kosztów modeli ani uzysku defektów względem konwencjonalnego zlecenia.

Nie dowodzi też, że agenci mogą budować równoważne narzędzia dla każdego nietypowego języka. MASM oferował właściwości sprzyjające analizie i modelowaniu formalnemu. Miden VM ma zwarty zestaw instrukcji, a wiele operacji unika złożonych efektów ubocznych.

Nawet w przypadku tego sprzyjającego celu dekompilator nie mógł bezpiecznie objąć każdej procedury. Trail of Bits zawęził obsługiwany podzbiór, ponieważ niespójne efekty stosu i brakujące sygnatury sprawiały, że pełna, niezawodna dekompilacja była niepraktyczna.

Przepływ pracy Lean miał kolejne ograniczenie. Dowody sprawdzone przez jądro ustanawiają jedynie sformułowane twierdzenie w ramach modelowanej semantyki. Błędnie przetłumaczona instrukcja, niepełny model VM lub słabe twierdzenie mogą utrzymać lukę między udowodnionym zachowaniem a rzeczywistym wdrożeniem.

Ludzki przegląd pozostawał widoczny na każdym etapie procesu. Audytorzy przeglądali kod wygenerowany przez agentów, przekształcali regresje w testy, sprawdzali sformułowania twierdzeń i analizowali nieudane dowody. Claude i Codex naprzemiennie uczestniczyli w tworzeniu i przeglądzie, zamiast działać jako niewidoczny autorytet.

To wyostrza podstawowe porównanie. Bezpośredni przegląd przez AI prosi model o rozpoznawanie podatności w istniejącej reprezentacji. Agenci budujący narzędzia pomagają ekspertom tworzyć reprezentację, w której brakujące ograniczenia, nieprawidłowe typy i błędne warunki końcowe stają się jawne.

Żadne z tych podejść nie powinno działać samodzielnie. Modele mogą ujawniać hipotezy, których analizatory statyczne nie kodują. Analiza statyczna może objąć ścieżki wykonania, które probabilistyczny recenzent może przeoczyć. Dowód formalny może następnie dotyczyć wybranych właściwości według standardu możliwego do sprawdzenia przez maszynę.

Proces ten tworzy również obowiązki utrzymaniowe. Parsery muszą nadążać za zmianami języka. Analizatory potrzebują zestawów testów regresyjnych. Modele formalne muszą pozostać zgodne z semantyką VM. Wygenerowane narzędzia, które stają się nieaktualne, mogą tworzyć fałszywe poczucie pewności.

Trail of Bits informuje, że zespół Miden przyjął silnik analizy statycznej do przyszłych aktualizacji podstawowej biblioteki. To ważny sygnał, ponieważ wyprowadza narzędzia poza pojedynczy obraz audytu. Dalsze użycie sprawdzi, czy analizator pozostaje przydatny wraz z ewolucją języka i biblioteki.

Organizacje rozważające podobny przepływ pracy powinny także planować pochodzenie zmian. Zespoły muszą wiedzieć, który model wygenerował zmianę, który człowiek ją przejrzał, które testy zostały uruchomione oraz jakie założenia wprowadzono do dowodu. Przepływ pracy inżynierskiej jest tylko tak możliwy do przejrzenia, jak zapisy zachowane wokół niego.

Publiczne dowody wspierają zatem ograniczony wniosek. Agenci umożliwili ambitny program przygotowawczy dla tego zlecenia. Pewność bezpieczeństwa nadal wynikała z połączonego systemu ekspertów dziedzinowych, testów, jawnych analiz i sprawdzania dowodów.

Ten system jest ciekawszy niż twierdzenie, że AI znalazła błąd. Oferuje konkretny model wykorzystywania niedoskonałych agentów bez traktowania ich pewności jako dowodu.

Trzy sygnały sprawdzą, czy ten model audytu przetrwa

Kolejnym testem będzie to, czy narzędzia zapewniające jakość zbudowane przez agentów pozostaną poprawne, stosowane i produktywne po medialnych ustaleniach.

Pierwszym sygnałem jest dalsza integracja analizatora MASM z procesem rozwoju Miden. Trail of Bits podaje, że zespół Miden przyjął silnik analizy statycznej dla przyszłych zmian w podstawowej bibliotece. Rutynowe użycie w ciągłej integracji wzmocniłoby argument, że narzędzia audytowe mogą stać się infrastrukturą prewencyjną.

Ważną miarą nie jest liczba generowanych ostrzeżeń. Jest nią to, czy nowe procedury publiczne otrzymują wymaganą walidację przed wydaniem oraz czy aktualizacje analizatora śledzą zmiany w semantyce MASM. Utrzymujące się fałszywe alarmy lub nieaktualne modele osłabiłyby rezultat.

Drugim sygnałem jest rozszerzanie i utrzymywanie 95 dowodów Lean. Dodatkowe zweryfikowane procedury pokazałyby, że początkowy model wspiera ciągłą pracę, a nie jest jedynie stałą demonstracją. Zmiany w istniejącym kodzie arytmetycznym powinny również wywoływać aktualizacje dowodów lub ich niepowodzenia.

Warto obserwować granicę między przetłumaczonym kodem a specyfikacjami przeglądanymi ręcznie. Automatyzacja zwiększająca liczbę dowodów bez wzmacniania zakresu twierdzeń nie zapewniłaby takiej samej pewności. Jasna dokumentacja założeń będzie równie ważna jak surowa liczba.

Trzecim sygnałem jest replikacja przez inne zespoły audytowe i ekosystemy językowe. Miden stanowił wyjątkowo odpowiednią kombinację: niestandardowy język, brakujące narzędzia, jawna semantyka dowodów i miesiące czasu na przygotowanie.

Powtarzalny wzorzec w różnych zkVM lub językach niskiego poziomu wsparłby szersze twierdzenie ekonomiczne Trail of Bits. Niemożność jego odtworzenia w systemach ze współbieżnością, złożoną pamięcią lub dużymi grafami zależności ujawniłaby jego ograniczenia.

Audyt Miden przeprowadzony przez Trail of Bits przyniósł już więcej niż spekulatywny przepływ pracy. Dostarczył integrację z edytorem, dekompilator, analizator, model VM, sprawdzone dowody oraz konkretne ustalenia dotyczące bezpieczeństwa.

Trwałe pytanie brzmi, czy zespoły potrafią utrzymać te artefakty w zgodzie z systemami, które chronią. Deweloperzy oceniający bezpieczeństwo wspierane przez agentów powinni przeanalizować repozytoria, sprawdzić modelowane założenia i zapytać, gdzie weryfikowalne maszynowo mechanizmy kontroli zastępują zaufanie do modelu. To standard, który warto zachować na kolejny audyt.