AI-розбір уразливостей смарт-контрактів і сліпі зони аудиту
Уразливості смарт-контрактів рідко виглядають як явна помилка в одній функції.
Частіше це коректний код, який поводиться неправильно в конкретній послідовності викликів: обхід перевірки прав доступу через функцію-посередник, повторний виклик, що повертає виконання в середину операції до запису у сховище, або помилка логіки контракту в рідкісній гілці розрахунку.
Статична перевірка таке пропускає — вона дивиться на функцію, а не на стан контракту між транзакціями.
Тому AI-аналіз смарт-контрактів будують як шар поверх статики: модель проходить графом викликів повністю, зіставляє точки входу з правами, які вони реально дають, і позначає, де зовнішній виклик іде раніше за зміну стану.
На виході — не абстрактне попередження, а сценарій експлуатації: яка послідовність транзакцій, від якої адреси і що саме втрачає протокол.
Solidity додає свій пласт: успадкування, контракти-посередники й делегування приховують реальні права за ланцюжком викликів, а дані із зовнішніх джерел змінюються між перевіркою та використанням.
Помилка логіки контракту найчастіше проявляється саме тут — умова правильна в момент читання і перестає бути правильною до моменту запису.
Знахідки ми розділяємо за класами — обхід прав, повторний виклик, маніпуляція зовнішніми даними, помилка логіки — і для кожного описуємо, чи відтворюється він на тестовій мережі та як закривається правкою. Далі дивимося, що саме перевіряється автоматично, а що залишається за інженером.
Що дає безперервна перевірка коду перед кожним релізом
Безперервна перевірка коду вбудована в конвеєр збірки й запускається на кожній значущій зміні, а не в кінці циклу. Розбір іде за двома лініями: статичний аналіз дерева викликів на актуальній гілці Slither і прогін сценаріїв на інваріанти в ізольованій мережі.
Знахідка приходить із трасуванням виклику та мінімальним відтворенням — її підтверджують або спростовують, а не сперечаються про формулювання попередження.
Що це змінює за пунктами:
- Знятий клас відмов. Повторний вхід, помилки прав доступу й переповнення відсікаються до збірки релізної гілки — викотити їх в основну мережу вже не можна.
- Розбір перед релізом. Звіт по змінах приходить на рев'ю, а не через тиждень після викладки, тому правки потрапляють у той самий цикл.
- Керований потік знахідок. Критичне піднімається нагору, дублікати згортаються, шум відсікається правилами — замість лавини перед запуском команда отримує чергу з пріоритетами.
- Термін випуску релізу. Перевірка йде паралельно розробці, і фінальний розбір перестає бути окремим етапом очікування.
- Менше ручних прогонів. Автоматика закриває типові перевірки, ручний розбір залишається на логіку економіки протоколу та права управління.
Політика перевірок живе в репозиторії: набір правил, поріг блокування релізу та історія рішень за кожною знахідкою. Частка змін, перевірених до релізу, і кількість знахідок на реліз видно у звіті — якість перестає обговорюватися на словах.
Режими перевірки коду: разовий аудит і безперервний контур
Жоден режим перевірки не дає повної картини сам по собі — вони закривають різні класи дефектів. Разовий аудит контракту ловить логічні помилки, які не описуються шаблоном, але до наступного коміту його висновки застарівають.
Безперервний контур перевірки спрацьовує на кожну зміну, зате бачить лише те, що вдалося формалізувати правилом або сценарієм. Вибір залежить від того, де контракт у життєвому циклі та якою є ціна помилки.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Разовий ручний аудит | перед заморожуванням логіки та виведенням у мережу, коли права доступу й виплати нестандартні | результат живе до першої зміни, перевірку потрібно проводити заново |
| Статичний аналіз | постійна перевірка на кожному коміті: переповнення, повторні виклики, небезпечні зовнішні звернення | частина спрацьовувань хибна, порядок викликів між контрактами не видно |
| Прогін сценаріїв | розгалуження економіки: ліквідації, аукціони, граничні суми, рідкісні послідовності викликів | покриття залежить від закладених шляхів — неперевірений шлях залишається дірою |
| Формальне доведення властивостей | інваріанти ядра: збіжність балансів, недоступність виведення після блокування | потребує явного формулювання властивостей і не покриває зовнішні залежності |
Як режими поєднуються
На кожному коміті йде статичний аналіз, сценарії крутяться в нічному прогоні, для ядра доводяться властивості, а ручний аудит підключають перед великим релізом або зміною моделі доступу.
Дешеві перевірки відсікають масові дефекти, дорогі — дістаються ділянкам, де помилка має найбільшу ціну.
Як проходить впровадження: кроки від аудиту до передачі
Впровадження йде ітераціями по одному-двох тижнях: спочатку фіксуємо поточний стан контрактів, потім збираємо контур перевірки і лише після цього вбудовуємо його в процес випуску.
Порядок саме такий — якщо одразу налаштовувати правила без інвентаризації, аналізатор починає шуміти на легітимних патернах проєкту, і команда перестає йому довіряти.
- Аудит коду контрактів. Збираємо перелік контрактів, їхні версії, зв'язки між ними, права ролей і зовнішні виклики. На виході — карта того, що взагалі потрібно перевіряти.
- Схема контуру перевірки. Визначаємо, де запускається аналіз: на кожній зміні, перед злиттям гілки або за розкладом для вже розгорнутих контрактів.
- Налаштування правил. Вмикаємо перевірки під предметну логіку: управління доступом, робота із зовнішніми викликами, порядок зміни стану. Нерелевантні правила вимикаємо, щоб не створювати шум.
- Тестові сценарії. Проганяємо контур на історичних релізах і на навмисно внесених помилках — бачимо, що він ловить, а що пропускає.
- Розбір хибних спрацьовувань. Кожне спірне спрацьовування розмічаємо з вашою командою: підтверджена проблема, допустимий патерн або прогалина в правилі. За підсумками правила коригуються.
- Вбудовування в процес розробки. Перевірка стає обов'язковим кроком перед випуском, зі зрозумілим статусом і порогом, за якого реліз блокується.
- Передача документації та навчання. Віддаємо опис контуру, набір правил з обґрунтуванням, інструкцію з розбору знахідок і проводимо навчання команди.
Готовність фіксуємо за вимірюваними критеріями: частка хибних спрацьовувань на вашому коді, час перевірки однієї зміни та кількість знахідок, підтверджених як реальні. Якщо правила дають шум вище узгодженого порогу, етап не закривається.
Артефакти передачі: правила, схеми та регламент прогонів
Передача контуру — не підсумковий звіт, а набір артефактів, які залишаються у вашому репозиторії та працюють без нас. Якщо команда не може сама запустити перевірку, розібрати знахідку й пояснити походження результату, робота не закрита.
- Карта ролей і прав доступу: хто запускає прогони, хто підтверджує знахідку, хто править правила розбору, хто бачить лише звіти. Права видаються групами — персональних безстрокових доступів не залишається.
- Схема архітектури: компоненти контуру, межі довіри та точки, де вихідні коди контрактів покидають ваш периметр і як результат повертається назад.
- Конфігурації розбору: файли правил, пороги спрацьовування та список пригнічених попереджень з обґрунтуванням — усе версіонується разом із кодом.
- Регламент прогонів: що запускає перевірку (зміна коду, підготовка релізу, регулярний прогін), глибина, очікуваний час і поведінка контуру при збої.
- Набір перевірочних сценаріїв: контракти з відомими дефектами, за якими видно, що після доопрацювань контур не почав пропускати те, що ловив раніше.
- Порядок розбору знахідок: рівні критичності, термін реакції на кожен, хто приймає рішення і як фіксується вердикт «беремо в роботу» або «хибне спрацьовування».
- Документація щодо контуру: як оновлювати правила, що робити при зміні інструментів збірки та куди дивитися в журналах при розбіжності результату.
Кейс: розбір коду перед запуском замість аудиту по факту
Замовник — команда, що випускає протокол зі смарт-контрактами, де помилка в логіці переказів загрожує втратою коштів без можливості відкату.
До впровадження перевірки йшли по факту: аудитори підключалися до замороженого коду за кілька днів до релізу, а між аудитами розробники вливали зміни без автоматичної перевірки.
Звіти приходили пачками попереджень, значна частина яких виявлялася хибною, і через пару тижнів їх перестали читати.
Ми зібрали контур, який працює на кожній зміні. Ядро — аналізатор Slither, доповнений моделлю, навченою на розмічених знахідках конкретно цього проєкту: вона ранжує попередження за ймовірністю реальної експлуатації та відсікає шаблонний шум. Вердикт по коміту приходить у запит на злиття до рев'ю, а не після злиття.
Метрики до і після
Частка уразливостей, знятих до релізу, зросла з приблизно половини до 92% — решта потрапляє до плану правок, а не в інциденти. Частка хибних спрацьовувань упала з 60% до 12%, тому на звіт дивляться, а не ігнорують його.
Час від коміту до вердикту по змінах скоротився з півгодини ручного розбору до 6-8 хвилин автоматичного прогону.
Щодо терміну випуску це дало зворотний ефект: релізний цикл стиснувся з трьох тижнів до дев'яти днів, бо правки безпеки перестали збиратися в окрему фазу в кінці. Найцінніше те, що знахідка приходить авторові зміни, поки контекст ще в голові.
Чим AI-розбір відрізняється від правил і сигнатурного пошуку?
Сигнатурний пошук і правила працюють на розборі коду в дерево та пошуку відомих шаблонів: виклик зовнішньої адреси до зміни стану, необроблений результат виклику, перевірка прав за джерелом транзакції.
Там, де клас уразливості вкладається в шаблон, підхід дає точний і пояснюваний результат — знахідку можна показати на конкретному рядку й конкретному шляху виконання.
Межа починається там, де шаблон перестає збігатися з реальністю. Проксі-контракти, обгортки над сторонніми бібліотеками, складені ланцюжки викликів через кілька контрактів — правила розсипаються на десятки окремих випадків.
Формальні методи закривають частину прогалини: вони доводять інваріанти, але потребують ручного опису специфікацій і погано переносяться на код, який змінюється щотижня.
AI-розбір коду знімає це обмеження інакше: модель навчається на розмітці знахідок — підтверджених і спростованих. Вона вчиться відрізняти спрацьовування, яке інженер закрив як хибне, від реального шляху до використання уразливості, і ранжує висновок за ймовірністю.
Швидкий первинний прохід за відомими класами дає Slither — модель доопрацьовує те, що в шаблон не вклалося.
На практиці зв'язка виглядає так: правила дають дешеве покриття відомих класів, формальні методи — доведення на критичних ділянках, модель знімає основне навантаження щодо хибних спрацьовувань.
Частка знахідок, які потрапляють у звіт без ручної повторної перевірки, зростає — саме вона визначає, скільки часу займає розбір перед випуском контракту.
Питання, які ставлять інженери перед стартом
Перед стартом інженери ставлять ті самі питання: де межа між автоматичним розбором і ручним аудитом, скільки шуму дає модель і як її висновок потрапить у конвеєр збірки.
Модель проходить контракт повністю, включно з гілками, до яких аудитор за обмежений час не доходить; людині залишаються економічні сценарії та перевірка критичних знахідок.
Скільки буде хибних спрацьовувань?
На першому прогоні поріг зміщено до повноти: краще зайва знахідка, ніж пропуск. Далі фільтр налаштовується на ваших контрактах, і кожне спрацьовування йде з фрагментом коду та рівнем упевненості.
Контракт уже розгорнуто — чи є сенс у перевірці?
Розбір іде за опублікованим кодом і байткодом: права власника, доступні функції, приймання зовнішніх викликів. Так видно, чим ризикує саме розгорнута версія.
Як перевіряти оновлювані контракти?
Розбір не разовий: нова реалізація проходить ті самі перевірки до публікації, між версіями порівнюються логіка та сховище. Інакше правка тихо відкриває те, що було закрито.
Куди передавати приватний код?
У публічні сервіси його викладати не потрібно: розбір в ізольованому контурі, доступ за ролями, результати залишаються у вас. Порядок роботи та видалення копій фіксуємо письмово.
Як вбудувати перевірку в конвеєр збірки?
Окремим кроком перед публікацією: запуск на зміни, машиночитний звіт, блокування випуску при знахідках вище заданого порогу.
Обговоримо задачу й повернемося з оцінкою та планом
Щоб оцінка проєкту спиралася на факти, а не на здогадки, для розмови достатньо кількох вхідних даних. Надсилати весь код заздалегідь не потрібно — важливо зрозуміти, як перевірка вбудована у ваш процес розробки та рев'ю.
- Перелік мереж і типів контрактів: токени, мости, протоколи кредитування — що саме потрібно перевіряти.
- Репозиторій або архів із прикладами — хоча б кілька контрактів у поточному стані.
- Класи уразливостей, критичні саме вам: повторне входження, помилки контролю доступу, переповнення.
- Як знахідки доходять до розробників: звіт, завдання в трекері, коментар до зміни коду.
- Обмеження щодо доступів: де живе код, що можна підключити до контуру збірки.
- Хто затверджує правила та розбирає хибні спрацьовування.
- Накопичені приклади знахідок і пропусків — за ними налаштовуємо чутливість.
У відповідь ви отримуєте схему контуру: де стоїть аналіз уразливостей, як він пов'язаний зі збіркою та перевіркою змін, де зберігаються результати і як вони потрапляють у задачі. Далі — план робіт за етапами з точками контролю та дата першого пробного прогону на ваших контрактах.
За підсумками прогону видно, яку частку знахідок підтверджують інженери і скільки йде в шум, — на цих числах і будується фінальна оцінка проєкту.
