Значок “Audited” на сайте DeFi-протокола — это не гарантия безопасности. Аудит — всего лишь документ: что именно проверяли, в каких условиях, какие нашли проблемы и как их (не) исправили. Чтобы аудит реально помогал управлять риском, его нужно уметь читать.

Этот материал — практичный чек-лист: что смотреть в отчёте аудита за 10–15 минут, какие формулировки и детали должны насторожить, и почему “аудит есть” иногда хуже, чем честное “мы эксперимент”.

Хороший аудит — это понятный scope (какие контракты проверяли), привязка к версии/коммиту, список находок с критичностью, подтверждённые исправления и, желательно, повторная проверка. Красные флаги — старый отчёт, “мы не проверяли ключевые модули”, критичные находки без фикса, апгрейды/админ-права вне scope.

Как пользоваться чек-листом

Откройте отчёт аудита и пройдитесь по разделам ниже по порядку. Цель — ответить себе на три вопроса:

• Что именно аудировали? (scope, контракты, версия кода)
• Что нашли? (критичность, влияние, сценарии атаки)
• Что реально исправили? (доказательства фикса, re-audit, изменения после аудита)

Что должно быть в хорошем отчёте (структура)

Большинство качественных отчётов (не важно, кто аудитор) содержат похожие блоки. Если части из списка нет — это повод читать внимательнее.

• Введение: цель аудита, краткое описание системы.
• Scope: какие контракты/модули/репозитории проверялись.
• Versioning: коммит/тэг/хэш или конкретная версия кода.
• Методология: ручной анализ, тестирование, инструменты, ограничения.
• Threat model: какие угрозы рассматривались (хотя бы поверхностно).
• Findings: список находок с уровнем критичности и описанием влияния.
• Recommendations: рекомендации и best practices.
• Fix review / retest: подтверждение исправлений или повторная проверка.

Scope и версия кода: главное, что проверяют первым

Самая частая ошибка читателя — начать с “есть ли Critical”. Правильнее начать с вопроса: аудировали ли вообще то, чем я буду пользоваться?

1) Scope: какие контракты входили

• Есть список контрактов/файлов/модулей.
• Понятно, какие компоненты вне scope (oracle, мосты, фронтенд, скрипты, инфраструктура).
• Если протокол модульный (vault + strategy + router), аудированы все ключевые модули, а не один “красивый” контракт.

2) Версия кода: к чему привязан аудит

• В отчёте указан коммит/тэг/хэш репозитория.
• Есть даты: период аудита и дата релиза/деплоя.
• Вы сравниваете: текущая версия контракта в сети = версия, которую аудировали (или есть re-audit после изменений).

Находки: критичность, влияние и реальная “боль”

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

Как читать находку правильно

• Impact: что будет, если атакующий воспользуется проблемой (кража средств, заморозка, манипуляция ценой).
• Exploitability: насколько реально это эксплуатировать (нужны ли привилегии, сложные условия, большое капиталовложение).
• Attack path: описан ли сценарий атаки шагами.
• Affected components: какие функции/контракты затронуты (депозит/вывод — всегда красная зона).

Что особенно важно для депозитов

Для пользователя, который “заносит деньги”, самые опасные находки — те, что затрагивают:

• deposit/withdraw (ввод/вывод средств);
• учёт балансов (shares, accounting, fee logic);
• доступ и роли (минтер, апгрейд, пауза);
• oracle (цены, ликвидации);
• bridge/кросс-чейн (если протокол зависит от них).

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

Большая часть “маркетинговых аудитов” ломается на этом шаге. Важно не то, что нашли, а что сделали после.

• 1) Есть статус находок: Fixed / Acknowledged / Won’t fix / Mitigated.
• 2) Есть доказательство фикса: ссылка на PR/коммит, изменение кода, описание исправления.
• 3) Есть retest/review: аудитор или независимый проверяющий подтвердил исправления.
• 4) Нет “размытых формулировок”: “мы учли”, “мы приняли к сведению”, “мы планируем исправить”.

Ограничения аудита: где “дырка” даже у сильного отчёта

Даже идеальный аудит не закрывает все риски. Обычно в отчёте есть отдельный раздел “limitations”. Его нужно читать внимательно.

Что аудит часто не покрывает полностью

• Экономику протокола. Можно не найти багов, но механика стимулов может приводить к потерям.
• Риски апгрейдов (proxy). Если контракт апгрейдится, риск смещается в управление админ-правами.
• Ораклы и внешние зависимости. Иногда они прямо указаны как out-of-scope.
• Фронтенд и инфраструктуру. Фишинг и подмена домена аудит кода не решает.
• Конфигурацию деплоя. Контракт может быть аудирован, но развернут с опасными параметрами.

Про архитектурный риск апгрейдов полезно помнить всегда: “aудировали код” ≠ “безопасно пользоваться”, если код можно поменять завтра.

Красные флаги в аудите: что должно насторожить

Это список “настораживающих признаков”, которые чаще всего встречаются в проектах с завышенными рисками.

• Нет версии/коммита — аудит не привязан к конкретному коду.
• Старый отчёт, а протокол активно менялся/обновлялся после даты аудита.
• Scope узкий: аудирован “один контракт”, а система состоит из 10 модулей.
• Критичные находки закрыты формулировкой “Acknowledged / Won’t fix”.
• Нет re-audit/retest после исправлений критичных/высоких проблем.
• Большая часть находок “informational” и почти нет реальной угроз-модели — иногда это признак “поверхностного” отчёта.
• Out-of-scope вынесены ораклы/мосты/админ-логика, хотя именно там основной риск.
• Отчёт не публичный (“аудит есть, но показать не можем”).
• Нет раздела о привилегиях: кто может паузить/апгрейдить/менять параметры.
• Слишком много “предположений” (assumptions), без которых безопасность не держится.

10 быстрых вопросов перед депозитом

Если вы не хотите читать весь отчёт, задайте себе эти 10 вопросов — они покрывают 80% практического смысла аудита.

• 1) Какие контракты аудировали? Они совпадают с тем, куда я депонирую?
• 2) К какой версии/коммиту привязан аудит?
• 3) Есть ли Critical/High находки? Если да — исправлены ли они?
• 4) Есть ли подтверждение фиксов (retest/review)?
• 5) Есть ли в отчёте отдельный блок про привилегии (roles/admin)?
• 6) Указаны ли ограничения аудита (что не проверяли)?
• 7) Проверяли ли депозит/вывод и учёт балансов (accounting)?
• 8) Есть ли риск апгрейда (proxy)? Как он управляется?
• 9) Не вынесены ли ключевые компоненты (oracle/bridge) “out-of-scope”?
• 10) Прошёл ли протокол “боевую” проверку временем (история без инцидентов важна)?

FAQ

Полезные ссылки

• Смарт-контракт аудит: что он даёт и чего не гарантирует
• Что такое смарт-контракт
• Reentrancy: базовый класс атак и защита
• Риски DELEGATECALL: прокси и подмена логики