Аудит смарт-контрактов: что проверяют, сколько стоит и как принять
отчёт

Аудит смарт-контрактов — это независимая проверка кода контракта до того, как в нём окажутся деньги пользователей. Короткий ответ: работа состоит из пяти решений — что именно попадает в объём проверки (контракты, библиотеки, прокси, скрипты деплоя), какой коммит считается финальным, кто и по какой методике смотрит код, как классифицируются найденные проблемы и что заказчик получает на выходе кроме текста отчёта. Ниже — что ищут в коде по OWASP Smart Contract Top 10 2026, как устроены три слоя проверки, из чего складывается стоимость в 2026 году, почему проверенный код всё равно теряет деньги и по какому чек-листу принимать отчёт.

Аудит смарт-контрактов: короткий ответ

Минимальный результат, за который имеет смысл платить, выглядит так:

• Объём зафиксирован: перечислены адреса контрактов, сеть, версия компилятора, настройки оптимизатора и хеш коммита, по которому шла проверка.
• Найденные проблемы пронумерованы и разделены по критичности, у критичных есть сценарий эксплуатации, а не только описание.
• Каждая проблема либо закрыта исправлением, либо явно принята заказчиком с записанным риском.
• После исправлений есть повторная проверка — mitigation review, а не «мы поправили, верьте».
• Отчёт можно показать партнёру, бирже или инвестору: без внутренних заметок, с понятной методикой и датой.

Если в предложении нет ни объёма, ни повторной проверки, речь идёт не об аудите, а о беглом просмотре. Общая картина того, как устроен продукт и где в нём вообще возникают деньги, разобрана в материале про разработку web3-проектов; здесь — только проверка кода.

Что аудит проверяет, а что остаётся за его границами

За границами аудита по умолчанию остаются:

• Ключи и мультисиг: как хранятся подписи, кто входит в кворум, что будет при компрометации одного участника.
• Серверная часть: бэкенд, API, боты и очереди, которые кормят контракт данными.
• Инфраструктура и процессы: доступы, сборка и доставка кода, мониторинг, реакция на инцидент.
• Юридический контур: статус токена, соответствие требованиям площадок, налоги.

Почему аудит стал обязательным: цифры 2025–2026

Отчёт Hacken Yearly Security Report 2025 фиксирует более 4 млрд долларов потерь в web3 за 2025 год. Из них 512 млн пришлись на эксплойты в DeFi-протоколах, а свыше 2,1 млрд — на операционные сбои и ошибки в контроле доступа. Вывод, важный для заказчика аудита: самая дорогая категория проблем находится не в арифметике контракта, а в том, кто и на каких условиях может вызывать функции.

Данные TRM Labs за первое полугодие 2026 года показывают другую сторону той же картины. Зафиксировано 207 атак — рекорд для полугодия, и 125 из них пришлись на эксплойты смарт-контрактов. При этом общий ущерб составил 972 млн долларов: компрометации инфраструктуры и ключей дали лишь около 15% инцидентов, но примерно 76% украденной суммы. Типичный инцидент подешевел до 219 тыс. долларов — атаки стали массовыми и мелкими.

OWASP Smart Contract Top 10 2026: что ищут в коде

Список OWASP — удобный способ сверить объём: если аудитор обещает проверить «всё», полезно уточнить, покрыты ли десять классов ниже. В редакции 2026 года порядок изменился: на первом месте стоят не арифметические ошибки, а права доступа и экономическая логика.

• SC01 — контроль доступа: кто может вызывать привилегированные функции, кому открыты админские и апгрейд-пути.
• SC02 — ошибки бизнес-логики: экономика лендинга, обменников, наград и голосования, где проверки формально верны, а правила нарушаются.
• SC03 — манипуляция ценовыми оракулами: слабый источник цены позволяет занизить обеспечение или исказить курс.
• SC04 — атаки через flash-кредиты: мгновенный необеспеченный заём превращает мелкую ошибку в крупный вывод средств.
• SC05 — отсутствие проверки входных данных: параметры пользователя, админа или кросс-чейн-сообщения доходят до ядра без валидации.
• SC06 — непроверенные внешние вызовы: результат обращения к чужому контракту не проверяется, состояние остаётся несогласованным.
• SC07 — арифметические ошибки: округление, масштабирование, расчёт долей и процентов, на которых можно повторно зарабатывать.
• SC08 — reentrancy: повторный вход в функцию до того, как обновлено состояние контракта.
• SC09 — переполнение и недополнение: арифметика без защиты даёт обёрнутые значения и ломает инварианты.
• SC10 — прокси и обновляемость: неверная инициализация, слабое управление апгрейдами, перехват реализации.

За пределами десятки остаются вещи, которые регулярно всплывают в отчётах: фронтраннинг и MEV, включая кросс-чейн-вариант с утечкой события исходной сети; атаки на permit и nonce; отказ в обслуживании через неограниченные циклы и рост состояния; слабое управление в протоколах голосования. Спросить про них стоит отдельно — в объём по умолчанию они попадают не всегда.

Три слоя проверки: автоанализ, ручное ревью, динамические тесты

Работающий аудит почти всегда совмещает три слоя, и в смете должны быть видны все три. Автоматический анализ ищет известные паттерны по всему коду и стоит дёшево, но не понимает замысла. Ручное ревью проверяет экономику и права — то, где чаще всего теряют деньги. Динамические тесты ломают инварианты на реальных сценариях. Как это выглядит в услуге разработки и аудита web3-решений, и что заказчик может проверить сам.

• Автоматический слой: статический анализ и поиск известных уязвимостей по всему репозиторию, включая зависимости.
• Ручной слой: чтение логики по потокам средств, разбор ролей и админских функций, сверка кода со спецификацией.
• Динамический слой: фаззинг, инвариантные тесты и симуляция эксплойтов на форке основной сети.

Из инструментов в отчётах 2026 года обычно фигурируют статический анализатор Slither, символьный Mythril, фаззеры Echidna и Medusa, инвариантные тесты в Foundry с форком сети и, для критичных протоколов, формальная верификация вроде Certora. Сам список инструментов ничего не доказывает: ценность в том, какие инварианты сформулированы и что нашлось при их проверке. Полезная деталь — покрытие тестами: если ключевые потоки средств не покрыты, фаззинг проверяет пустоту.

Как проходит аудит: этапы и сроки

1. Заявка и объём: какие контракты, какая сеть, что считается финальной версией, есть ли зависимости и прокси.
2. Подготовка: код собирается, тесты проходят, архитектура и роли описаны. Аудит по нестабильной ветке — потеря денег.
3. Автоматический проход: статический анализ и первичная инвентаризация внешних вызовов и прав.
4. Ручное ревью: чтение логики по потокам средств, проверка инвариантов, отдельный разбор админских функций.
5. Динамика: фаззинг, инвариантные тесты, симуляция эксплойтов на форке.
6. Отчёт и обсуждение: проблемы с критичностью, сценариями и рекомендациями, созвон с командой.
7. Повторная проверка исправлений и финальный отчёт, который можно публиковать.

Сроки привязаны к объёму и качеству подготовки, а не к обещаниям. Простой токен на несколько сотен строк закрывают за считанные дни, стандартный DeFi-протокол — за недели, мост или систему с кросс-чейн-логикой — за месяцы. Срочность стоит денег: ускорение обычно добавляет 25–50% к смете, а выпуск «за неделю» может её удвоить.

Что должно быть в отчёте об аудите

Отчёт — главный артефакт, за который платят. Хороший документ читается человеком, который не видел переписки с аудитором, и позволяет воспроизвести проверку спустя месяцы.

• Объём: адреса контрактов, сеть, версия компилятора, настройки оптимизатора, хеш проверенного коммита.
• Методика: какие слои применялись, какие инструменты и какие инварианты проверялись.
• Классификация критичности с определениями: что считается Critical, High, Medium, Low и информационным замечанием.
• Для High и Critical — сценарий эксплуатации или PoC, а не только описание последствий.
• Статусы исправлений по каждой проблеме: fixed, acknowledged, wontfix — с датой проверки исправления.
• Финальный отчёт с хешем документа и датой выпуска: именно его показывают партнёрам и площадкам.
• Явное разрешение публиковать отчёт либо описание того, что раскрывать нельзя.

Отдельно проверьте две вещи, которые чаще всего отсутствуют. Первая — хеш финального коммита: без него невозможно доказать, что проверен именно развёрнутый код. Вторая — соответствие исходников развёрнутому байткоду: верификация в обозревателе сети (например, Etherscan) должна сходиться с адресом контракта, иначе отчёт относится к другому коду. Если продукт кроме контрактов включает сайт, кабинет и интеграции, полезно закрыть и их — по той же логике, что и аудит digital-проекта целиком.

Сколько стоит аудит смарт-контрактов в 2026

Цены различаются на два порядка, и это нормально: сравнивать нужно не прайсы, а объём. Ориентиры ниже — рыночные диапазоны по открытым обзорам рынка начала 2026 года (Sherlock, Zealynx, сравнения провайдеров), а не прайс APEX IOINC: точная смета зависит от сложности кода, сети и сроков.

• Простой токен или NFT-контракт на несколько сотен строк: примерно 5–15 тыс. долларов, работа занимает дни.
• Стейкинг, вестинг, голосование, маркетплейс NFT: 5–20 тыс. долларов за 1–3 недели.
• Стандартный DeFi-протокол (обменник, лендинг, хранилища): 25–100 тыс. долларов за 3–6 недель.
• Мост, L1, ZK-rollup, мультичейн-система: 150–500 тыс. долларов за 2–6 месяцев.
• Формальная верификация инвариантов: отдельная надбавка около 20–50 тыс. долларов к базовой смете.

Что двигает цену внутри диапазона: объём и плотность логики, число внешних интеграций и оракулов, наличие прокси и механик апгрейда, нестандартная сеть или язык (Rust и Move дороже Solidity из-за меньшего пула специалистов), срочность и репутация исполнителя. У крупных фирм почасовая ставка — порядка 400–600 долларов за час аудитора, у топовых команд встречается фиксированная цена около 25 тыс. долларов за инженера-неделю. Конкурсные аудиты на платформах дешевле по порогу входа, но призовой пул начинается примерно от 20 тыс. долларов.

В смету нужно закладывать не один проход, а два: повторная проверка исправлений обычно стоит ещё 5–20 тыс. долларов. Для протокола с высоким объёмом средств разумный бюджет запуска — 60–120 тыс. долларов на аудит и повторную проверку. Если объём ещё не определён, дешевле начать с оценки кода и границ — такая работа ближе к заказной разработке и инженерному аудиту архитектуры, чем к фиксированному прайсу.

Почему аудит не гарантирует безопасность

Самая частая ошибка ожиданий — считать отчёт гарантией. Аудит остаётся выборкой и суждением ограниченной команды за ограниченное время. Рынок 2025–2026 годов показывает, что значительная часть потерь вообще не связана с ошибкой в коде: по данным Hacken, свыше 2,1 млрд долларов из 4 млрд в 2025 году ушло через операционные сбои и слабый контроль доступа, а по данным TRM Labs за первое полугодие 2026 года инфраструктурные компрометации дали около 76% украденной суммы.

Проверенный код теряет деньги, когда:

• ключи или мультисиг скомпрометированы, а кворум собран из адресов одного человека или одной инфраструктуры;
• апгрейд-механика позволяет подменить реализацию без таймлока и без второго подтверждения;
• код после аудита изменился, а развёрнут не проверенный коммит;
• цена приходит из слабого оракула, а внешний протокол-партнёр ведёт себя иначе, чем предполагалось.

Отсюда практическое правило: аудит проверяет конкретный коммит, поэтому любая правка после отчёта требует либо повторной проверки, либо явного решения принять риск. И второе: контракты — не весь продукт. Как устроены остальные слои и где ещё бывают дыры, разобрано в статье про аудит сайта и в общей логике проверки digital-проекта.

Что делать после аудита

• Закрыть критичные и высокие проблемы и получить повторную проверку исправлений.
• Опубликовать отчёт и хеш финального коммита — это и аргумент для партнёров, и защита от подмены версии.
• Запустить программу баг-баунти: аудит ищет то, что успели посмотреть, баг-баунти — то, что не успели.
• Настроить мониторинг: аномальные выводы средств, изменение прав, неожиданные апгрейды, движения в казне.
• Описать процедуру апгрейда: таймлок, второе подтверждение, проверка параметров до выполнения.

Мониторинг и процедуры — это уже операционный контур: роли, доступы, дежурство, реакция на инцидент. Строить его сразу дешевле, чем разбираться после первых потерь.

Аудит до запуска и после: в чём разница

Предзапусковый аудит проверяет замысел: инварианты, экономику, права и граничные сценарии до того, как в контракте появились деньги. Здесь правки дешёвые, а найденная ошибка логики не стоит ничего, кроме времени.

Проверка после запуска работает с другим материалом: реальными потоками средств, интеграциями, поведением пользователей и обновлениями. Здесь чаще находят не ошибки компиляции, а расхождения между задуманным и фактическим использованием: открытые админские функции, неожиданные пути вывода, параметры, которые никто не ограничил. Форматы тоже различаются — от повторного ревью после апгрейда до постоянного сопровождения безопасности и разбора инцидентов.

Как выбрать аудитора: восемь вопросов

1. Кто именно будет смотреть код и сколько инженеров-недель заложено в смету?
2. Что входит в объём: контракты, библиотеки, скрипты деплоя, прокси, внешние интеграции?
3. Какие классы из OWASP Smart Contract Top 10 вы покрываете, а какие считаете вне объёма?
4. Делаете ли динамические тесты и формальную верификацию, и что именно проверяют инварианты?
5. Что входит в отчёт: сценарии эксплуатации, PoC, статусы исправлений, хеш коммита?
6. Сколько стоит повторная проверка исправлений и входит ли она в смету?
7. Можно ли опубликовать отчёт и как вы относитесь к публикации хеша финального коммита?
8. Что происходит после сдачи: сопровождение, мониторинг, консультации по исправлениям?

Как принять работу: чек-лист

1. В отчёте указан адрес контракта, сеть, версия компилятора, настройки оптимизатора и хеш коммита.
2. Объём совпадает с тем, что реально развёрнуто: проверьте верификацию кода в обозревателе сети.
3. Каждая проблема имеет критичность, описание и рекомендацию; для High и Critical — сценарий эксплуатации.
4. Статусы исправлений проставлены и подтверждены повторной проверкой.
5. Финальный отчёт датирован и совпадает по хешу с тем, что вы получили.
6. Отдельно перечислено, что в объём не входило.
7. Есть короткая выжимка для партнёров и биржи — без внутренних деталей.
8. Команда объясняет находки своими словами на созвоне, а не только ссылкой на документ.

Типичные ошибки заказчиков

• Заказывать аудит до того, как код стабилен: каждая правка после отчёта обесценивает проверку.
• Проверять только токен, оставляя без внимания прокси, скрипты деплоя и админские функции.
• Экономить на повторной проверке исправлений и считать, что «мы всё поправили» равно «проверено».
• Не хранить хеш проверенного коммита — потом невозможно доказать, что развёрнут именно он.
• Путать аудит с пентестом инфраструктуры и ждать от него защиты от кражи ключей.
• Смотреть только на цену: разница в 20 тыс. долларов на фоне потери казны — не та экономия. Разработку контрактов без тестов и ревью стоит обсудить отдельно — см. разработку программного обеспечения.

Когда аудит не нужен

Честная граница: если контракт учебный, тестовый или не держит чужих денег, полноценный аудит избыточен. Разумный минимум — статический анализ, тесты и ясное понимание, что контракт делает с деньгами.

• Тестовая сеть или прототип без средств пользователей: хватит автотестов и линтеров.
• Внутренний контракт без внешних вызовов и админских функций: достаточно ревью вторым инженером.
• Открытый исходный код, который никто не разворачивает: смысла в отчёте нет.

Обратная ситуация встречается чаще: контракт небольшой, но держит средства пользователей и связан с оракулом и прокси. Тогда аудит нужен даже при скромном объёме кода, потому что цена ошибки не зависит от числа строк.

Итог

Аудит смарт-контрактов — это фиксация объёма, независимая проверка логики и прав, отчёт с проверяемыми деталями и повторная проверка исправлений. В 2026 году он остаётся обязательным шагом перед запуском, но перестал быть достаточным: большая часть потерь связана с ключами, доступом и апгрейд-механизмами. Практический вывод простой: проверяйте код, закрывайте операционный контур и держите связь между проверенным коммитом и тем, что развёрнуто. Если проект только планируется, начать разумнее с архитектуры и модели угроз — это часть разработки web3-решений, а не отдельная формальность.

Нужен аудит смарт-контрактов или проверка модели угроз? Обсудим объём и смету