Почему ручной аудит смарт-контрактов пропускает уязвимости
Аудит смарт-контрактов до сих пор держится на человеке: ревьюер читает логику, сверяет её с замыслом и проверяет граничные условия вызовов. Пока контракт укладывается в несколько сотен строк, ручная проверка кода уверенно находит и опасный порядок внешних вызовов, и дыры в разграничении прав, и необработанные отказы при переводах средств.
Проблема проявляется на объёме изменений. Когда в одном релизе смешаны новая логика, миграция состояния и переименования, ревьюер теряет контекст между проверками: он судит о функции по последней прочитанной версии, а не по всей цепочке правок. Пропущенные уязвимости оседают при этом не в ядре, а в обвязке — модификаторах доступа, расчёте комиссий, ветках при нулевых и максимальных значениях.
Отдельный источник — регресс после правок. Правка одной функции меняет состояние, от которого зависят соседние, и без повторного прогона всего набора проверок дефект возвращается уже в другом месте. Накопление мелких правок без повторного разбора сдвигает поведение системы незаметно для глаза.
И ещё одно: у ручного разбора нет воспроизводимых сценариев. Каждый аудит начинается с чистого листа, негативные кейсы держатся в голове ревьюера и не переиспользуются от контракта к контракту. Разбираем, как это закрывается.
Что даёт автоматический анализ кода: измеримые эффекты
Автоматический анализ кода не заменяет аудит целиком, а перераспределяет внимание: машина закрывает типовые классы отказов, инженер разбирает экономику, права ролей и сценарии, которые из шаблонов не выводятся. Прогон занимает минуты, поэтому проверка живёт в конвейере сборки и запускается на каждое изменение, а не однократно перед выпуском.
Первый уровень — формальные правила и символьное исполнение: таким набором, как Slither, проверяют весь репозиторий, включая внешние библиотеки, а не только изменённые файлы. Второй — ручная инспекция критичных путей: выпуск средств, обновление логики, права администратора.
| Что измеряем | До внедрения | После | За счёт чего |
|---|---|---|---|
| Доля найденных дефектов | 6–7 классов из 10 при ручном чтении | 9–10 из 10, остаток — экономика и права | Весь код под проверкой на каждом изменении |
| Время проверки перед выпуском | неделя ручной инспекции на релиз | часы прогона и день на разбор значимых находок | Проверка идёт параллельно разработке |
| Простой при отказе | часы на поиск причины и откат | минуты на возврат к предыдущей версии | Регрессионный набор проверок |
| Классы отказов в эксплуатации | повторные вызовы, переполнения, неограниченный доступ к средствам | закрываются до выпуска | Правила дополняются после каждой находки |
Набор проверок накапливается: каждая закрытая находка становится правилом и в следующей версии ловится автоматически. Итог — доля найденных дефектов растёт не за счёт времени инженеров, а за счёт прогонов, которые идут без участия человека.
Форматы проверки: разовый разбор или постоянный контроль
Проверка смарт-контракта — это не одна процедура, а набор режимов работы системы, которые отличаются глубиной, частотой и областью анализа: только опубликованный код или весь его жизненный цикл вместе с обновлениями.
Разовый режим отвечает на вопрос «можно ли выпускать», остальные — «что изменилось с прошлого раза и что это ломает». Ниже — как это выглядит на практике и какие ограничения режима нужно учитывать заранее.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Разовая проверка перед выпуском | Логика зафиксирована, обновления не планируются, нужен допуск к запуску | Анализируется только текущее состояние; правки после отчёта остаются вне контроля |
| Постоянный анализ изменений | Контракт развивается, есть обновляемые модули и внешние зависимости | Нужен доступ к репозиторию и истории выпусков; сигналы приходят только по изменённым участкам |
| Точечный разбор спорных участков с экспертом | Сложная экономика протокола, механизмы ликвидации, оракулы, расчёты комиссий | Выше трудозатраты: разбор требует погружения в контекст всей системы, а не в один модуль |
| Периодические ревизии | Код стабилен, но меняется окружение: зависимости, стандарты, внешние контракты | Между ревизиями остаётся окно, когда проблема уже появилась, а находка ещё не сформирована |
Режимы не исключают друг друга: разовая проверка на входе, постоянный анализ изменений на время активной разработки, ревизии по расписанию. Общее ограничение у них одно — система анализирует то, к чему есть доступ, поэтому без репозитория, артефактов сборки и описания экономики протокола часть путей остаётся вне разбора.
Как проходит аудит смарт-контрактов: этапы работы
Аудит смарт-контрактов — это не разовая проверка одного файла, а настройка анализа под конкретную кодовую базу. Этапы внедрения строим так, чтобы проверки встроились в текущий процесс разработки. Опасные места у разных проектов выглядят по-разному: где-то критично право на выпуск токенов, где-то — внешние вызовы без проверки результата. Поэтому сначала изучаем код, затем настраиваем правила — иначе получим поток ложных срабатываний, который команда перестанет читать.
- Разбор репозитория и логики. Изучаем структуру контрактов, зависимости, точки входа, роли и права доступа. Отмечаем, какие части обновляются, а какие заморожены — от этого зависит приоритет проверок.
- Модель поведения. Описываем инварианты: что не должно нарушаться ни при каком сценарии вызова. Эта модель становится основой правил.
- Настройка правил. Включаем проверки на переполнения, повторные вызовы, доступ к административным функциям, необработанные внешние вызовы. Пороги и исключения подгоняем под проект, а не под типовой шаблон.
- Прогон на исторических изменениях. Проверяем настройки на прошлых версиях и правках: сколько находок подтвердилось, сколько оказалось шумом. По результату правим пороги.
- Проверка результатов инженером. Каждое срабатывание разбирает человек: подтверждает или отклоняет с указанием причины. Так формируется база решений для похожих случаев.
- Передача регламентов. Отдаём описание правил, разбор спорных случаев и порядок действий при новых находках, обучаем команду на её же примерах.
Артефакты и регламенты, которые остаются у вашей команды
Разбор отдельного контракта — не конечный результат. Мы передаём вашей команде опорный набор правил проверки, схему потоков данных с отмеченными границами доверия и регламенты, по которым проверка воспроизводится без нас: новый контракт прогоняется теми же правилами, а находки получают тот же уровень критичности и порядок обработки.
Что именно остаётся в репозитории рядом с кодом и во внутренней документации:
- Набор правил проверки: сигнатуры типовых дефектов — повторный вход в функцию, небезопасные внешние вызовы, переполнение разрядности, неограниченные права владельца. Правила версионируются вместе с кодом и уточняются по мере накопления разборов.
- Схема потоков данных и границ доверия: кто вызывает контракт, какие внешние источники значений считаются недоверенными, где проходит граница между вашим кодом и сторонними вызовами.
- Политики доступа: изменение правил, закрытие находки и подписание выпуска — разные роли. Журнал действий ведётся и не переписывается задним числом.
- Отчёт о проверке по каждому разбору: адрес контракта, отпечаток исходного кода, перечень находок с уровнем критичности, привязкой к строке, обоснованием и статусом — исправлено, принято как риск, отклонено.
- Регламент реагирования: что делать, если критичная находка всплывает между проверкой и выпуском — кто останавливает выпуск, кто решает вопрос доработки или отката и в какой срок.
- Инструкции для команды: как запускать проверку при каждом изменении кода, как добавить собственное правило и как оспорить ложное срабатывание с фиксацией решения.
- Матрица покрытия: какие контракты и какие ветки логики уже проверены, а какие остались вне проверки — это видно до выпуска, а не после инцидента.
Кейс: как выросла доля найденных дефектов до выпуска
Заказчик выпускал протокол на смарт-контрактах и обновлял его раз в две недели. Каждый релиз проходил ручной разбор: два инженера построчно читали изменения и тратили на проверку около 30 часов, а на новые модули уходило заметно больше.
До внедрения разбор давал предсказуемую, но ограниченную выборку. До выпуска удавалось поймать 58% дефектов, остальное всплывало на тестовой сети или уже после публикации контрактов — и тогда исправление требовало нового релиза и миграции состояния. Доля находок упиралась во внимание: к концу проверки инженер хуже замечает однотипные шаблоны — неверные проверки доступа, переполнения при вычислениях.
Что изменили
Мы собрали модель на разметке прошлых аудитов и поставили её первым слоем: статический анализатор Slither и модель размечают кандидатов и ранжируют их по вероятности реального дефекта, а инженер подтверждает или снимает каждую находку. Ложные срабатывания отсекаются до того, как попадут в отчёт, поэтому время разбора не растёт.
На релизах после внедрения доля дефектов, найденных до выпуска, выросла с 58% до 91%, а время от находки до исправления сократилось с двух суток до нескольких часов — правка уходит в тот же цикл, без отдельного релиза. Проверка одного релиза занимает около 12 часов вместо 30, при этом покрытие неочевидных веток логики выше, чем при чистом ручном разборе.
Чем отличается статический анализ от проверки логики протокола
Статический анализ работает с кодом, не исполняя его: строит дерево вызовов и граф зависимостей, сверяет результат с каталогом типовых слабостей вроде SWC Registry. Так закрываются переполнения, незащищённые внешние вызовы, отсутствие проверки прав, неинициализированные переменные. Проверка полная, повторяемая и не зависит от фантазии инженера — но видит только то, что выражено в синтаксисе.
Проверка логики начинается раньше — с модели поведения протокола. Мы фиксируем, что система обещает участникам, какие инварианты обязаны сохраняться при любом порядке транзакций, и уже потом ищем места, где код эти инварианты нарушает. «Компилируется и проходит тесты» и «ведёт себя корректно» — разные утверждения, и между ними лежит вся зона экономических дефектов.
Второй слой — сценарии злоупотребления: разбор последовательностей вызовов, где каждый шаг легален, а вместе они дают атакующему выгоду. Манипуляция ценой оракула в пределах одной транзакции, повторный вход через внешний колбэк, заём без залога под голосование, опережение чужой ликвидации. Синтаксис при этом безупречен, и формальные проверки по такому коду молчат.
Поэтому слои не конкурируют. Статика быстро отсеивает массовые классы ошибок по всему массиву контрактов, модель поведения и разбор сценариев ловят композиционные дефекты, невидимые в отдельной функции. В отчёте это два разных перечня находок с разной ценой исправления — и заказчик видит, что именно закрыто проверкой, а что осталось явным допущением.
Ограничения метода и типовые сомнения инженеров
Система не заменяет аудит целиком, и мы прямо называем границы применимости. Типовые классы — повторный вызов до списания баланса, переполнение, незащищённый доступ к хранилищу, ошибки в порядке внешних вызовов — находятся устойчиво. А вот экономическую логику: устойчивость оракула, сценарии ликвидации, манипуляции ценой внутри одной транзакции — модель не выводит, здесь нужен контекст задачи и модель угроз.
Ложные срабатывания отсекаются в два шага. Сначала проверяем достижимость: если ветка не исполняется при заданных условиях, находка помечается как незначимая. Затем инженер подтверждает или отклоняет сигнал, и в отчёт попадают только подтверждённые случаи — доля шума на первом экране падает в разы, а разбор не превращается в перелистывание сотни однотипных предупреждений.
Ручная верификация обязательна там, где вывод зависит от договорённостей, а не от кода: права администратора, порядок обновления контракта, распределение комиссий, расчёт долей держателей.
Что система гарантированно не найдёт?
Дефекты, вытекающие из внешних договорённостей: ошибки в токеномике, неверное ценообразование, конфликты ролей в управлении, поведение сторонних контрактов и оракулов. Это закрывается разбором сценариев вместе с командой заказчика.
Как вы проверяете качество модели?
Прогоняем её на исторических инцидентах с известным исходом и считаем, какую долю подтверждённых дефектов она находит и сколько даёт неподтверждённых срабатываний. Дополнительно сверяем с независимым статическим анализом, расхождения разбираем вручную. Целевые метрики фиксируем до старта работ — результат остаётся измеримым, а не оценочным.
Обсудим задачу: что нужно для оценки и плана работ
Оценка проекта по аудиту смарт-контрактов зависит не от количества строк кода, а от того, насколько полно описаны границы системы. Если присылают только файлы контрактов, без процесса выпуска и истории правок, приходится закладывать запас на неизвестное: сроки растягиваются, а часть путей остаётся вне проверки. Чтобы посчитать объём работ точно, нужны входные данные.
- Репозиторий или его копия: доступ на чтение к коду, тестам, скриптам развёртывания и настройкам сборки.
- Адреса уже развёрнутых контрактов и сеть, в которой они работают, включая случаи, когда логика разнесена по нескольким контрактам.
- Ответы по процессу выпуска: кто publishes изменения, проходит ли код ревью, кто держит ключи администратора и как передаются права.
- Схема ролей и прав доступа: какие операции доступны владельцу, какие — управляющему контракту, какие открыты всем.
- Известные проблемные места и история: что уже находили прошлые проверки, какие правки вносили после запуска и почему.
- Что считать критичным именно для вас: вывод средств, изменение комиссий, внешние вызовы, пауза и остановка системы.
Порядок старта одинаков почти всегда. Сначала обсуждаем задачу и границы проверки — разговор занимает меньше часа и сразу показывает, где оценка будет отличаться от ожиданий. Затем открываете доступ к репозиторию или копии, отвечаете на вопросы по процессу выпуска. После этого мы возвращаемся с оценкой проекта и планом работ: этапы, что проверяем на каждом, какие артефакты передаём и в каком виде отчёт удобнее читать вашей команде. Дальше — согласование сроков и старт.
Если часть данных закрыта, это не блокирует начало: помечаем такие участки в плане как непроверенные и говорим об этом прямо, а не заменяем молчание общими формулировками.
