Печалби:
- Способността да се разбере, че изкуственият интелект разширява обхвата на одитора, но не го замества, и е полезен при сканиране на категории и изготвяне на намиране.
- Да можеш да разпознаеш, че изкуственият интелект е пропуснал първоначалната уязвимост и грешка в бизнес логиката и че гладкото „сигурно“ изявление не е гаранция
- Способност за класифициране на констатациите според тяхното ниво на сериозност и разбиране, че окончателното одобрение и професионалната отговорност са на компетентния одитор.
Одитът на сигурността (систематично изследване на интелигентен договор за уязвимости) е най-отговорната работа на Web3. Един единствен ред, пропуснат от одитор, може да доведе до милиони долари загуби. В този модул ще научите как да използвате AI като асистент за одит; Ще се учим от генерирането на улики до написването на схема на констатациите. Но най-критичното изречение е следното: AI не контролира; Това е помощник, който изостря окото на одитора. Окончателното одобрение е на компетентния одитор, който поема професионалната отговорност.
Защо одитът е критичен за сигурността
Одитен доклад уверява проекта и инвеститорите, че „този код е прегледан“. Ако тази увереност е фалшива, последствията са катастрофални: експлоатиран протокол, загубено финансиране, рухнал проект. Следователно използването на AI при проверка е най-внимателната част от този модул. AI разширява обхвата на одитора (припомня повече модели, чете по-бързо), но не замества одитора.
Защо не минава? защото:
- AI не може да види уникалната/новата уязвимост, която не е в данните за обучение.
- AI често пропуска недостатъка в бизнес логиката на протокола - че кодът е технически правилен, но икономически използваем.
- AI може да даде фалшива увереност, като каже „безопасно“ на гладък език; Това е най-опасният резултат.
Слоеве на използване на AI в контрола
1. Първоначално сканиране и напомняне за шаблон. AI преминава през известни модели на уязвимост като списък за проверка: повторно влизане, контрол на достъпа, манипулиране на оракул, изпреварване. Това гарантира, че одиторът няма да пропусне нито една категория.
2. Обяснение на кода. Обясняването на сложна функция на AI на обикновен език позволява на одитора бързо да схване логиката; но описанието винаги се сравнява с кода.
3. Писане на чернова на констатациите. Когато одиторът открие уязвимост, AI спестява време при писане на черновата на доклада (описание, въздействие, предложено решение).
4. Генериране на контрахипотеза. Попитайте AI "как може да се злоупотребява с тази функция?" Питането ни напомня за агресивната перспектива.
Внимание: Само защото изкуственият интелект казва „Не открих никакви уязвимости в този код“ НЕ означава „този код е безопасен“. Доказателство за липса не е липса на доказателство. Фактът, че AI не може да намери нещо, не прави ненужно одиторът да изследва тази област.
Намиране на нива на тежест
Констатациите от одита се класифицират според нивото им на тежест. AI трябва да използва тази рамка, когато генерира чернови:
Ниво
Значение
пример
критичен
Директна възможна загуба на средства/заключване
Теглене на средства с повторно влизане
високо
Сериозно въздействие при определени условия
Неоторизиран печат (монетния двор)
среден
Ограничено въздействие или трудно състояние
Малка загуба с отклонение от Oracle
ниско
Малък риск, нарушение на добрата практика
Липсва предаване на събитието
Информация
Несигурност, четливост
Липса на NatSpec
Слаба подкана / Силна подкана
Слаба подкана:
Безопасен ли е този договор?
Този въпрос принуждава AI да направи абсолютна, неоправдана преценка като „да/не“ – точно това, което не искаме.
Мощна подкана:
Вашата роля: асистент на старши одитор на интелигентни договори. Сканирайте следния договор за сигурност. Преминете през следните категории една по една: повторно влизане, контрол на достъпа, целочислени операции, валидиране на вход, оракул/външни данни, първоначално изпълнение, ограничение на газа. За всяка КОНСТАТАЦИЯ: (1) подходящ ред от код, (2) причина за риск, (3) прогнозна сериозност (критична/висока/средна/ниска), (4) предложение за решение. Това са ХИПОТЕЗИ, КОИТО ТРЯБВА ДА БЪДАТ ПОТВЪРДЕНИ; Не давайте „безопасна“ присъда. Маркирайте областите, в които не сте сигурни, като ясно кажете „оставете одитора да потвърди“.
Четири копируеми шаблона
1) Сърфиране въз основа на категория:
Сканирайте този договор за следните категории: повторно влизане, контрол на достъпа, целочислено препълване, валидиране на входа, зависимост от оракул, първоначално изпълнение, DoS/газ. За всяка категория кажете „няма/няма риск/не съм сигурен“ и свържете обосновката си с реда в кода. Не правете окончателна преценка.
2) Контрахипотеза от гледна точка на нападателя:
Мислете като нападател: какви са начините за злоупотреба с тази функция? Напишете всеки сценарий стъпка по стъпка и посочете какви условия са необходими. Тези сценарии са хипотезите, които трябва да бъдат тествани; НЕ генерирайте действителен експлойт код, просто опишете риска.
3) Проект на констативен доклад:
Докладвайте следната проверена констатация на официалния език на одита: заглавие, сериозност, описание, въздействие, засегнат код, стъпки за възпроизвеждане, предложено решение. Използвайте премерен и технически език; преувеличение. Да предположим, че констатацията е потвърдена от одитора, не правете нова констатация.
4) Проверка на коригиране:
По-долу е дадена уязвимост и корекцията, приложена от разработчика. Проверете дали корекцията наистина затваря уязвимостта; маркирайте дали създава нов страничен ефект или уязвимост. Не казвайте със сигурност „затворено“; Завършете с „трябва да се потвърди чрез тестване“.
Три мини калъфа (в брой)
Случай 1 — AI предотврати прескачане на категории. Един одитор беше на път да се съсредоточи върху договор от 400 реда и да пропусне категорията оракул. Сканирането на категорията на AI даде предупреждение, че „данните за цените са от един източник, отворени за манипулация“. Одиторът го прегледа и установи, че наистина е среден риск. Урок: AI поддържа дисциплина на покритието.
Случай 2 — Фалшива увереност за „безопасност“. Друг екип попита AI "това безопасно ли е?" попита той; „Изглежда, че няма значителен проблем“, каза AI. Проверката на екипажа беше лека. Тогава независимият одитор откри грешка в бизнес логиката: изчисление, което беше технически правилно, но чиито стимули можеха да се използват. Урок: AI пропуска грешка в бизнес логиката; Не може да му се вярва, че ще каже „безопасен“.
Случай 3 — Изготвянето на доклада спестява 3 часа. Одиторът прекарваше половината ден, докладвайки ръчно 8 констатации. След като дадох проверените констатации на AI и отпечатах официалния проект, времето спадна с ~3 часа; Одиторът отдели време за задълбочаване. Урок: AI е безопасен и ефективен при отчитането, тъй като констатациите вече са проверени от хора.
Уязвимост на бизнес логиката: Сляпо петно на AI
Най-скъпите уязвимости често идват не от техническа грешка в кода, а от възможността за използване на бизнес логиката: закръгляване на използване на награден акаунт, бързо отвличане на заем на глас, мигновено манипулиране на цена. Това са случаи, в които кодът работи "правилно", но протоколът може да бъде измамен икономически. AI вероятно ще пропусне такива грешки - особено тези, специфични за протокола. Следователно прегледът на бизнес логиката е най-интензивната от хората област на одитора и най-малко зависима от AI.
Съвет: Попитайте AI "как могат да се използват икономическите стимули на този протокол?" и използвайте сценариите, които се появяват като отправна точка – но не забравяйте, че вие и вашият екип трябва да направите истинския анализ.
Често срещани грешки
- Попитайте AI "безопасно ли е?" Искам и се доверявам на вашето да. Не е необходима категорична преценка.
- Спиране на прегледа, когато AI каже "Не можах да го намеря". Отсъствието не е доказателство.
- Делегиране на преглед на бизнес логиката на AI. Това е най-голямата му сляпа точка.
- Без използване на независими инструменти (Slither и др.). AI сам по себе си не е достатъчен.
- Поставяне на констатацията, направена от AI в доклада, без да се проверява. Риск от халюцинации.
- Опитвайки се да прехвърлите отговорността за контрол върху AI. Отговорността е на експерта.
В обобщение
- Одитът е критичен за безопасността; AI разширява обхвата на одитора, но не го замества.
- AI пропуска оригиналната уязвимост и грешка в бизнес логиката; Казването „безопасно“ не е гаранция.
- Находките се класифицират според нивото на тежест; AI е полезен при генериране на чернови.
- Контрахипотезата и проверката на категориите запазват дисциплината на включването.
- Окончателното одобрение и професионалната отговорност винаги се носят от компетентния одитор.
Задача за приложение
Намерете примерен договор, който съдържа известна уязвимост (за образователни цели, примери за „уязвими договори“ са налични в отворен код). Приложете подканата „сканиране въз основа на категория“ към AI. Обърнете внимание дали ИИ: (1) е открил истинската уязвимост, (2) е произвел изфабрикувани/фалшиви констатации, (3) е направил абсолютни преценки като „сигурен“. След това го сравнете с инструмент за статичен анализ.
контролен списък
- [ ] Попитайте AI "безопасно ли е?" Вместо това имах сканиране, базирано на категория.
- [ ] Отнасях се към всяко откритие като към хипотеза.
- [ ] Направих прегледа на бизнес логиката сам/екип.
- [ ] Проверих го кръстосано с независим инструмент за статичен анализ.
- [ ] Потвърдих, че AI не измисля констатации.
- [ ] Класифицирах констатациите според нивото на тежест.
- [ ] Приех, че окончателното одобрение е на компетентния одитор.