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

Смарт-контракт нельзя поправить после запуска, а ошибка может стоить миллионы. Поэтому код проверяют до запуска (аудит) и после него поощряют тех, кто найдёт уязвимость (баг-баунти). Для пользователя важно понимать, что именно значит надпись «проект проаудирован» и чего она не гарантирует. Контекст - в каталоге уязвимостей и статье про тестирование.

Что такое аудит

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

Аудит - это:

• проверка конкретной версии кода (по хешу коммита);
• ограниченное по времени исследование (обычно 1-4 недели);
• экспертная оценка, а не математическое доказательство.

Как проходит аудит

1. Определение объёма. Какие контракты, версии, внешние зависимости входят в проверку.
2. Подготовка. Команда проекта даёт документацию, описание ожидаемого поведения, тесты.
3. Автоматизированный анализ. Статические анализаторы (например, Slither), фаззинг, символьное исполнение.
4. Ручной разбор. Эксперты читают код построчно, ищут логические ошибки, проверяют инварианты и граничные случаи, моделируют атаки.
5. Отчёт и обсуждение. Находки классифицируются, команда комментирует.
6. Исправления. Разработчики вносят правки.
7. Повторная проверка. Аудиторы подтверждают, что исправления закрыли проблемы и не создали новых.
8. Публикация. Финальный отчёт публикуется (иногда после запуска).

Уровни серьёзности

Для каждой находки в отчёте указан статус: исправлено, признано без исправления (с обоснованием) или не исправлено.

Чем аудит не является

• Не доказательство отсутствия ошибок. Аудиторы находят то, что видят за отведённое время.
• Только эта версия кода. Любое изменение после аудита выходит за пределы проверки.
• Не проверка всей системы. Фронтенд, серверы, процессы управления ключами, поведение людей часто остаются за рамками.
• Не защита от вредительства команды. Если у команды есть возможность обновить контракт, аудит версии не защитит от будущей подмены (прокси).
• Качество различается. Репутация и опыт фирмы имеют значение.

Как читать отчёт и оценивать проект

1. Совпадает ли проверенный код с развёрнутым? В отчёте указан хеш коммита или адрес; сверьте с верифицированным контрактом.
2. Кто аудитор и как давно на рынке? Есть ли публичные отчёты, репутация?
3. Что в объёме? Все ли контракты вошли?
4. Статус находок. Исправлены ли критические и высокие? «Не исправлено» по критическим - серьёзная тревога.
5. Дата. Давно ли проведён аудит и были ли изменения после.
6. Допущения. Какие доверительные предположения делает система (роли, оракулы, администратор)? (права владельца)
7. Несколько независимых проверок лучше одной.

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

Другие способы проверки

• Соревнования аудиторов. Площадки (Code4rena, Sherlock, Cantina и др.) выставляют код на публичное исследование с призовым фондом. Много независимых глаз находят разные проблемы.
• Формальная верификация. Математическое доказательство, что код соответствует спецификации. Мощно, но трудоёмко и применимо к ограниченным свойствам.
• Внутреннее ревью и тесты - Foundry, фаззинг, инварианты.
• Мониторинг после запуска. Системы, замечающие подозрительную активность и позволяющие нажать паузу.

Баг-баунти

Баг-баунти - программа вознаграждения для исследователей, которые находят уязвимости в работающем проекте и сообщают о них ответственно.

Как устроено:

1. Проект публикует правила: что входит в область, какие уязвимости принимаются, размеры наград по серьёзности.
2. Исследователь сообщает приватно (не публикуя) через специальную площадку или контакт безопасности.
3. Команда проверяет и устраняет проблему.
4. Исследователю выплачивается награда; информация раскрывается после исправления.

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

Ответственное раскрытие

Если вы нашли уязвимость:

1. Не используйте её для получения выгоды и не демонстрируйте на реальных средствах.
2. Сообщите приватно разработчикам.
3. Дайте время на исправление до публикации.
4. Следуйте правилам программы баунти.

Эксплуатация уязвимости - преступление, а ответственное раскрытие - легальный и часто хорошо оплачиваемый путь.

Что может сделать обычный пользователь

• Проверяйте, есть ли у проекта отчёты и программа баунти.
• Не вкладывайте больше, чем готовы потерять, пока проект молод.
• Следите за обновлениями безопасности.
• Применяйте личные меры защиты: большинство потерь происходит не из-за контрактов, а из-за людей (фишинг).
• Для сделок учитывайте, что эскроу уменьшает риск контрагента, но не отменяет риск программного кода.

Что почитать дальше

Вернитесь к практике: чек-лист безопасности или жизненный цикл сделки. Для разработчиков - оптимизация газа без ущерба для безопасности.