Прибыль:
- Способность понимать, что искусственный интеллект расширяет сферу деятельности аудитора, но не заменяет ее, и полезен при сканировании категорий и поиске чертежей.
- Способность признать, что искусственный интеллект упустил изначальную уязвимость и ошибку бизнес-логики и что беглое заявление о «безопасности» не является гарантией.
- Способность классифицировать выводы в соответствии с уровнем их серьезности и понимать, что окончательное утверждение и профессиональная ответственность лежит на компетентном аудиторе.
Аудит безопасности (систематическая проверка смарт-контракта на наличие уязвимостей) — самая ответственная работа Web3. Одна-единственная строка, пропущенная аудитором, может привести к убыткам в миллионы долларов. В этом модуле вы узнаете, как использовать ИИ в качестве помощника по аудиту; Мы научимся генерировать подсказки и писать план выводов. Но самое критическое предложение таково: ИИ не контролирует; Это помощник, обостряющий глаз одитора. Окончательное утверждение лежит на компетентном аудиторе, который принимает на себя профессиональную ответственность.
Почему аудит имеет решающее значение для безопасности
Аудиторский отчет заверяет проект и инвесторов в том, что «этот кодекс был проверен». Если эта уверенность ложна, последствия будут катастрофическими: использованный протокол, потеря финансирования, крах проекта. Поэтому использование ИИ при проверке — самая тщательная часть этого модуля. ИИ расширяет возможности одитора (запоминает больше закономерностей, быстрее читает), но не заменяет одитора.
Почему не проходит? Потому что:
- ИИ не может увидеть уникальную/новую уязвимость, которой нет в обучающих данных.
- ИИ часто упускает изъян в бизнес-логике протокола — код технически правильный, но экономически пригодный для использования.
- ИИ может давать ложные заверения, говоря «безопасно» на беглом языке; Это самый опасный исход.
Уровни использования ИИ для контроля
1. Первоначальное сканирование и напоминание о шаблоне. ИИ анализирует известные шаблоны уязвимостей, такие как контрольный список: повторный вход, контроль доступа, манипулирование оракулом, опережающее управление. Это гарантирует, что аудитор не пропустит ни одной категории.
2. Объяснение кода. Объяснение сложной функции ИИ простым языком позволяет аудитору быстро уловить логику; но описание всегда сравнивается с кодом.
3. Написание проекта заключения. Когда аудитор обнаруживает уязвимость, ИИ экономит время при написании проекта отчета (описание, влияние, предлагаемое решение).
4. Генерация контргипотезы. Спросите ИИ «как можно злоупотребить этой функцией?» «Просьба» напоминает нам об агрессивной перспективе.
Внимание: То, что ИИ говорит «Я не нашел уязвимостей в этом коде», НЕ означает «этот код безопасен». Доказательства отсутствия не являются отсутствием доказательств. Тот факт, что ИИ не может что-то найти, не освобождает аудитора от необходимости исследовать эту область.
Определение уровней серьезности
Выводы аудита классифицируются в зависимости от степени их серьезности. ИИ должен использовать эту структуру при создании черновиков:
Уровень
Значение
пример
критический
Возможна прямая потеря средств/локаут
Вывод средств с реентерабельностью
высокий
Серьезное воздействие в определенных условиях
Несанкционированная печать (мята)
средний
Ограниченное воздействие или тяжелое состояние
Небольшая потеря при отклонении Oracle
низкий
Незначительный риск, нарушение надлежащей практики
Отсутствует трансляция мероприятия
Информация
Небезопасность, читабельность
Отсутствие NatSpec
Слабая подсказка / Сильная подсказка
Слабая подсказка:
Этот контракт безопасен?
Этот вопрос заставляет ИИ выносить абсолютное, необоснованное суждение типа «да/нет» — именно то, чего мы не хотим.
Мощная подсказка:
Ваша роль: помощник старшего аудитора смарт-контрактов. Для безопасности отсканируйте следующий контракт. Пройдитесь по следующим категориям одну за другой: повторный вход, контроль доступа, целочисленные операции, проверка ввода, оракул/внешние данные, опережающий запуск, ограничение газа. Для каждого ВЫВОДА: (1) соответствующая строка кода, (2) причина риска, (3) предполагаемая серьезность (критическая/высокая/средняя/низкая), (4) предложение по решению. Это ГИПОТЕЗЫ, КОТОРЫЕ БУДУТ ПОДТВЕРЖДЕНЫ; Не давайте «безопасного» вердикта. Отметьте области, в которых вы не уверены, и четко скажите: «Пусть аудитор подтвердит».
Четыре копируемых шаблона
1) Просмотр по категориям:
Просканируйте этот контракт на наличие следующих категорий: повторный вход, контроль доступа, целочисленное переполнение, проверка ввода, зависимость от оракула, опережающий запуск, DoS/gas. Для каждой категории скажите «нет/нет риска/я не уверен» и соедините свое обоснование со строкой кода. Не выносите окончательного суждения.
2) Контргипотеза с точки зрения злоумышленника:
Подумайте как злоумышленник: как можно злоупотребить этой функцией? Напишите каждый сценарий шаг за шагом и укажите, какие условия необходимы. Эти сценарии представляют собой гипотезы, подлежащие проверке; НЕ создавайте реальный код эксплойта, просто опишите риск.
3) Проект отчета о результатах:
Сообщите о следующем подтвержденном выводе на официальном языке аудита: название, серьезность, описание, влияние, затронутый код, шаги по воспроизведению, предлагаемое решение. Используйте размеренный и технический язык; преувеличение. Предположим, что вывод подтвержден аудитором, не придумывайте новый вывод.
4) Исправление проверки:
Ниже представлена уязвимость и исправление, внесенное разработчиком. Проверьте, действительно ли исправление закрывает уязвимость; отметьте, создает ли это новый побочный эффект или уязвимость. Не говорите наверняка «закрыто»; Завершите словами «должно быть подтверждено тестированием».
Три мини-кейса (в цифрах)
Случай 1 — ИИ предотвратил переключение категорий. Одитор собирался сосредоточиться на контракте из 400 строк и пропустить категорию оракула. Сканирование категорий AI выдало предупреждение о том, что «данные о ценах взяты из одного источника и открыты для манипуляций». Аудитор изучил его и обнаружил, что это действительно средний риск. Урок: ИИ поддерживает дисциплину освещения.
Случай 2 — Ложная уверенность в «безопасности». Другая команда спросила ИИ: «Это безопасно?» — спросил он; «Похоже, что серьезной проблемы нет», — сказал AI. Проверка экипажа была легкой. Затем независимый аудитор обнаружил ошибку в бизнес-логике: расчет, который был технически верным, но стимулы которого можно было использовать. Урок: ИИ пропускает ошибку бизнес-логики; Ему нельзя доверять, когда он говорит «в безопасности».
Случай 3 — Составление отчета сэкономило 3 часа. Аудитор потратил половину дня, вручную сообщая о 8 выводах. Как только я передал ИИ проверенные результаты и распечатал официальный черновик, время сократилось примерно на 3 часа; Одитор посвятил время углублению. Урок: ИИ безопасен и эффективен при составлении отчетов, поскольку результаты уже проверены людьми.
Уязвимость бизнес-логики: слепое пятно ИИ
Самые дорогостоящие уязвимости часто возникают не из-за технической ошибки в коде, а из-за возможности использования бизнес-логики: эксплуатация округления вознаграждения, перехват голосов, мгновенная манипуляция ценой. Это случаи, когда код работает «правильно», но протокол можно экономически обмануть. ИИ, скорее всего, пропустит такие ошибки, особенно связанные с протоколом. Поэтому проверка бизнес-логики — самая трудоемкая область работы аудитора и наименее зависимая от ИИ.
Подсказка: спросите ИИ: «Как можно использовать экономические стимулы этого протокола?» и используйте возникающие сценарии в качестве отправной точки, но помните, что вы и ваша команда должны провести настоящий анализ.
Распространенные ошибки
- Спросите ИИ: «Это безопасно?» Спрашивать и доверять своему «да». Абсолютное суждение не требуется.
- Остановка обзора, когда ИИ говорит: «Я не смог его найти». Отсутствие не является доказательством.
- Делегирование проверки бизнес-логики ИИ. Это его самое большое слепое пятно.
- Не использовать независимые инструменты (Slither и т. д.). Одного ИИ недостаточно.
- Внесение вывода, составленного ИИ, в отчет без его проверки. Риск галлюцинаций.
- Пытаются возложить ответственность за контроль на ИИ. Ответственность лежит на эксперте.
В заключение
- Аудит имеет решающее значение для безопасности; ИИ расширяет сферу деятельности аудитора, но не заменяет ее.
- ИИ не учитывает исходную уязвимость и ошибку бизнес-логики; Сказать «безопасно» — это не гарантия.
- Результаты классифицируются в зависимости от уровня тяжести; ИИ полезен при создании черновиков.
- Контргипотеза и проверка категорий сохраняют дисциплину включения.
- Окончательное утверждение и профессиональная ответственность всегда лежит на компетентном аудиторе.
Задача приложения
Найдите образец контракта, содержащего известную уязвимость (в образовательных целях примеры «уязвимых контрактов» доступны в открытом исходном коде). Примените к ИИ подсказку «сканирование по категориям». Обратите внимание, что ИИ: (1) обнаружил реальную уязвимость, (2) выдал сфабрикованные/ложные выводы, (3) вынес абсолютные суждения, такие как «безопасность». Затем сравните его с инструментом статического анализа.
контрольный список
- [ ] Спросите ИИ: «Это безопасно?» Вместо этого у меня было сканирование по категориям.
- [ ] Я рассматривал каждое открытие как гипотезу.
- [ ] Я провел проверку бизнес-логики самостоятельно/в команде.
- [ ] Я проверил это с помощью независимого инструмента статического анализа.
- [ ] Я подтвердил, что ИИ не фабрикует выводы.
- [ ] Я классифицировал результаты по степени тяжести.
- [ ] Я согласен с тем, что окончательное утверждение остается за компетентным аудитором.