Чому старий аудит не завжди описує поточну версію продукту

Наявність аудиту не означає, що поточна версія продукту перевірена. Аудит — це знімок конкретного стану коду на певний момент. Якщо після аудиту код змінився, висновки стосуються попередньої версії, а не тієї, яку ви використовуєте зараз. Це базове обмеження, яке варто враховувати перед будь-якою дією з гаманцем, застосунком або смартконтрактом.

Що саме потрібно перевірити

Головна теза: аудит описує лише ту версію коду, яка була передана аудиторам. Будь-яка зміна після цього моменту виходить за межі висновків аудиту.

Межа цього матеріалу: тут пояснюється, чому виникає ця розбіжність і як її розпізнати. Цей текст не замінює інструкцію з читання звіту аудиту і не охоплює загальну підготовку пристрою до роботи з фінансовими застосунками. Ці теми розкриті в окремих матеріалах.

Якщо вам потрібен загальний огляд підходів до безпеки в екосистемі, почніть із розділу Безпека Solana: спокійно, конкретно, перевірено. Загальне пояснення, що таке аудит смартконтракту й чим він відрізняється від безпеки продукту загалом, доступне за посиланням Аудит смартконтракту й безпека продукту.

Як це працює в системі

Процес аудиту зазвичай виглядає так:

1. Команда продукту фіксує версію коду.
2. Передає цю версію аудиторській компанії або незалежному аудитору.
3. Аудитори аналізують код, знаходять вразливості, готують звіт.
4. Команда продукту отримує звіт, виправляє знайдені проблеми (або ні).
5. Опублікований звіт містить висновки щодо тієї версії, яка була на кроці 1.

Після публікації звіту розробка не зупиняється. Продукт оновлюється: додаються функції, змінюється логіка, оновлюються залежності, виправляються помилки. Кожна з цих змін створює нову версію коду, яка не була частиною аудиту.

Типові причини розбіжності між аудитом і поточною версією:

• Функціональні оновлення. Додано нові можливості, нові шляхи взаємодії зі смартконтрактом або нові екрани в застосунку. Новий код не перевірено.
• Виправлення помилок. Навіть виправлення може внести нову вразливість, якщо змінена логіка взаємодіє з іншими частинами системи.
• Оновлення залежностей. Зміна версій бібліотек, фреймворків або інструментів збирання може змінити поведінку коду без видимих змін у самому продукті.
• Зміна конфігурації. Нові адреси контрактів, змінені параметри, оновлені RPC-ендпоінти — все це виходить за межі перевіреного стану.
• Рефакторинг. Код переписано без зміни функціональності, але структура змінилася. Такі зміни також не охоплені попереднім аудитом.

Як розпізнати, що аудит може не відповідати поточній версії

Критерії, які вказують на можливу розбіжність:

• У звіті вказана версія або коміт, але ви не можете знайти цю інформацію в публічному репозиторії продукту.
• Звіт опублікований значно раніше за останнє оновлення продукту.
• Функції, описані в поточному інтерфейсі продукту, не згадані в звіті аудиту.
• У звіті є розділ «виправлення», але немає підтвердження, що саме ці виправлення застосовано без додаткових змін.

Жоден із цих критеріїв не є підтвердженням компрометації. Це лише підозра на розбіжність, яка потребує перевірки.

Що можна перевірити

Щоб визначити, чи описує аудит поточну версію, потрібні три елементи:

1. Ідентифікатор перевіреної версії. Це може бути хеш коміту, тег релізу, номер версії або посилання на конкретну гілку в репозиторії.
2. Ідентифікатор поточної версії. Те саме, але для стану коду на цей момент.
3. Можливість порівняння. Доступ до історії змін між цими двома точками.

Позиція аудиторської компанії зазвичай полягає в тому, що їхній висновок стосується виключно переданого їм стану. Це стандартна практика, і вона не є недоліком аудиту — це його властивість.

Позиція команди продукту може різнитися. Деякі команди публікують звіти з чітким зазначенням версії і супроводжують кожен реліз оновленим аудитом або принаймні описом змін. Інші посилаються на старий звіт без уточнень. Відсутність уточнень — це сигнал для додаткової перевірки, а не підтвердження проблеми.

Щоб перевірити відповідність самостійно, скористайтеся матеріалом Як читати публічний звіт аудиту без глибокої експертизи.

Ризики та межі висновку

Повний аудит кожної зміни — це ресурсомісткий процес. Він вимагає часу та коштів, які не кожна команда може виділити. Тому на практиці існують компроміси:

• Аудит лише критичних змін. Команда замовляє перевірку не кожного релізу, а лише тих, які суттєво змінюють логіку управління коштами.
• Внутрішній рев’ю замість зовнішнього аудиту. Зміни перевіряє власна команда, що не замінює незалежний аудит, але знижує ризик.
• Автоматизовані інструменти. Лінтери, статичні аналізатори та тести запускаються автоматично, але вони виявляють лише відомі класи вразливостей.

Невизначеність залишається завжди. Навіть свіжий аудит не гарантує повної відсутності вразливостей. Коректний висновок вужчий: звіт документує обсяг, методику та результати перевірки певного стану коду; те, що не входило в scope або не було виявлено, залишається поза таким висновком.

Безпечна дія: як перевірити відповідність аудиту поточній версії

Кроки для самостійної перевірки:

1. Знайдіть у звіті ідентифікатор версії. Шукайте хеш коміту, тег або номер версії. Якщо його немає — це перша ознака обмеженої корисності звіту.
2. Знайдіть поточну версію продукту. Перевірте репозиторій, релізи або документацію.
3. Порівняйте ідентифікатори. Якщо ідентифікатори збігаються, звіт, імовірно, стосується цього стану коду; додатково перевірте scope, конфігурацію та чи не відрізняється фактичне розгортання. Якщо не збігаються — потрібно оцінити обсяг змін.
4. Перевірте наявність додаткових аудитів. Якщо між старим аудитом і поточною версією були інші перевірки, їхні висновки можуть покрити частину змін.
5. Оцініть характер змін. Якщо зміни стосуються інтерфейсу, а не логіки управління коштами, ризик нижчий. Якщо змінено логіку транзакцій, дозволів або доступів — ризик вищий.

Очікуваний результат: ви розумієте, чи описує аудит поточну версію, і якщо ні — які саме частини коду залишилися неперевіреними.

Чого не робити

• Не вважайте наявність аудиту автоматичною гарантією безпеки поточної версії.
• Не робіть висновків про відсутність вразливостей лише на основі старого звіту.
• Не передавайте нікому свої секретні ключі, seed-фразу або паролі навіть «для перевірки».
• Не виконуйте команди терміналу з неперевірених джерел, якщо не розумієте кожну з них.
• Не сприймайте сам факт аудиту як гарантію безпеки: звіт описує певну версію, обсяг перевірки та відомі на той момент знахідки. Після інциденту важливіше встановити технічну причину й актуальний статус, ніж робити висновок лише з наявності старого аудиту.

Практичний висновок

Старий аудит — це корисний, але обмежений інструмент. Він показує, що на певний момент певна версія коду пройшла перевірку. Усе, що змінилося після цього, потребує окремої оцінки. Практична користь: перед прийняттям рішення про використання продукту перевірте, чи відповідає опублікований аудит тій версії, яку ви збираєтеся використовувати.

Якщо ви не можете встановити відповідність або зміни стосуються критичної логіки, розгляньте такі варіанти:

• Зупиніть використання продукту до отримання додаткової інформації.
• Зверніться до незалежного фахівця з безпеки для експертної перевірки.
• Якщо потрібна альтернатива, перевіряйте не лише наявність аудиту, а його дату, охоплену версію коду, scope, невиправлені знахідки та поточну документацію конкретного продукту.

Якщо ви плануєте встановлювати або оновлювати гаманець чи фінансовий застосунок, наступний логічний крок — переконатися, що ваш пристрій готовий до цього. Це окрема тема, яка не розкривається в цьому матеріалі.

Редакція солана.укр