Блокчейн
Аудит смарт-контрактов
В 2023 году DeFi-протоколы потеряли более $1.8 миллиарда из-за взломов и эксплойтов. При этом протоколы с качественным аудитом теряли средства в 3-5 раз реже, а те, что комбинировали аудит с bug bounty и мониторингом, практически не попадали в заголовки. Аудит смарт-контракта это не формальность и не галочка перед деплоем. Это систематический процесс, в котором специалисты за $50,000-500,000 неделями разбирают каждую строку кода, моделируют атаки и пишут PoC-эксплойты для найденных уязвимостей. Один пропущенный баг может стоить протоколу сотни миллионов, а аудитору, который его нашёл через bug bounty, принести миллионы в награду.
- **Euler Finance (2023, 197M)** - аудирован 6 раз разными фирмами, включая Trail of Bits. Уязвимость в функции donateToReserves позволяла создать bad debt. Ни один из шести аудитов не обнаружил баг, который нашёл атакующий. После взлома средства были возвращены через переговоры
- **Code4rena Top Auditors** - лучшие wardens на платформе конкурентных аудитов зарабатывают $200K-$1M+ в год, находя уязвимости в протоколах параллельно с десятками других исследователей. Конкурентный формат мотивирует глубокий анализ и покрывает слепые зоны частных аудитов
- **Immunefi Bug Bounty ($10M)** - рекордная выплата $10M за Critical-уязвимость в Wormhole bridge. White-hat исследователь обнаружил баг, позволявший украсть все залоченные средства, и ответственно раскрыл его через bug bounty вместо эксплуатации
Предварительные знания
Процесс аудита: от scoping до финального отчёта
Аудит смарт-контракта - это не просто "прочитать код и найти баги". Это систематический процесс с чётко определёнными фазами, где каждый этап имеет свои методологии и deliverables. Опытный аудитор тратит на review **200-500 строк кода в день** - не потому что медленно читает, а потому что каждая строка требует анализа в контексте всего протокола: какие state-переменные она затрагивает, какие инварианты может нарушить, какие edge-case-ы не учтены. Аудит протокола на 5,000 строк Solidity занимает у команды из 2-3 аудиторов от 2 до 4 недель.
**Фаза 1: Scoping** - определение границ аудита. Аудитор получает от клиента: исходный код (конкретный commit), документацию (whitepaper, спецификацию), предыдущие отчёты аудитов, deployment-конфигурацию. На этом этапе строится **threat model**: кто потенциальные атакующие (user, admin, miner/validator, другой контракт), какие активы под угрозой (ETH, ERC-20, NFT, governance power), какие инварианты должны всегда выполняться (`totalSupply == sum(balances)`, `msg.sender проверяется перед state-change`). Scoping определяет стоимость и сроки аудита.
**Фаза 2: Manual Review** - ядро аудита. Три ключевых подхода: **line-by-line** - построчный анализ каждой функции (самый медленный, но самый тщательный); **function-by-function** - анализ каждой функции как чёрного ящика (входы → state changes → выходы → events); **attack surface mapping** - идентификация всех точек входа (public/external функции), всех external calls, всех точек доступа к privileged операциям. Лучшие аудиторы комбинируют все три подхода и ведут **заметки** по каждой функции: предполагаемое поведение, edge cases, потенциальные проблемы.
**Фазы 3-5** завершают процесс. **Testing** (фаза 3) включает запуск автоматических инструментов (Slither, Aderyn, Mythril) и написание PoC-эксплойтов для подтверждённых уязвимостей. **Reporting** (фаза 4) - структурированный документ со всеми находками, их severity и рекомендациями. **Fixes Review** (фаза 5) - аудитор проверяет, что команда правильно исправила все Critical и High findings, не внесла новых уязвимостей в процессе. Крупные аудиторские фирмы - **Trail of Bits**, **OpenZeppelin**, **Spearbit**, **Cyfrin** - стоят от $50,000 до $500,000+ за полный аудит. Конкурентные платформы **Code4rena** и **Sherlock** предлагают альтернативу: десятки аудиторов параллельно ищут баги за вознаграждение.
Аудит - это **не гарантия безопасности**. Даже протоколы с 3-5 аудитами от топовых фирм подвергались взломам (Euler Finance - 197M, аудирован 6 раз). Аудит снижает вероятность уязвимости, но не исключает её. Поэтому зрелые протоколы дополняют аудит **bug bounty** программами, **monitoring** системами и **incident response** планами.
Опытный аудитор анализирует 200-500 строк Solidity в день. Какова основная причина такой низкой скорости?
Типичные находки: классификация и реальные примеры
Каждая находка в аудите получает **severity level** - оценку серьёзности, определяющую приоритет исправления. Стандартная классификация включает 6 уровней: от **Critical** (немедленная потеря средств) до **Gas** (оптимизация без влияния на безопасность). Severity определяется комбинацией двух факторов: **impact** (какой ущерб может нанести уязвимость) и **likelihood** (насколько вероятна эксплуатация). Critical vulnerability с высоким impact, но требующая специфических условий, может быть понижена до High.
Статистика реальных аудитов показывает, что одни и те же категории уязвимостей встречаются снова и снова. По данным **Code4rena** за 2023-2024: **Access Control** - ~25% всех High/Critical (отсутствие модификаторов, некорректная проверка `msg.sender`). **Logic Errors** - ~20% (неправильная бизнес-логика, ошибки в формулах). **Reentrancy** - ~10%. **Front-running / MEV** - ~8%. **Oracle manipulation** - ~7%. **Centralization risks** - ~15% Medium (owner может rug-pull, single point of failure). Остальные - integer issues, DoS, missing events, gas optimization.
**Centralization risks** - особая категория, часто игнорируемая разработчиками. Если owner-адрес (EOA или multisig) может: менять ключевые параметры без timelock, ставить контракт на паузу навсегда, обновлять implementation proxy на произвольный код, выводить средства пользователей через backdoor-функцию - это **rug-pull вектор**. Аудиторы оценивают не только "может ли хакер сломать контракт", но и "может ли owner злоупотребить властью". Рекомендация: **multisig** (Gnosis Safe) + **timelock** (24-48 часов) + **transparent governance**.
Lending-протокол использует spot price из Uniswap pool для оценки collateral. Аудитор пометил это как High severity. Почему?
Инструменты: Slither, Aderyn и автоматический анализ
Ручной аудит незаменим, но **автоматический статический анализ** - обязательный первый шаг. Он за секунды находит паттерны уязвимостей, которые человек может пропустить от усталости. **Slither** от Trail of Bits - de facto стандарт индустрии: open-source, 90+ встроенных детекторов, понимает Solidity AST (Abstract Syntax Tree). Slither не заменяет аудитора - он обрабатывает "low-hanging fruit" и позволяет аудитору сфокусироваться на сложной логике, где автоматика бессильна.
Помимо детекторов, Slither предоставляет **printers** - утилиты для визуализации структуры контракта. `--print inheritance-graph` строит дерево наследования, `--print function-summary` показывает все функции с их visibility и modifiers, `--print call-graph` - граф вызовов между функциями. Для аудитора printers - инструмент разведки: они помогают быстро понять архитектуру незнакомого проекта до погружения в код.
**Aderyn** от Cyfrin - новый инструмент статического анализа, написанный на Rust (значительно быстрее Slither на Python). Aderyn генерирует Markdown-отчёт с находками, структурированный как настоящий аудит-репорт. **4naly3er** - ещё один инструмент, специализирующийся на gas-оптимизациях и Low/Informational находках. В production-workflow все три инструмента дополняют друг друга: Slither для глубокого анализа, Aderyn для быстрого скана, 4naly3er для gas-оптимизаций.
**Практический workflow аудитора с инструментами:** 1. `slither . --print function-summary` - быстрый обзор всех функций. 2. `slither . --print inheritance-graph` - понять архитектуру наследования. 3. `slither .` - запустить все детекторы, отфильтровать false positives. 4. `aderyn .` - получить второе мнение от другого анализатора. 5. Только после автоматического анализа - приступить к manual review с фокусом на бизнес-логику, которую автоматика не покрывает.
Slither обнаружил `reentrancy-eth` в функции, которая использует `call{value}()`. Однако функция защищена модификатором `nonReentrant`. Что должен сделать аудитор?
Написание отчёта, bug bounty и responsible disclosure
Audit report - финальный deliverable, ради которого всё затевалось. Качественный отчёт - не просто список багов: это документ, по которому команда разработчиков должна суметь воспроизвести, понять и исправить каждую уязвимость. Структура отчёта стандартизирована индустрией и включает **Executive Summary** (для руководства, без технических деталей), **Scope** (что аудировалось), **Findings** (все уязвимости с деталями), **Recommendations** (как исправить) и **Appendix** (газ-оптимизации, informational notes).
Каждая finding - самодостаточный документ. Аудитор, который нашёл баг, должен написать находку так, чтобы разработчик, никогда не видевший отчёт ранее, мог понять проблему и исправить её. Ключевой элемент - **Proof of Concept (PoC)**: рабочий код или пошаговая инструкция, демонстрирующая эксплуатацию. Без PoC находка - это мнение; с PoC - это доказательство.
Помимо частных аудитов, существуют **конкурентные аудиты** и **bug bounty** программы. **Code4rena** и **Sherlock** - платформы, где десятки-сотни аудиторов ("wardens") одновременно ищут баги в протоколе за pool вознаграждений ($20K-$500K+). Судьи оценивают уникальность и severity каждой находки. **Immunefi** - крупнейшая платформа bug bounty в Web3: выплаты до $10M за Critical (рекорд - $10M от Wormhole). Immunefi reports подчиняются **responsible disclosure**: исследователь сообщает об уязвимости приватно, даёт время на исправление, и только потом (обычно 90 дней) деталями можно делиться публично.
**Code4rena competitive audit - как это работает для аудитора:** 1. Выбираете contest с интересным протоколом. 2. 3-7 дней на поиск уязвимостей в публичном репозитории. 3. Пишете submission (finding) с severity, description, PoC, recommendation. 4. Судьи дедуплицируют находки - если 5 аудиторов нашли один и тот же баг, вознаграждение делится. 5. Уникальные High/Medium findings оплачиваются лучше всего. Топ-аудиторы на Code4rena зарабатывают $200K-$1M+ в год.
**Responsible disclosure** - этическое обязательство каждого security-исследователя. Найденную уязвимость в deployed-контракте **нельзя** публиковать до того, как команда исправит проблему. Правильная последовательность: 1. сообщить команде через bug bounty программу или приватный канал 2. дать 48-96 часов на emergency response 3. дождаться исправления или истечения grace period (90 дней) 4. только потом - публичный disclosure. Эксплуатация найденной уязвимости вместо disclosure - это **black-hat** поведение с уголовными последствиями в большинстве юрисдикций.
Один аудит от топовой фирмы гарантирует безопасность контракта - если аудит пройден, можно деплоить и не беспокоиться
Аудит - это snapshot безопасности кода на конкретный момент времени. Он значительно снижает риск, но не может гарантировать отсутствие уязвимостей: аудиторы - люди, которые могут пропустить сложный баг, а новые attack vectors появляются после аудита. Зрелые протоколы используют многоуровневую защиту: множественные аудиты + конкурентный аудит + bug bounty + on-chain monitoring + incident response plan
Итоги
- **Процесс аудита** состоит из 5 фаз: scoping → manual review → automated testing → reporting → fixes review. Опытный аудитор анализирует 200-500 LOC/день, потому что каждая строка требует контекстного анализа инвариантов, attack surface и межконтрактных взаимодействий
- **Severity** определяется матрицей Impact × Likelihood: от Critical (прямая потеря средств, высокая вероятность) до Informational (best practices). Топ-категории реальных находок: access control (~25%), logic errors (~20%), reentrancy (~10%), oracle manipulation (~7%), centralization risks (~15%)
- **Slither** (Trail of Bits) - стандарт индустрии для статического анализа: 90+ детекторов находят reentrancy, uninitialized storage, unchecked calls за секунды. Aderyn (Cyfrin) дополняет быстрым Rust-сканом. Автоматика не заменяет manual review, но обрабатывает паттерны, которые человек может пропустить
- **Audit report** - структурированный документ с Executive Summary, Scope, Findings (каждая с severity, description, PoC, recommendation). Proof of Concept превращает мнение в доказательство - без него находка не имеет веса
- Один аудит - не гарантия безопасности: Euler Finance потеряла 197M после 6 аудитов. Надёжная стратегия - частный аудит → конкурентный аудит (Code4rena) → деплой → bug bounty (Immunefi) → on-chain мониторинг. Именно многоуровневая защита отличает протоколы, которые теряют миллиарды, от тех, что выдерживают атаки
Связанные темы
Аудит объединяет все знания о безопасности смарт-контрактов - от конкретных уязвимостей до методов их автоматического обнаружения:
- Reentrancy и классические атаки — Reentrancy - одна из первых проверок в любом аудите. Детектор reentrancy-eth в Slither автоматически ищет паттерн state-change после external call
- Overflow и underflow — Integer overflow/underflow - категория High-findings в аудитах контрактов на Solidity < 0.8. Slither детектор unchecked-arithmetic находит их автоматически
- Формальная верификация — Следующий уровень после аудита: математическое доказательство корректности. Certora, Halmos дополняют ручной review формальными гарантиями инвариантов
- Fuzzing смарт-контрактов — Фаза testing в аудите включает fuzzing: Echidna и Foundry генерируют тысячи случайных входов для поиска нарушений инвариантов, которые пропустил ручной review
Вопросы для размышления
- Euler Finance прошла 6 аудитов от ведущих фирм, но всё равно потеряла 197M. Означает ли это, что аудиты бесполезны? Или что текущая модель аудита - snapshot одного момента времени - фундаментально недостаточна для протоколов, которые постоянно обновляются и взаимодействуют с другими протоколами?
- Конкурентные аудиты (Code4rena) делают код публичным на время contest-а. Это означает, что потенциальные атакующие тоже видят код и ищут баги. Как вы считаете, перевешивают ли преимущества десятков глаз риск раскрытия кода? Существуют ли ситуации, когда конкурентный аудит противопоказан?
- White-hat хакер обнаружил Critical-уязвимость в deployed-протоколе без bug bounty программы. Responsible disclosure требует приватного сообщения команде, но команда может просто исправить баг без вознаграждения. Как должна быть устроена система стимулов, чтобы исследователи всегда выбирали disclosure вместо эксплуатации?