Чому ручний аудит смарт-контрактів пропускає уразливості
Аудит смарт-контрактів досі тримається на людині: рев'юер читає логіку, звіряє її із задумом і перевіряє граничні умови викликів.
Поки контракт вкладається в кілька сотень рядків, ручна перевірка коду впевнено знаходить і небезпечний порядок зовнішніх викликів, і діри в розмежуванні прав, і необроблені відмови під час переказів коштів.
Проблема проявляється на обсязі змін. Коли в одному релізі змішано нову логіку, міграцію стану й перейменування, рев'юер втрачає контекст між перевірками: він судить про функцію за останньою прочитаною версією, а не за всім ланцюжком правок.
Пропущені уразливості осідають при цьому не в ядрі, а в обв'язці — модифікаторах доступу, розрахунку комісій, гілках за нульових і максимальних значень.
Окреме джерело — регрес після правок. Правка однієї функції змінює стан, від якого залежать сусідні, і без повторного прогону всього набору перевірок дефект повертається вже в іншому місці. Накопичення дрібних правок без повторного розбору зсуває поведінку системи непомітно для ока.
І ще одне: у ручного розбору немає відтворюваних сценаріїв. Кожен аудит починається з чистого аркуша, негативні кейси тримаються в голові рев'юера й не перевикористовуються від контракту до контракту. Розбираємо, як це закривається.
Що дає автоматичний аналіз коду: вимірювані ефекти
Автоматичний аналіз коду не замінює аудит повністю, а перерозподіляє увагу: машина закриває типові класи відмов, інженер розбирає економіку, права ролей і сценарії, які з шаблонів не виводяться.
Прогін займає хвилини, тому перевірка живе в конвеєрі збірки й запускається на кожну зміну, а не одноразово перед випуском.
Перший рівень — формальні правила й символьне виконання: таким набором, як Slither, перевіряють увесь репозиторій, включно із зовнішніми бібліотеками, а не лише змінені файли. Другий — ручна інспекція критичних шляхів: випуск коштів, оновлення логіки, права адміністратора.
| Що вимірюємо | До впровадження | Після | За рахунок чого |
|---|---|---|---|
| Частка знайдених дефектів | 6–7 класів із 10 при ручному читанні | 9–10 із 10, залишок — економіка й права | Увесь код під перевіркою на кожній зміні |
| Час перевірки перед випуском | тиждень ручної інспекції на реліз | години прогону й день на розбір значущих знахідок | Перевірка йде паралельно розробці |
| Простій при відмові | години на пошук причини й відкат | хвилини на повернення до попередньої версії | Регресійний набір перевірок |
| Класи відмов в експлуатації | повторні виклики, переповнення, необмежений доступ до коштів | закриваються до випуску | Правила доповнюються після кожної знахідки |
Набір перевірок накопичується: кожна закрита знахідка стає правилом і в наступній версії ловиться автоматично. Підсумок — частка знайдених дефектів зростає не за рахунок часу інженерів, а за рахунок прогонів, які йдуть без участі людини.
Формати перевірки: разовий розбір чи постійний контроль
Перевірка смарт-контракту — це не одна процедура, а набір режимів роботи системи, які відрізняються глибиною, частотою та областю аналізу: лише опублікований код чи весь його життєвий цикл разом з оновленнями.
Разовий режим відповідає на питання «чи можна випускати», решта — «що змінилося з минулого разу і що це ламає». Нижче — як це виглядає на практиці та які обмеження режиму потрібно враховувати заздалегідь.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Разова перевірка перед випуском | Логіка зафіксована, оновлення не плануються, потрібен допуск до запуску | Аналізується лише поточний стан; правки після звіту залишаються поза контролем |
| Постійний аналіз змін | Контракт розвивається, є оновлювані модулі та зовнішні залежності | Потрібен доступ до репозиторію та історії випусків; сигнали надходять лише за зміненими ділянками |
| Точковий розбір спірних ділянок з експертом | Складна економіка протоколу, механізми ліквідації, оракули, розрахунки комісій | Вищі трудозатрати: розбір потребує занурення в контекст усієї системи, а не в один модуль |
| Періодичні ревізії | Код стабільний, але змінюється оточення: залежності, стандарти, зовнішні контракти | Між ревізіями залишається вікно, коли проблема вже з'явилася, а знахідка ще не сформована |
Режими не виключають один одного: разова перевірка на вході, постійний аналіз змін на час активної розробки, ревізії за розкладом.
Спільне обмеження в них одне — система аналізує те, до чого є доступ, тому без репозиторію, артефактів збірки та опису економіки протоколу частина шляхів залишається поза розбором.
Як проходить аудит смарт-контрактів: етапи роботи
Аудит смарт-контрактів — це не разова перевірка одного файлу, а налаштування аналізу під конкретну кодову базу. Етапи впровадження будуємо так, щоб перевірки вбудувалися в поточний процес розробки.
Небезпечні місця в різних проєктах виглядають по-різному: десь критичне право на випуск токенів, десь — зовнішні виклики без перевірки результату. Тому спочатку вивчаємо код, потім налаштовуємо правила — інакше отримаємо потік хибних спрацювань, який команда перестане читати.
- Розбір репозиторію та логіки. Вивчаємо структуру контрактів, залежності, точки входу, ролі та права доступу. Відзначаємо, які частини оновлюються, а які заморожені — від цього залежить пріоритет перевірок.
- Модель поведінки. Описуємо інваріанти: що не повинно порушуватися за жодного сценарію виклику. Ця модель стає основою правил.
- Налаштування правил. Включаємо перевірки на переповнення, повторні виклики, доступ до адміністративних функцій, необроблені зовнішні виклики. Пороги та винятки підганяємо під проєкт, а не під типовий шаблон.
- Прогін на історичних змінах. Перевіряємо налаштування на минулих версіях і правках: скільки знахідок підтвердилося, скільки виявилося шумом. За результатом правимо пороги.
- Перевірка результатів інженером. Кожне спрацювання розбирає людина: підтверджує або відхиляє із зазначенням причини. Так формується база рішень для схожих випадків.
- Передача регламентів. Віддаємо опис правил, розбір спірних випадків і порядок дій при нових знахідках, навчаємо команду на її ж прикладах.
Артефакти та регламенти, які залишаються у вашої команди
Розбір окремого контракту — не кінцевий результат.
Ми передаємо вашій команді опорний набір правил перевірки, схему потоків даних із позначеними межами довіри та регламенти, за якими перевірка відтворюється без нас: новий контракт проганяється тими самими правилами, а знахідки отримують той самий рівень критичності та порядок обробки.
Що саме залишається в репозиторії поруч із кодом і у внутрішній документації:
- Набір правил перевірки: сигнатури типових дефектів — повторний вхід у функцію, небезпечні зовнішні виклики, переповнення розрядності, необмежені права власника. Правила версіонуються разом із кодом і уточнюються в міру накопичення розборів.
- Схема потоків даних і меж довіри: хто викликає контракт, які зовнішні джерела значень вважаються недовіреними, де проходить межа між вашим кодом і сторонніми викликами.
- Політики доступу: зміна правил, закриття знахідки та підписання випуску — різні ролі. Журнал дій ведеться й не переписується заднім числом.
- Звіт про перевірку за кожним розбором: адреса контракту, відбиток вихідного коду, перелік знахідок із рівнем критичності, прив'язкою до рядка, обґрунтуванням і статусом — виправлено, прийнято як ризик, відхилено.
- Регламент реагування: що робити, якщо критична знахідка спливає між перевіркою та випуском — хто зупиняє випуск, хто вирішує питання доопрацювання чи відкату й у який термін.
- Інструкції для команди: як запускати перевірку при кожній зміні коду, як додати власне правило й як оспорити хибне спрацювання з фіксацією рішення.
- Матриця покриття: які контракти та які гілки логіки вже перевірені, а які залишилися поза перевіркою — це видно до випуску, а не після інциденту.
Кейс: як зросла частка знайдених дефектів до випуску
Замовник випускав протокол на смарт-контрактах і оновлював його раз на два тижні. Кожен реліз проходив ручний розбір: два інженери порядково читали зміни й витрачали на перевірку близько 30 годин, а на нові модулі йшло помітно більше.
До впровадження розбір давав передбачувану, але обмежену вибірку. До випуску вдавалося зловити 58% дефектів, решта спливала в тестовій мережі або вже після публікації контрактів — і тоді виправлення вимагало нового релізу та міграції стану.
Частка знахідок упиралася в увагу: до кінця перевірки інженер гірше помічає однотипні шаблони — неправильні перевірки доступу, переповнення при обчисленнях.
Що змінили
Ми зібрали модель на розмітці минулих аудитів і поставили її першим шаром: статичний аналізатор Slither і модель розмічають кандидатів і ранжують їх за ймовірністю реального дефекту, а інженер підтверджує або знімає кожну знахідку. Хибні спрацювання відсікаються до того, як потраплять у звіт, тому час розбору не зростає.
На релізах після впровадження частка дефектів, знайдених до випуску, зросла з 58% до 91%, а час від знахідки до виправлення скоротився з двох діб до кількох годин — правка йде в той самий цикл, без окремого релізу.
Перевірка одного релізу займає близько 12 годин замість 30, при цьому покриття неочевидних гілок логіки вище, ніж при чистому ручному розборі.
Чим відрізняється статичний аналіз від перевірки логіки протоколу
Статичний аналіз працює з кодом, не виконуючи його: будує дерево викликів і граф залежностей, звіряє результат із каталогом типових слабкостей на кшталт SWC Registry. Так закриваються переповнення, незахищені зовнішні виклики, відсутність перевірки прав, неініціалізовані змінні.
Перевірка повна, повторювана й не залежить від фантазії інженера — але бачить лише те, що виражено в синтаксисі.
Перевірка логіки починається раніше — з моделі поведінки протоколу. Ми фіксуємо, що система обіцяє учасникам, які інваріанти зобов'язані зберігатися за будь-якого порядку транзакцій, і вже потім шукаємо місця, де код ці інваріанти порушує.
«Компілюється й проходить тести» та «поводиться коректно» — різні твердження, і між ними лежить уся зона економічних дефектів.
Другий шар — сценарії зловживання: розбір послідовностей викликів, де кожен крок легальний, а разом вони дають атакуючому вигоду.
Маніпуляція ціною оракула в межах однієї транзакції, повторний вхід через зовнішній колбек, позика без застави під голосування, випередження чужої ліквідації. Синтаксис при цьому бездоганний, і формальні перевірки за таким кодом мовчать.
Тому шари не конкурують. Статика швидко відсіює масові класи помилок по всьому масиву контрактів, модель поведінки та розбір сценаріїв ловлять композиційні дефекти, невидимі в окремій функції.
У звіті це два різних переліки знахідок із різною ціною виправлення — і замовник бачить, що саме закрито перевіркою, а що залишилося явним припущенням.
Обмеження методу та типові сумніви інженерів
Система не замінює аудит повністю, і ми прямо називаємо межі застосовності. Типові класи — повторний виклик до списання балансу, переповнення, незахищений доступ до сховища, помилки в порядку зовнішніх викликів — знаходяться стійко.
А от економічну логіку: стійкість оракула, сценарії ліквідації, маніпуляції ціною всередині однієї транзакції — модель не виводить, тут потрібен контекст задачі та модель загроз.
Хибні спрацювання відсікаються у два кроки. Спочатку перевіряємо досяжність: якщо гілка не виконується за заданих умов, знахідка позначається як незначуща.
Потім інженер підтверджує або відхиляє сигнал, і у звіт потрапляють лише підтверджені випадки — частка шуму на першому екрані падає в рази, а розбір не перетворюється на перегортання сотні однотипних попереджень.
Ручна верифікація обов'язкова там, де висновок залежить від домовленостей, а не від коду: права адміністратора, порядок оновлення контракту, розподіл комісій, розрахунок часток власників.
Що система гарантовано не знайде?
Дефекти, що випливають із зовнішніх домовленостей: помилки в токеноміці, неправильне ціноутворення, конфлікти ролей в управлінні, поведінка сторонніх контрактів і оракулів. Це закривається розбором сценаріїв разом із командою замовника.
Як ви перевіряєте якість моделі?
Проганяємо її на історичних інцидентах із відомим результатом і рахуємо, яку частку підтверджених дефектів вона знаходить і скільки дає непідтверджених спрацювань. Додатково звіряємо з незалежним статичним аналізом, розбіжності розбираємо вручну. Цільові метрики фіксуємо до старту робіт — результат залишається вимірюваним, а не оцінним.
Обговоримо задачу: що потрібно для оцінки та плану робіт
Оцінка проєкту з аудиту смарт-контрактів залежить не від кількості рядків коду, а від того, наскільки повно описані межі системи.
Якщо надсилають лише файли контрактів, без процесу випуску та історії правок, доводиться закладати запас на невідоме: терміни розтягуються, а частина шляхів залишається поза перевіркою. Щоб порахувати обсяг робіт точно, потрібні вхідні дані.
- Репозиторій або його копія: доступ на читання до коду, тестів, скриптів розгортання та налаштувань збірки.
- Адреси вже розгорнутих контрактів і мережа, у якій вони працюють, включно з випадками, коли логіка рознесена по кількох контрактах.
- Відповіді щодо процесу випуску: хто публікує зміни, чи проходить код рев'ю, хто тримає ключі адміністратора й як передаються права.
- Схема ролей і прав доступу: які операції доступні власнику, які — керуючому контракту, які відкриті всім.
- Відомі проблемні місця та історія: що вже знаходили минулі перевірки, які правки вносили після запуску й чому.
- Що вважати критичним саме для вас: виведення коштів, зміна комісій, зовнішні виклики, пауза та зупинка системи.
Порядок старту однаковий майже завжди. Спочатку обговорюємо задачу та межі перевірки — розмова займає менше години й одразу показує, де оцінка відрізнятиметься від очікувань. Потім відкриваєте доступ до репозиторію або копії, відповідаєте на питання щодо процесу випуску.
Після цього ми повертаємося з оцінкою проєкту та планом робіт: етапи, що перевіряємо на кожному, які артефакти передаємо і в якому вигляді звіт зручніше читати вашій команді. Далі — узгодження термінів і старт.
Якщо частина даних закрита, це не блокує початок: позначаємо такі ділянки в плані як неперевірені й говоримо про це прямо, а не замінюємо мовчання загальними формулюваннями.
