Читать отчёт об аудите смарт-контракта и не повторять чужих ошибок помогает один навык — умение читать шкалу серьёзности. Большинство ошибок при знакомстве с отчётом сводится к неверному толкованию слов «critical», «medium» и «acknowledged». Количество находок ничего не говорит. Решает связка трёх полей: уровень, статус устранения и то, на кого направлен ущерб.

Шкала серьёзности в отчёте об аудите — это оценка находки по двум составляющим: насколько тяжелы последствия и насколько легко довести ошибку до эксплуатации; рядом с уровнем обязательно указывают статус — исправлено, принято как есть или отложено.

Откуда берутся уровни и почему они разные

Единого обязательного стандарта для аудитов смарт-контрактов нет. Большинство команд опирается на подход, принятый в отрасли безопасности: базовая оценка складывается из группы метрик эксплуатируемости и группы метрик воздействия, а числовому значению соответствует словесный уровень. В спецификации CVSS версии 3.1 шкала задана так: 0,0 — отсутствие, от 0,1 до 3,9 — низкий, от 4,0 до 6,9 — средний, от 7,0 до 8,9 — высокий, от 9,0 до 10,0 — критический.

Аудиторы адаптируют эту логику под контракты. Где-то «critical» означает прямую потерю средств пользователей, где-то — любую возможность вмешаться в работу протокола. Слово одно. Содержание разное. Поэтому сравнивать отчёты двух команд по количеству «критических» находок бессмысленно: при разных определениях уровня вы сопоставляете не степень опасности двух протоколов, а устройство двух измерительных линеек.

Из редакционной практики: читатели чаще всего задают вопрос «сколько там критических», а правильный первый вопрос другой — по какой методике считали и что команда сделала с каждой находкой.

Пять чужих ошибок и правильное чтение

Как читают Какой вывод делают Что это значит на деле Как читать правильно
Смотрят только на число находок «Ноль критических — безопасно» Отсутствие критических находок означает, что их не нашли в проверенном объёме кода за отведённое время Начинать с раздела о границах проверки, а не со сводной таблицы
Путают уровень с вероятностью «Critical — значит, вот-вот произойдёт» Уровень объединяет тяжесть последствий и сложность эксплуатации, а не прогноз события Смотреть, что именно в оценке дало высокий балл: последствия или лёгкость атаки
Игнорируют статус устранения «Critical страшнее, чем medium» Исправленная критическая находка закрыта, а принятая средняя остаётся в работающем коде Читать уровень и статус вместе, сортировать отчёт по статусу
Пропускают информационные пункты «Informational — придирки стиля» В этот раздел часто попадают замечания о централизации и административных полномочиях Прочитать информационный блок целиком, он короткий и говорит о рисках управления
Воспринимают отчёт как сертификат «Протокол прошёл аудит, значит проверен» Отчёт описывает состояние конкретной версии кода на конкретную дату и содержит оговорку об ответственности Найти дисклеймер и дату, затем проверить, та ли версия работает сейчас
Сравнивают отчёты разных команд «У этих находок меньше — они надёжнее» Методики, глубина проверки и шкалы различаются, а число находок зависит и от объёма кода Сравнивать не числа, а покрытие, методику и реакцию команды на замечания
Числовые границы шкалы заданы в спецификации CVSS версии 3.1: None — 0,0; Low — от 0,1 до 3,9; Medium — от 4,0 до 6,9; High — от 7,0 до 8,9; Critical — от 9,0 до 10,0. Базовая оценка складывается из метрик эксплуатируемости и метрик воздействия на конфиденциальность, целостность и доступность. Документ сверен по тексту спецификации на 15 октября 2026 года. Отчёты по смарт-контрактам используют эту шкалу как ориентир, а не как обязательную норму.
Статус «acknowledged» или «принято как есть» означает, что команда согласилась с находкой и решила ничего не менять. Это законная позиция: исправление иногда дороже риска. Но для пользователя такая строка важнее трёх исправленных критических, потому что описанное в ней поведение работает прямо сейчас.

Порядок чтения за полчаса

  1. Титул и дата. Запишите версию кода, которую проверяли.
  2. Границы проверки. Убедитесь, что ваш модуль в списке.
  3. Методика и шкала. Посмотрите, как команда определяет уровни.
  4. Сводная таблица находок, отсортированная по статусу, а не по уровню.
  5. Все пункты со статусом «принято как есть» — читать целиком.
  6. Информационный раздел и замечания о централизации.
Схема из пяти шагов чтения отчёта: дата и версия кода, границы проверки, методика и шкала уровней, сортировка находок по статусу, разбор принятых как есть и информационных пунктов
Схема из пяти шагов чтения отчёта: дата и версия кода, границы проверки, методика и шкала уровней, сортировка находок по статусу, разбор принятых как есть и информационных пунктов

Что делать с находкой, которая вас касается

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

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

Третий шаг касается продуктов со сложной механикой выплат, где находка может означать иное распределение результата между сторонами. Устройство такого продукта разобрано в тексте о том, как работает структурный продукт SharkFin с защитой капитала.

Чего отчёт не говорит никогда

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

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

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

Чек-лист

  • Дата отчёта и проверенная версия кода выписаны.
  • Раздел о границах проверки прочитан до сводной таблицы.
  • Методика определения уровней найдена и понята.
  • Находки отсортированы по статусу устранения.
  • Все пункты «принято как есть» прочитаны целиком.
  • Информационный раздел просмотрен на предмет централизации.
  • Дисклеймер прочитан, ограничения ответственности отмечены.
  • Число находок не использовалось для сравнения двух протоколов.

Частые вопросы

Отчёт без критических находок — хороший знак?

Сам по себе он говорит немного. Отсутствие критических пунктов может означать зрелый код, а может — узкие границы проверки или короткий срок работы. Смотрите на объём проверенного, методику и на то, сколько находок других уровней осталось без исправления. Эти три параметра информативнее, чем нули в верхней строке таблицы.

Почему у одного протокола два отчёта с разными оценками?

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

Что опаснее: исправленная критическая находка или принятая средняя?

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

Нужно ли разбираться в коде, чтобы прочитать отчёт?

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

Материалы по теме:

Шкалу серьёзности читают по первоисточнику — спецификации CVSS версии 3.1; методические материалы по защите информации публикуются на странице Банка России об информационной безопасности.

Вердикт

Чужие ошибки при чтении отчётов однотипны и стоят дорого: человек принимает маркетинговую фразу «прошёл аудит» за гарантию, считает нули в таблице и не доходит до раздела с принятыми находками, где описано поведение работающего кода. Читайте статус раньше уровня. Читайте границы раньше находок. Это переворачивает отчёт нужной стороной за полчаса.

Разборы отчётов и обновлений протоколов — в Telegram-канале Cryptium.