Почему аудит смарт-контрактов теряет актуальность из-за ИИ

Одноразовый аудит больше не закрывает threat model

Руководитель отдела политики TRM Labs Ари Редборд формулирует проблему без романтики: отрасли нужна модель непрерывной проверки, а не аудит «на запуск». Его тезис прост: методы атак эволюционируют быстрее, чем отчет, написанный под сценарии прошлого года, способен это учесть.

Это не означает, что классический аудит бесполезен. Он просто имеет срок годности. Особенно если после аудита протокол менял параметры, добавлял модули, переносил контракты, трогал роли администраторов или оставил старую инфраструктуру в полуживом состоянии. В такой архитектуре отчет становится снимком состояния, а не инвариантом безопасности.

Отдельная проблема — доверие к самим формулировкам. «Аудировано» в интерфейсе часто выглядит как печать качества, хотя технически это может означать только проверку конкретного коммита в конкретный момент времени. Здесь полезна та же дисциплина, что и в разборе новостей и пропагандистских тезисов: смотреть не на вывеску, а на проверяемые утверждения — commit hash, scope, найденные issues, статус remediation.

ИИ снижает стоимость поиска старых багов

CertiK, по данным источников, оценила потери криптоиндустрии от взломов в первом полугодии 2026 года в $1,32 млрд. Компания также отмечает новую тенденцию: злоумышленники возвращаются к старым или уже закрытым протоколам. Логика понятна. Заброшенный код редко получает повторный аудит, но активы, права доступа и ошибки в механизмах возврата средств могут жить годами.

Показательный кейс — Zcash. Инженер по безопасности Shielded Labs Тейлор Горнби обнаружил критическую уязвимость с помощью специального audit-агента на базе Claude Opus 4.8 от Anthropic. Ошибка, как сообщается, существовала около четырех лет и потенциально позволяла незаметно создавать фальшивые активы в одном из ключевых приватных пулов сети. После обнаружения ее устранили.

Технический вывод неприятен для команд с большим legacy: если LLM-агент способен быстро прочесывать массивы кода и находить скрытые паттерны, то это работает симметрично. Белый хакер получает инструмент для ресерча. Черный — тоже. Разница не в модели, а в операционной дисциплине проекта: кто первым прогонит код, кто закроет issue, кто мониторит on-chain аномалии.

Что проверять проектам и пользователям

Для команд минимальный набор теперь выглядит так: повторные аудиты старых контрактов, continuous monitoring, пересмотр threat model после каждого существенного изменения архитектуры, отдельная ревизия ролей, upgrade-механизмов и неиспользуемых контрактов. CertiK прямо указывает: проекты со старой инфраструктурой должны считать повторные аудиты регулярным операционным требованием, а не процедурой развертывания.

Для пользователей критерий еще проще. Если протокол показывает только старый audit badge без даты, scope и ссылки на исправленные уязвимости — это не доказательство безопасности. Если проект фактически закрыт, но контракты держат средства или сохраняют права на операции, риск не исчезает вместе с сайтом и Discord.

Есть и обратные примеры. В мае белый хакер 0xflorent помог вернуть 1003 ETH, более $1,7 млн, 48 инвесторам ICO-проекта Hong Coin 2016 года: средства годами были заблокированы из-за ошибки в механизме автоматического возврата. Это хороший кейс не потому, что «ИИ спасает Web3», а потому что старый код продолжает иметь экономические последствия.

Вердикт сухой: аудит смарт-контрактов больше нельзя считать финальным состоянием системы. Это regression test с датой, scope и оверхедом на поддержку. У кого нет повторной проверки и мониторинга, у того не безопасность, а архивный PDF.