Разработка звіту аудиту смарт-контрактів
Звіт аудиту — це документ, який команда протоколу надає публічно перед запуском. Інвесторів, користувачів, та інтеграторів читають його щоб оцінити ризики. Поганий звіт — це або порожня формальність, або так технічно перевантажений текст, що нікто не розуміє реальних ризиків. Хороший звіт чесно описує що було знайдено, що виправлено, та що залишилось.
Важливо розуміти: аудитор не може гарантувати відсутність багів. Аудитор може сказати "я перевірив ці специфічні властивості цими специфічними методами і не знайшов проблем". Чесний звіт це описує.
Структура професійного звіту
Executive Summary
Перший розділ читають не розробники — інвесторів, партнери, юристи. Тут: загальний висновок (critical issues знайдені? виправлені?), scope (які контракти, commit hash, чейни), методологія (manual review, fuzzing, formal verification?), summary таблиця findings по severity.
Summary таблиця має бути на першій сторінці:
| Severity | Found | Fixed | Acknowledged | Disputed |
|---|---|---|---|---|
| Critical | 2 | 2 | 0 | 0 |
| High | 4 | 3 | 1 | 0 |
| Medium | 7 | 6 | 1 | 0 |
| Low | 12 | 8 | 4 | 0 |
| Informational | 15 | 5 | 10 | 0 |
Якщо critical issues залишилися unfixed або acknowledged — червоний прапір для читача. Аудитор не може змусити виправити — тільки задокументувати.
Scope та обмеження
Точний scope обов'язковий. Без нього незрозуміло що саме перевірялось. Має включати:
- Специфічні файли та функції (не "весь протокол")
- Repository commit hash
- Що не входило у scope (оракули, admin ключі, frontend)
- Часові обмеження та їх вплив на глибину review
Професійний аудитор чесно пише: "Через обсяг коду та часові обмеження, fuzzing проводився тільки для core swap функцій, модуль lending перевірен тільки manual review." Захищає обох аудитора та допомагає читачу зрозуміти рівень впевненості.
Методологія
Пояснює як проводився аудит:
Manual code review — побудкова перечитання коду з фокусом на відомі класи вразливостей: reentrancy, integer overflow/underflow, access control, front-running, oracle manipulation, flash loan вектори.
Automated analysis — Slither, Mythril, 4naly3er. Знаходять очевидні паттерни, генерують false positives. Результати потребують ручної валідації.
Fuzzing — Foundry Invariant testing або Echidna. Визначити інваріанти (властивості що завжди виконуються) та запустити test corpus з мільйонів випадкових inputs.
Formal verification (якщо застосовувалась) — Certora Prover або K framework. Математичне доведення властивостей. Дорого, для критичних компонентів.
Формат опису findings
Кожний findings — окрема секція зі стандартною структурою:
Заголовок з ID та severity. H-01: Reentrancy in withdraw() allows draining funds. ID для відслідковування, severity для пріоритизації.
Класифікація severity:
- Critical — втрата коштів користувачів, повний контроль контракту зловмисником
- High — частична втрата коштів, обхід критичної логіки
- Medium — нарушення інваріантів без прямої втрати коштів, DoS
- Low — неоптимальне поведення, потенційний вектор за умов
- Informational — code quality, gas inefficiency, best practice порушення
Опис вразливості. Що саме неправильно та чому це проблема. Специфічна функція, рядки коду, механізм експлуатації.
Proof of Concept. Для critical та high — обов'язковий. Foundry тест демонструючи експлуатацію.
Рекомендація по виправленню. Конкретна — не "додайте перевірку", а "додайте nonReentrant модифікатор з OpenZeppelin ReentrancyGuard та перенесіть state update перед зовнішнім викликом (Checks-Effects-Interactions паттерн)".
Відповідь команди та статус. Після того як команда відповідає — додаємо статус: Fixed (з commit hash), Acknowledged (команда знає та приймає ризик), Disputed (команда не згодна).
Додатки
Appendix A: Test Coverage. Процент рядків/функцій/гілок покритих тестами. forge coverage --report lcov. Низьке coverage (<70%) саме по собі ризик.
Appendix B: Automated Tools Output. Raw Slither/Mythril вихід з нотатками які false positives та чому.
Appendix C: Code Quality. Стиль, документація (NatSpec), события для мониторингу, upgrade паттерн, admin key ризики.
Робота з командою
Якісний аудит — це діалог, не монолог. Після початкового review аудитор передає findings команді, команда виправляє та пояснює спірні моменти. Аудитор верифікує виправлення (окремий review). Фінальний звіт відображає фінальний стан.
Best practice: публікувати не тільки фінальний звіт але й changelog — що було знайдено, що виправлено. Показує зрілість команди.
Сроки: 1-3 тижні залежно від обсягу коду та глибини review. Середній DeFi протокол (5-10 контрактів, 2000-5000 Solidity рядків) — 2 тижні.