AI-разбор уязвимостей смарт-контрактов и слепые зоны аудита
Уязвимости смарт-контрактов редко выглядят как явная ошибка в одной функции. Чаще это корректный код, который ведёт себя неверно в конкретной последовательности вызовов: обход проверки прав доступа через функцию-посредник, повторный вызов, возвращающий исполнение в середину операции до записи в хранилище, или ошибка логики контракта в редкой ветке расчёта. Статическая проверка такое пропускает — она смотрит на функцию, а не на состояние контракта между транзакциями.
Поэтому ai анализ смарт-контрактов строят как слой поверх статики: модель проходит по графу вызовов целиком, сопоставляет точки входа с правами, которые они реально дают, и отмечает, где внешний вызов идёт раньше изменения состояния. На выходе — не абстрактное предупреждение, а сценарий эксплуатации: какая последовательность транзакций, от какого адреса и что именно теряет протокол.
Solidity добавляет свой пласт: наследование, контракты-посредники и делегирование скрывают реальные права за цепочкой вызовов, а данные из внешних источников меняются между проверкой и использованием. Ошибка логики контракта чаще всего проявляется именно здесь — условие верно в момент чтения и перестаёт быть верным к моменту записи.
Находки мы разделяем по классам — обход прав, повторный вызов, манипуляция внешними данными, ошибка логики — и для каждого описываем, воспроизводится ли он на тестовой сети и как закрывается правкой. Дальше смотрим, что именно проверяется автоматически, а что остаётся за инженером.
Что даёт непрерывная проверка кода перед каждым релизом
Непрерывная проверка кода встроена в конвейер сборки и запускается на каждом значимом изменении, а не в конце цикла. Разбор идёт по двум линиям: статический анализ дерева вызовов на актуальной ветке Slither и прогон сценариев на инварианты в изолированной сети. Находка приходит с трассировкой вызова и минимальным воспроизведением — её подтверждают или опровергают, а не спорят о формулировке предупреждения.
Что это меняет по пунктам:
- Снятый класс отказов. Повторный вход, ошибки прав доступа и переполнения отсекаются до сборки релизной ветки — выкатить их в основную сеть уже нельзя.
- Разбор перед релизом. Отчёт по изменениям приходит к ревью, а не через неделю после выкладки, поэтому правки попадают в тот же цикл.
- Управляемый поток находок. Критичное поднимается наверх, дубликаты схлопываются, шум отсекается правилами — вместо лавины перед запуском команда получает очередь с приоритетами.
- Срок выпуска релиза. Проверка идёт параллельно разработке, и финальный разбор перестаёт быть отдельным этапом ожидания.
- Меньше ручных прогонов. Автоматика закрывает типовые проверки, ручной разбор остаётся на логику экономики протокола и права управления.
Политика проверок живёт в репозитории: набор правил, порог блокировки релиза и история решений по каждой находке. Доля изменений, проверенных до релиза, и число находок на релиз видны в отчёте — качество перестаёт обсуждаться на словах.
Режимы проверки кода: разовый аудит и непрерывный контур
Ни один режим проверки не даёт полной картины сам по себе — они закрывают разные классы дефектов. Разовый аудит контракта ловит логические ошибки, которые не описываются шаблоном, но к следующему коммиту его выводы устаревают. Непрерывный контур проверки срабатывает на каждое изменение, зато видит только то, что удалось формализовать правилом или сценарием. Выбор зависит от того, где контракт в жизненном цикле и какова цена ошибки.
| Подход | Когда подходит | Ограничения |
|---|---|---|
| Разовый ручной аудит | перед заморозкой логики и выводом в сеть, когда права доступа и выплаты нестандартны | результат живёт до первого изменения, проверку нужно проводить заново |
| Статический анализ | постоянная проверка на каждом коммите: переполнения, повторные вызовы, небезопасные внешние обращения | часть срабатываний ложная, порядок вызовов между контрактами не виден |
| Прогон сценариев | ветвления экономики: ликвидации, аукционы, граничные суммы, редкие последовательности вызовов | покрытие зависит от заложенных путей — непроверенный путь остаётся дырой |
| Формальное доказательство свойств | инварианты ядра: сходимость балансов, недоступность вывода после блокировки | требует явной формулировки свойств и не покрывает внешние зависимости |
Как режимы сочетаются
На каждом коммите идёт статический анализ, сценарии крутятся в ночном прогоне, для ядра доказываются свойства, а ручной аудит подключают перед крупным релизом или сменой модели доступа. Дешёвые проверки отсекают массовые дефекты, дорогие — достаются участкам, где ошибка стоит дороже всего.
Как проходит внедрение: шаги от аудита до передачи
Внедрение идёт итерациями по одной-двум неделям: сначала фиксируем текущее состояние контрактов, затем собираем контур проверки и только потом встраиваем его в процесс выпуска. Порядок именно такой — если сразу настраивать правила без инвентаризации, анализатор начинает шуметь на легитимных паттернах проекта, и команда перестаёт ему доверять.
- Аудит кода контрактов. Собираем перечень контрактов, их версии, связи между ними, права ролей и внешние вызовы. На выходе — карта того, что вообще нужно проверять.
- Схема контура проверки. Определяем, где запускается анализ: на каждом изменении, перед слиянием ветки или по расписанию для уже развёрнутых контрактов.
- Настройка правил. Включаем проверки под предметную логику: управление доступом, работа с внешними вызовами, порядок изменения состояния. Нерелевантные правила отключаем, чтобы не создавать шум.
- Тестовые сценарии. Прогоняем контур на исторических релизах и на намеренно внесённых ошибках — видим, что он ловит, а что пропускает.
- Разбор ложных срабатываний. Каждое спорное срабатывание размечаем с вашей командой: подтверждённая проблема, допустимый паттерн или пробел в правиле. По итогам правила корректируются.
- Встраивание в процесс разработки. Проверка становится обязательным шагом перед выпуском, с понятным статусом и порогом, при котором релиз блокируется.
- Передача документации и обучение. Отдаём описание контура, набор правил с обоснованием, инструкцию по разбору находок и проводим обучение команды.
Готовность фиксируем по измеримым критериям: доля ложных срабатываний на вашем коде, время проверки одного изменения и число находок, подтверждённых как реальные. Если правила дают шум выше согласованного порога, этап не закрывается.
Артефакты передачи: правила, схемы и регламент прогонов
Передача контура — не итоговый отчёт, а набор артефактов, которые остаются в вашем репозитории и работают без нас. Если команда не может сама запустить проверку, разобрать находку и объяснить происхождение результата, работа не закрыта.
- Карта ролей и прав доступа: кто запускает прогоны, кто подтверждает находку, кто правит правила разбора, кто видит только отчёты. Права выдаются группами — персональных бессрочных доступов не остаётся.
- Схема архитектуры: компоненты контура, границы доверия и точки, где исходники контрактов покидают ваш периметр и как результат возвращается обратно.
- Конфигурации разбора: файлы правил, пороги срабатывания и список подавленных предупреждений с обоснованием — всё версионируется вместе с кодом.
- Регламент прогонов: что запускает проверку (изменение кода, подготовка релиза, регулярный прогон), глубина, ожидаемое время и поведение контура при сбое.
- Набор проверочных сценариев: контракты с известными дефектами, по которым видно, что после доработок контур не начал пропускать то, что ловил раньше.
- Порядок разбора находок: уровни критичности, срок реакции на каждый, кто принимает решение и как фиксируется вердикт «берём в работу» или «ложное срабатывание».
- Документация по контуру: как обновлять правила, что делать при смене инструментов сборки и куда смотреть в журналах при расхождении результата.
Кейс: разбор кода перед запуском вместо аудита по факту
Заказчик — команда, выпускающая протокол со смарт-контрактами, где ошибка в логике переводов стоит потери средств без возможности отката. До внедрения проверки шли по факту: аудиторы подключались к замороженному коду за несколько дней до релиза, а между аудитами разработчики вливали изменения без автоматической проверки. Отчёты приходили пачками предупреждений, значительная часть которых оказывалась ложной, и через пару недель их перестали читать.
Мы собрали контур, который работает на каждом изменении. Ядро — анализатор Slither, дополненный моделью, обученной на размеченных находках конкретно этого проекта: она ранжирует предупреждения по вероятности реальной эксплуатации и отсекает шаблонный шум. Вердикт по коммиту приходит в запрос на слияние до ревью, а не после слияния.
Метрики до и после
Доля уязвимостей, снятых до релиза, выросла с примерно половины до 92% — остальное попадает в план правок, а не в инциденты. Доля ложных срабатываний упала с 60% до 12%, поэтому на отчёт смотрят, а не игнорируют его. Время от коммита до вердикта по изменениям сократилось с получаса ручного разбора до 6-8 минут автоматического прогона.
На сроке выпуска это дало обратный эффект: релизный цикл сжался с трёх недель до девяти дней, потому что правки безопасности перестали собираться в отдельную фазу в конце. Ценнее всего то, что находка приходит автору изменения, пока контекст ещё в голове.
Чем AI-разбор отличается от правил и сигнатурного поиска?
Сигнатурный поиск и правила работают на разборе кода в дерево и поиске известных шаблонов: вызов внешнего адреса до изменения состояния, необработанный результат вызова, проверка прав по источнику транзакции. Там, где класс уязвимости укладывается в шаблон, подход даёт точный и объяснимый результат — находку можно показать на конкретной строке и конкретном пути исполнения.
Предел начинается там, где шаблон перестаёт совпадать с реальностью. Прокси-контракты, обёртки над сторонними библиотеками, составные цепочки вызовов через несколько контрактов — правила рассыпаются на десятки частных случаев. Формальные методы закрывают часть пробела: они доказывают инварианты, но требуют ручного описания спецификаций и плохо переносятся на код, который меняется каждую неделю.
AI-разбор кода снимает это ограничение иначе: модель обучается на разметке находок — подтверждённых и опровергнутых. Она учится отличать срабатывание, которое инженер закрыл как ложное, от реального пути к использованию уязвимости, и ранжирует вывод по вероятности. Быстрый первичный проход по известным классам даёт Slither — модель дорабатывает то, что в шаблон не уложилось.
На практике связка выглядит так: правила дают дешёвое покрытие известных классов, формальные методы — доказательства на критичных участках, модель снимает основную нагрузку по ложным срабатываниям. Доля находок, которые уходят в отчёт без ручной перепроверки, растёт — именно она определяет, сколько времени занимает разбор перед выпуском контракта.
Вопросы, которые задают инженеры перед стартом
Перед стартом инженеры задают одни и те же вопросы: где граница между автоматическим разбором и ручным аудитом, сколько шума даёт модель и как её вывод попадёт в конвейер сборки. Модель проходит контракт целиком, включая ветки, до которых аудитор за ограниченное время не доходит; человеку остаются экономические сценарии и проверка критичных находок.
Сколько будет ложных срабатываний?
На первом прогоне порог смещён к полноте: лучше лишняя находка, чем пропуск. Дальше фильтр настраивается на ваших контрактах, и каждое срабатывание идёт с фрагментом кода и уровнем уверенности.
Контракт уже развёрнут — есть ли смысл в проверке?
Разбор идёт по опубликованному коду и байткоду: права владельца, доступные функции, приём внешних вызовов. Так видно, чем рискует именно развёрнутая версия.
Как проверять обновляемые контракты?
Разбор не разовый: новая реализация проходит те же проверки до публикации, между версиями сравниваются логика и хранилище. Иначе правка тихо открывает то, что было закрыто.
Куда передавать приватный код?
В публичные сервисы его выкладывать не нужно: разбор в изолированном контуре, доступ по ролям, результаты остаются у вас. Порядок работы и удаление копий фиксируем письменно.
Как встроить проверку в конвейер сборки?
Отдельным шагом перед публикацией: запуск на изменения, машиночитаемый отчёт, блокировка выпуска при находках выше заданного порога.
Обсудим задачу и вернёмся с оценкой и планом
Чтобы оценка проекта опиралась на факты, а не на догадки, для разговора достаточно нескольких вводных. Присылать весь код заранее не нужно — важно понять, как проверка встроена в ваш процесс разработки и ревью.
- Перечень сетей и типов контрактов: токены, мосты, протоколы кредитования — что именно нужно проверять.
- Репозиторий или архив с примерами — хотя бы несколько контрактов в текущем состоянии.
- Классы уязвимостей, критичные именно вам: повторное вхождение, ошибки контроля доступа, переполнения.
- Как находки доходят до разработчиков: отчёт, задача в трекере, комментарий к изменению кода.
- Ограничения по доступам: где живёт код, что можно подключить к сборочному контуру.
- Кто утверждает правила и разбирает ложные срабатывания.
- Накопленные примеры находок и пропусков — по ним настраиваем чувствительность.
В ответ вы получаете схему контура: где стоит анализ уязвимостей, как он связан со сборкой и проверкой изменений, где хранятся результаты и как они попадают в задачи. Дальше — план работ по этапам с точками контроля и дата первого пробного прогона на ваших контрактах. По итогам прогона видно, какую долю находок подтверждают инженеры и сколько уходит в шум, — на этих числах и строится финальная оценка проекта.
