Szkic smart kontrakt może przejść wszystkie generowane przez AI testy, a nadal zawierać poważną lukę bezpieczeństwa. Problem nie polega na tym, że testowanie nie ma wartości. Problemem jest to, że przejście testów może wygenerować poziom zaufania, którego nie popiera dowód.
To jest fałszywe przekonanie. Pojawia się ono, gdy zespół widzi zielone wyniki testów, czyta jasne wyjaśnienie od AI i przestaje zadawać trudne pytania.
Test udowadnia jedną wąską rzecz. Pokazuje, że kod zachowywał się zgodnie z oczekiwaniami w warunkach tego konkretnego testu. Nie dowodzi, że kod jest bezpieczny w każdym stanie, wobec każdego użytkownika ani przy każdej możliwej sekwencji działań.
Ta różnica ma znaczenie w systemach blockchaina. Smart kontrakty mogą przechowywać pieniądze, egzekwować reguły i współdziałać z nieznanymi użytkownikami. Po wdrożeniu niektóre części mogą być trudne lub niemożliwe do zmiany. Przegapione założenie może stać się ścieżką ataku.
Jak AI tworzy iluzję bezpieczeństwa
AI może generować kod szybko. Może również generować testy jednostkowe dla tego kodu. Wydaje się to wydajne. Programista opisuje zamierzone zachowanie, otrzymuje implementację, a następnie prosi ten sam system o utworzenie testów.
Niebezpieczeństwo polega na tym, że ten sam model kontroluje teraz kilka części procesu. Pisze kod. Decyduje, jakie zachowanie jest istotne. Tworzy testy dla tego zachowania. Może również wyjaśnić, dlaczego wynik wygląda na bezpieczny.
Tworzy to monokulturę oprogramowania. Kod i testy dzielą te same ślepe plamy.
Zestaw testów może wyglądać na szeroki, ponieważ zawiera wiele plików i przypadków. Jednak testy mogą powtarzać te same założenia. Mogą sprawdzać normalne wpłaty, normalne wypłaty i oczekiwane uprawnienia. Mogą nigdy nie pytać, co się dzieje, gdy użytkownik łączy działania w nieoczekiwanej kolejności.
AI ma również silną tendencję do brzmięcia pewnie. Może opisywać kod jako czysty, solidny lub wolny od problemów bez udowodnienia tych twierdzeń. Jasny język brzmi jak ostrożne rozumowanie. To nie to samo.
Ten pewny ton wpływa na ludzką ocenę. Programiści mogą zacząć ufać wyjaśnieniu zamiast inspicować dowody. Błąd automatyzacji sprawia, że wyjście maszyny wydaje się bezpieczniejsze, niż jest w rzeczywistości. Błąd autorytetu sprawia, że pewna odpowiedź wydaje się poprawna.
Efekt może być silniejszy, gdy ludzie są zmęczeni, spieszą się lub są chętni do zakończenia pracy. Zielony dashboard jest uspokajający. Ukojenie nie jest właściwością bezpieczeństwa.
Przejście testów dowodzi mniej, niż myślą zespoły
Rozważ prosty token kontrakt z funkcją wypłaty. Zamierzona zasada jest prosta:
- Użytkownik może wypłacić tylko swój własny saldo.
- Kontrakt musi zmniejszyć saldo po wypłacie.
- Użytkownik musi otrzymać prawidłową kwotę.
System AI może generować testy dla tych zasad. Testy mogą przejść. Jest to użyteczny dowód.
Teraz dodaj drugą zasadę. Wypłata może uruchomić inny kontrakt. Ten kontrakt woła z powrotem do oryginalnego przed zakończeniem aktualizacji salda. Jeśli oryginalny kontrakt nie obsługuje tej sekwencji bezpiecznie, atakujący może wypłacić ponownie podczas callbacku.
Normalne testy mogą nigdy nie stworzyć tej sytuacji. Każdy test może przejść, ponieważ każdy test podąża oczekiwaną ścieżką.
Błąd żyje w nieprzetestowanym założeniu: wywołujący zachowuje się jak normalny użytkownik i nie atakuje procesu. Na publicznym blockchainie to założenie ma niewielką wartość. Wywołującym może być każdy. Wywołujący może wybrać timing, kolejność, wartości wejściowe i wielokrotne interakcje.
Ten przykład pokazuje również, dlaczego liczba testów jest słabym dowodem. Dziesięć testów może przegapić ten sam atak co jeden test. Sto testów może nadal dzielić jedną ślepą plamę.
Ważnym pytaniem nie jest „Ile testów przeszło?”. Pytaniem jest „Jakich założeń testy zakwestionowały?”
Blockchain zwiększa presję na problem
Wiele systemów oprogramowania spotyka się z wrogim wejściem. Systemy blockchaina dodają zachęty finansowe i publiczny dostęp. Atakujący może inspicować wdrożony kod, obserwować transakcje i szukać zyskownej sekwencji działań.
Smart kontrakty mają również stan. Jedna transakcja zmienia to, co może zrobić następna transakcja. Bezzębne działanie w izolacji może stać się niebezpieczne po kilku innych działaniach. Testowanie pojedynczych funkcji nie zawsze ujawnia te zmiany stanu.
Logika ekonomiczna tworzy kolejną warstwę ryzyka. Kontrakt może podążać swoim kodem, a nadal zachowywać się szkodliwie. Zasada cenowa, system nagród, zasada likwidacji lub kalkulacja opłat mogą tworzyć zachętę dla użytkowników do wypompowania wartości.
Generowane przez AI testy często skupiają się na widocznym zachowaniu kodu. Mogą sprawdzać, czy funkcja zwraca oczekiwany wynik. Mogą przegapić to, czy cały system daje atakującemu powód do wywołania tej funkcji w określonej kolejności.
To jest miejsce, gdzie zmienność, zachęty i publiczni przeciwnicy mnożą ryzyko. Kod nie działa w cichej laboratorium. Działa w systemie, w którym inni aktorzy mogą się do niego dostosować.
Narzędzia zautomatyzowane mogą przegapić błędy i produkować fałszywe alarmy. Rygorystyczne testowanie może zmniejszyć ryzyko, ale nie może udowodnić, że kontrakt nie ma nieznanych wad. Niezależna recenzja dodaje inną perspektywę, ponieważ recenzenci nie byli zaangażowani w tworzenie oryginalnych założeń.
Jak wygląda silniejszy proces recenzji
Pierwszym krokiem jest bezpieczne domniemanie: traktuj pokrycie testami AI jako niekompletne.
Oznacza to nie odrzucanie AI. AI może przyspieszyć tworzenie testów i pomóc znaleźć powszechne błędy. Może również sugerować przypadki brzegowe, które programista mógł przeoczyć. Przydatną rolą jest akceleracja, a nie posiadanie ostatecznej decyzji dotyczącej ryzyka.
Same testy potrzebują recenzji. Nazwa testu może brzmieć imponująco, a nadal sprawdzać bardzo mało. Wejście może być zbyt zwyczajne. Stan może być zbyt prosty. Test może weryfikować, że funkcja robi to, co już mówi implementacja, zamiast sprawdzać, czy implementacja podąża za regułą biznesową.
Recenzja bezpieczeństwa powinna szukać niewygodnych dowodów. Recenzent może zadać pytania:
- Co się dzieje, gdy wołania występują w nietypowej kolejności?
- Które działania można powtarzać?
- Co jeśli inny kontrakt woła tę funkcję?
- Co jeśli cena, saldo lub uprawnienie zmienia się między krokami?
- Które założenia zależą od uczciwych użytkowników?
- Jaka wartość może uzyskać atakujący z naruszenia oczekiwanej przepływu?
Te pytania przesuwają cel od potwierdzania projektu do jego kwestionowania.
Testowanie adversarialne również wymaga ludzkiej odpowiedzialności. Ograniczenia bezpieczeństwa AI mogą uniemożliwiać modelowi pełną symulację szkodliwego planowania ataku. Zespoły bezpieczeństwa nadal muszą myśleć jak atakujący i testować ścieżki, których unikają normalne przykłady.
Testowanie nie powinno być jedynym warunkiem wypuszczenia. Niezależny audyt może zbadać całą bazę kodu i kwestionować wybory projektowe spoza oryginalnego pętli rozwoju. Nie tworzy to gwarancji. Tworzy kolejną szansę na ujawnienie ślepych plam.
Znane problemy również potrzebują jasnych rekordów. Tabela ryzyka może wymienić każdy otwarty problem, jego możliwe skutki, bieżącą kontrolę i osobę, która akceptuje pozostałe ryzyko. Podpisanie ma znaczenie, ponieważ czyni decyzję widoczną. Zapobiega zaniknięciu nierozwiązanej obawy wewnątrz raportu przechodzącego testu.
Zespoły potrzebują również właściwej kultury. Nagradzanie ludzi tylko za dodawanie testów może produkować duże zestawy ze słabym pokryciem. Nagradzanie ostrożnych pytań tworzy lepszą presję. Zdrowy sceptycyzm różni się od odmowy przyjęcia każdego narzędzia. Celem jest sprawienie, by pewność sobie zarobiła swoje miejsce.
Projekt może zyskać impet i nadal być niebezpieczny. Żądanie ukończenia może cicho zastąpić obowiązek recenzji. Tak właśnie długa lista udanych testów staje się sygnałem zatrzymania.
Praktyczny limit testowania AI
AI może pomóc znaleźć defekty szybciej. Może tworzyć przykłady, sugerować przypadki brzegowe i ujawniać proste błędy. Te korzyści są rzeczywiste.
Limitem jest autorytet. AI nie posiada konsekwencji złego wdrożenia. Nie rozumie wszystkich zachęt finansowych w kontrakcie. Nie wie automatycznie, które założenia atakujący wykorzysta.
Przechodzący test generowany przez AI to dowód o przetestowanym zachowaniu. Nie jest to dowód, że wszystkie ważne zachowania zostały przetestowane. Pewne wyjaśnienie to twierdzenie, nie dowód.
Przydatnym modelem mentalnym jest prosty: AI dodaje kolejną ścieżkę do znajdowania problemów. Nie usuwa normalnego procesu bezpieczeństwa. Ludzka recenzja, testowanie adversarialne, niezależne audyty i jawne decyzje dotyczące ryzyka nadal mają oddzielne zadania.
Czytelnik może teraz oddzielić sukces testów od pewności bezpieczeństwa. Następna recenzja może skupić się na założeniach, zmianach stanu, zachętach i zachowaniu atakującego zamiast tylko na liczbach testów. To jest mała zmiana w języku, ale prowadzi do lepszych decyzji inżynierskich.
To jest rodzaj praktycznego rozróżnienia, wokół którego zbudowano The Model Log: jedna koncepcja AI, jeden działający przykład i jedna szczera analiza tego, co naprawdę działa.
