Як читати публічний звіт аудиту без глибокої експертизи

З чого починаємо перевірку безпеки

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

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

Логіка роботи

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

Типова структура звіту

1. Вступ із описом обсягу. Що саме перевіряли: який контракт, яка версія, які функції входили до перевірки, а які — ні.
2. Методологія. Які інструменти й підходи використовували. Цей розділ корисний для фахівців, користувачеві достатньо переконатися, що методологія вказана.
3. Знайдені проблеми (findings). Основна частина. Кожна проблема описана за шаблоном: суть — рівень критичності — реакція команди — статус виправлення.
4. Підсумок. Загальна оцінка аудиторів.

Рівні критичності проблем

У більшості звітів проблеми поділені на рівні. Назви можуть відрізнятися, але логіка загалом однакова:

• Критичний (Critical / High). Проблема, яка може призвести до втрати коштів або повної зупинки роботи контракту. Навіть один невиправлений критичний рівень — це серйозний сигнал.
• Середній (Medium). Проблема, яка не призводить до прямої втрати коштів, але може порушити логіку роботи або створити умови для атаки в поєднанні з іншими вразливостями.
• Низький (Low / Informational). Рекомендації щодо покращення коду, стилю або ефективності. Вони не становлять прямої загрози.

Статуси виправлення

Це найважливіше поле для користувача без технічної експертизи. Побачивши проблему, одразу шукайте статус:

• Fixed / resolved. Зазвичай означає, що команда внесла зміни щодо знахідки, але точний статус треба читати за легендою конкретного звіту: різні аудитори використовують різні позначення й процедури повторної перевірки.
• Acknowledged (прийнято до відома). Команда погоджується, що проблема існує, але не виправляє її. Тут важливо розуміти причину: іноді це свідомий компроміс, іноді — ігнорування.
• Out of scope (поза обсягом). Компонент або клас перевірок не входив до погодженого обсягу аудиту. Це не означає, що там обов’язково є проблема; означає лише, що цей звіт не дає підстав робити висновок про цю частину системи.
• Not fixed / Won't fix (не виправлено). Проблема зафіксована й залишається.

На які дані спиратися

Читаючи звіт, розділяйте три речі: що перевіряли аудитори, як команда відреагувала на знахідки і який ризик із цього випливає для вашого сценарію. Сам звіт не зобов’язаний містити готову користувацьку оцінку.

Хто написав звіт

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

Критерій перевірки: знайдіть автора звіту та спробуйте підтвердити сам документ через офіційний сайт, репозиторій або інший канал аудитора. Відсутність публічного каталогу всіх робіт сама по собі нічого не доводить; важливо, чи можна встановити походження конкретного звіту й його незмінність.

Хто замовив аудит

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

Чи опубліковано звіт на сторонньому майданчику

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

Що залежить від контексту

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

Що перевіряти після читання звіту

1. Дату завершення аудиту. Зафіксуйте цю дату.
2. Дату останнього оновлення коду продукту. Якщо код оновлювався після аудиту — звіт описує попередню версію.
3. Наявність інших перевірок. Додатковий аудит може покрити іншу версію або іншу частину системи. Важливі не кількість логотипів, а обсяг, дата, версія коду й статус знайдених проблем.
4. Кількість невиправлених проблем критичного рівня. Якщо є хоча б одна — це прямий сигнал для обережності.

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

• Не вважати наявність аудиту гарантією безпеки. Аудит перевіряє код у визначеному обсязі, а не весь продукт повністю.
• Не робити висновків лише за підсумковою оцінкою. Іноді загальна оцінка може бути позитивною, але в тексті залишаються невиправлені проблеми середнього рівня.
• Не ігнорувати розділ «out of scope». Якщо ключова функція продукту була поза обсягом аудиту — це важлива інформація для вашого рішення.
• Не приймати рішення про використання продукту лише на основі одного звіту.

Типові помилки при читанні

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

Підсумок і спосіб перевірки

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

Порядок пріоритетів при прийнятті рішення:

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

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

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

Більше матеріалів про безпеку в екосистемі Solana доступно в розділі Безпека Solana: спокійно, конкретно, перевірено. Загальний огляд продуктів — у розділі Продукти Solana: що працює для людей.

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