Zyski:
- Umiejętność zrozumienia, że sztuczna inteligencja poszerza zakres działania audytora, ale go nie zastępuje i jest przydatna w skanowaniu kategorii i wyszukiwaniu projektów.
- Możliwość rozpoznania, że sztuczna inteligencja przeoczyła pierwotną lukę i błąd logiki biznesowej oraz że płynne „bezpieczne” oświadczenie nie gwarantuje pewności
- Umiejętność klasyfikowania ustaleń według poziomu ich wagi oraz zrozumienie, że ostateczna akceptacja i odpowiedzialność zawodowa spoczywają na kompetentnym audytorze.
Audyt bezpieczeństwa (systematyczne badanie inteligentnego kontraktu pod kątem luk) to najbardziej odpowiedzialne zadanie Web3. Pojedyncza linijka pominięta przez audytora może skutkować wielomilionowymi stratami. W tej części dowiesz się, jak wykorzystać sztuczną inteligencję jako asystenta audytu; Będziemy uczyć się od generowania wskazówek do pisania konspektu ustaleń. Ale najbardziej krytyczne zdanie jest takie: AI nie kontroluje; To asystent, który wyostrza oko audytora. Ostateczna akceptacja należy do kompetentnego audytora, który przyjmuje na siebie odpowiedzialność zawodową.
Dlaczego inspekcja ma kluczowe znaczenie dla bezpieczeństwa
Raport z audytu zapewnia projekt i inwestorów, że „ten kodeks został sprawdzony”. Jeśli to zapewnienie jest fałszywe, konsekwencje są katastrofalne: wykorzystany protokół, utrata funduszy, upadek projektu. Dlatego wykorzystanie sztucznej inteligencji w inspekcji jest najbardziej ostrożną częścią tego modułu. Sztuczna inteligencja poszerza zakres działania audytora (przywołuje więcej wzorców, szybciej czyta), ale nie zastępuje audytora.
Dlaczego to nie przechodzi? Ponieważ:
- Sztuczna inteligencja nie może wykryć unikalnej/nowej luki w zabezpieczeniach, której nie ma w danych szkoleniowych.
- Sztuczna inteligencja często przeocza wadę logiki biznesowej protokołu — fakt, że kod jest poprawny technicznie, ale możliwy do ekonomicznego wykorzystania.
- Sztuczna inteligencja może dać fałszywe zapewnienie, mówiąc płynnie „bezpieczne”; To najniebezpieczniejszy wynik.
Warstwy wykorzystania sztucznej inteligencji do kontroli
1. Wstępne skanowanie i przypomnienie wzoru. Sztuczna inteligencja przechodzi przez znane wzorce podatności na ataki w formie listy kontrolnej: ponowne wejście, kontrola dostępu, manipulacja wyrocznią, front-running. Dzięki temu audytor nie pominie żadnej kategorii.
2. Wyjaśnienie kodu. Wyjaśnienie AI złożonej funkcji prostym językiem pozwala audytorowi szybko zrozumieć logikę; ale opis jest zawsze porównywany z kodem.
3. Napisanie projektu ustaleń. Gdy audytor znajdzie podatność, AI oszczędza czas na pisaniu projektu raportu (opis, wpływ, proponowane rozwiązanie).
4. Generowanie kontrhipotezy. Zapytaj sztuczną inteligencję „w jaki sposób można nadużyć tej funkcji?” Pytanie” przypomina nam o perspektywie agresywnej.
Uwaga: To, że sztuczna inteligencja mówi „Nie znalazłem żadnych luk w tym kodzie”, NIE oznacza, że „ten kod jest bezpieczny”. Dowód na nieobecność nie jest brakiem dowodu. To, że sztuczna inteligencja nie może czegoś znaleźć, nie powoduje, że audytor nie musi badać tego obszaru.
Znajdowanie poziomów ważności
Ustalenia audytu są klasyfikowane według poziomu ich istotności. AI powinna używać tych ram podczas generowania wersji roboczych:
Poziom
Znaczenie
przykład
krytyczny
Możliwa bezpośrednio utrata/blokada środków
Wypłata środków z ponownym wejściem
wysoki
Poważny wpływ w pewnych warunkach
Nieautoryzowany nadruk (miętowy)
średni
Ograniczony wpływ lub trudny stan
Mała strata z odchyleniem od Oracle
niski
Niewielkie ryzyko, naruszenie dobrych praktyk
Brak transmisji wydarzenia
Informacje
Brak bezpieczeństwa, czytelność
Brak NatSpeca
Słaba zachęta/silna zachęta
Słaba zachęta:
Czy ta umowa jest bezpieczna?
To pytanie zmusza sztuczną inteligencję do podjęcia absolutnej, nieuzasadnionej oceny w stylu „tak/nie” – dokładnie tego, czego nie chcemy.
Potężny monit:
Twoja rola: asystent starszego audytora inteligentnych kontraktów. Zeskanuj poniższą umowę ze względów bezpieczeństwa. Przejrzyj kolejno następujące kategorie: ponowne wejście, kontrola dostępu, operacje na liczbach całkowitych, walidacja danych wejściowych, dane Oracle/zewnętrzne, front-running, limit gazu. Dla każdego WYNIKU: (1) odpowiednia linia kodu, (2) ryzyko przyczyny, (3) szacowana dotkliwość (krytyczna/wysoka/średnia/niska), (4) propozycja rozwiązania. Są to hipotezy do potwierdzenia; Nie wydawaj „bezpiecznego” werdyktu. Zaznacz obszary, których nie jesteś pewien, wyraźnie mówiąc „pozwól audytorowi potwierdzić”.
Cztery szablony do kopiowania
1) Przeglądanie według kategorii:
Zeskanuj tę umowę pod kątem następujących kategorii: ponowne wejście, kontrola dostępu, przepełnienie liczb całkowitych, sprawdzanie poprawności danych wejściowych, zależność od Oracle, front-running, DoS/gaz. W przypadku każdej kategorii powiedz „nie ma/nie ma ryzyka/nie jestem pewien” i połącz swoje uzasadnienie z linią kodu. Nie wydawaj ostatecznego osądu.
2) Kontrhipoteza z perspektywy atakującego:
Myśl jak atakujący: jakie są sposoby na nadużycie tej funkcji? Napisz krok po kroku każdy scenariusz i wskaż, jakie warunki są wymagane. Scenariusze te stanowią hipotezy, które należy przetestować; NIE generuj rzeczywistego kodu exploita, po prostu opisz ryzyko.
3) Projekt raportu z ustaleń:
Zgłoś następujące zweryfikowane ustalenia w formalnym języku audytu: tytuł, istotność, opis, wpływ, kod, którego dotyczy problem, kroki niezbędne do odtworzenia, proponowane rozwiązanie. Używaj wyważonego i technicznego języka; przesada. Załóżmy, że audytor potwierdził ustalenie i nie wymyślaj nowego ustalenia.
4) Napraw weryfikację:
Poniżej znajduje się luka i poprawka zastosowana przez programistę. Sprawdź, czy poprawka rzeczywiście zamyka lukę; zaznacz, czy powoduje to nowy efekt uboczny lub lukę w zabezpieczeniach. Na pewno nie mów „zamknięte”; Zakończ słowami „należy potwierdzić testami”.
Trzy mini etui (w liczbach)
Przypadek 1 – sztuczna inteligencja uniemożliwiła przeskakiwanie kategorii. Audytor miał właśnie skupić się na umowie składającej się z 400 linii i pominąć kategorię wyrocznia. Skan kategorii dokonany przez sztuczną inteligencję ostrzegł, że „dane dotyczące cen pochodzą z jednego źródła i mogą podlegać manipulacji”. Audytor zbadał to i stwierdził, że rzeczywiście było to średnie ryzyko. Lekcja: Sztuczna inteligencja utrzymuje dyscyplinę zasięgu.
Przypadek 2 – Fałszywa pewność „bezpieczności”. Inny zespół zapytał sztuczną inteligencję „czy to bezpieczne?” zapytał; „Wydaje się, że nie ma większego problemu” – stwierdziła AI. Kontrola załogi była niewielka. Następnie niezależny audytor znalazł błąd w logice biznesowej: obliczenia, które były technicznie poprawne, ale których zachęty można było wykorzystać. Lekcja: AI pomija błąd logiki biznesowej; Nie można mu ufać, że powie „bezpieczny”.
Przypadek 3 — Sporządzenie raportu pozwoliło zaoszczędzić 3 godziny. Audytor spędzał pół dnia na ręcznym zgłaszaniu 8 ustaleń. Gdy przekazałem AI zweryfikowane ustalenia i wydrukowałem oficjalny projekt, czas skrócił się o ~3 godziny; Audytor poświęcił czas na pogłębienie. Lekcja: Sztuczna inteligencja jest bezpieczna i skuteczna w raportowaniu, ponieważ ustalenia zostały już zweryfikowane przez człowieka.
Luka w logice biznesowej: martwy punkt sztucznej inteligencji
Najdroższe luki często nie wynikają z błędu technicznego w kodzie, ale z możliwości wykorzystania logiki biznesowej: zaokrąglania wykorzystania konta z nagrodami, przejmowania głosowania w formie pożyczki błyskawicznej, natychmiastowej manipulacji ceną. Są to przypadki, w których kod działa „poprawnie”, ale protokół można oszukać ekonomicznie. Sztuczna inteligencja prawdopodobnie przeoczy takie błędy – zwłaszcza te specyficzne dla protokołu. Dlatego przegląd logiki biznesowej jest obszarem najbardziej angażującym człowieka i najmniej zależnym od AI.
Wskazówka: zapytaj sztuczną inteligencję „w jaki sposób można wykorzystać zachęty ekonomiczne wynikające z tego protokołu?” i wykorzystaj pojawiające się scenariusze jako punkt wyjścia — pamiętaj jednak, że Ty i Twój zespół powinniście przeprowadzić prawdziwą analizę.
Typowe błędy
- Zapytaj sztuczną inteligencję „czy to bezpieczne?” Prosić i ufać Twojemu „tak”. Absolutny osąd nie jest wymagany.
- Zatrzymanie recenzji, gdy sztuczna inteligencja powie „Nie mogłem tego znaleźć”. Nieobecność nie jest dowodem.
- Delegowanie przeglądu logiki biznesowej do AI. To jego największy martwy punkt.
- Nieużywanie niezależnych narzędzi (Slither itp.). Sama sztuczna inteligencja nie wystarczy.
- Umieszczenie ustalenia AI w raporcie bez jego weryfikacji. Ryzyko halucynacji.
- Próbuję zrzucić odpowiedzialność za kontrolę na sztuczną inteligencję. Odpowiedzialność spoczywa na ekspertze.
Podsumowując
- Audyt ma kluczowe znaczenie dla bezpieczeństwa; Sztuczna inteligencja poszerza zakres działania audytora, ale go nie zastępuje.
- AI pomija pierwotną lukę i błąd logiki biznesowej; Powiedzieć „bezpieczne” nie gwarantuje.
- Wyniki są klasyfikowane według poziomu ważności; Sztuczna inteligencja jest przydatna w generowaniu przeciągów.
- Kontrhipotezy i selekcja kategorii utrzymują dyscyplinę włączania.
- Ostateczna akceptacja i odpowiedzialność zawodowa zawsze spoczywa na kompetentnym audytorze.
Zadanie aplikacji
Znajdź przykładową umowę zawierającą znaną lukę w zabezpieczeniach (w celach edukacyjnych przykłady „umów zawierających lukę” są dostępne w oprogramowaniu open source). Zastosuj monit „skanowanie w oparciu o kategorię” do AI. Należy zwrócić uwagę, czy sztuczna inteligencja: (1) znalazła rzeczywistą lukę, (2) stworzyła sfabrykowane/fałszywe ustalenia, (3) wydała bezwzględną ocenę, np. „bezpieczna”. Następnie porównaj to z narzędziem do analizy statycznej.
lista kontrolna
- [ ] Zapytaj sztuczną inteligencję „czy to bezpieczne?” Zamiast tego miałem skanowanie oparte na kategoriach.
- [ ] Każde ustalenie traktowałem jako hipotezę.
- [ ] Sam/zespół przeprowadziłem przegląd logiki biznesowej.
- [ ] Sprawdziłem to krzyżowo za pomocą niezależnego narzędzia do analizy statycznej.
- [ ] Potwierdziłem, że sztuczna inteligencja nie fabrykuje ustaleń.
- [ ] Sklasyfikowałem ustalenia według poziomu dotkliwości.
- [ ] Przyjąłem, że ostateczna akceptacja należy do kompetentnego audytora.