Призначення чек-листа

Чек-лист призначений для систематичної перевірки безпеки програм на Solana перед деплоєм у mainnet, поданням на хакатон чи передачею зовнішньому аудитору. Він охоплює типові вразливості, специфічні для моделі облікових записів Solana та викликів між програмами (CPI — Cross-Program Invocation). Ресурс допомагає розробнику чи команді структурувати огляд коду, не пропустити критичні точки та зафіксувати результати кожного етапу.

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

Етапи перевірки

Аналіз входів та перевірка авторизації

  • Перевірка поля signer. Кожен обліковий запис, який ініціює зміну стану або переказ коштів, має бути позначений як signer. Якщо програма ігнорує цю перевірку, будь-хто зможе викликати інструкцію від чужого імені.
  • Валідація is_writable. Облікові записи, які програма не змінює, мають бути передані без прапорця writable. Це ускладнює атаки через підміну облікових записів.
  • Перевірка власника облікового запису (owner). Програма має переконуватися, що системні облікові записи (SystemProgram, TokenProgram, Clock тощо) належать відповідним програмам. Підміна owner — поширений вектор атаки.
  • Перевірка PDA (Program Derived Address). Усі PDA, які програма створює або використовує, мають бути виведені з коректних насінних значень (seeds). Збій у seeds призводить до створення передбачуваних адрес, які атакувальник зможе відтворити.
  • Авторизація через authority. Якщо інструкція вимагає прав адміністратора чи власника, переконайтеся, що authority збігається з очікуваним обліковим записом, а не з довільним signer.

Перевірка математичних операцій та переповнень

  • Цілісність (checked) арифметики. Усі додавання, віднімання та множення, пов'язані з балансами, кількістю токенів чи лічильниками, мають використовувати методи з суфіксом checked_ (наприклад, checked_add). Звичайні операції в Rust при переповненні загортаються мовчки, що може призвести до маніпуляцій з балансами.
  • Коректність округлення. При діленні переконайтеся, що округлення йде в бік протилежний до вигоди користувача (наприклад, при нарахуванні винагород — вниз, при стягненні комісій — вгору).
  • Перевірка на нуль. Ділення на нуль та множення на нуль у фінансовій логіці мають бути явно оброблені або виключені на етапі валідації вхідних даних.
  • Логіка комісій та зборів. Сума комісії не має перевищувати суму транзакції. Перевірте, чи обчислення відбувається до фактичного переказу, а не після.

Перевірка управління станом та власністю

  • Закриття облікових записів. При закритті (close) PDA-облікових записів переконайтеся, що lamports повертаються легітимному отримувачу, а не довільному адресу. Перевірте, що закритий обліковий запис не може бути повторно використаний у тій самій транзакції.
  • Ініціалізація стану. Кожен обліковий запис має ініціалізуватися лише один раз. Повторна ініціалізація дозволяє перезаписати стан і, зокрема, обійти обмеження на зміну власника.
  • Зміна власника токен-акаунта. Інструкції, які змінюють власника токен-акаунта, мають чітко перевіряти поточного власника. Відсутність перевірки дозволяє вивести кошти з чужого акаунта.
  • Перехідність стану. Перевірте, чи немає шляхів, які дозволяють перевести програму з одного стану в інший, минаючи обов'язкові проміжні кроки (наприклад, пропустити ескроу-етап і одразу завершити угоду).

Аудит зовнішніх викликів та CPI

  • Перевірка програми-отримувача CPI. У кожному виклику invoke або invoke_signed переконайтеся, що адреса програми, якій передається керування, є саме тією, яку ви очікуєте (SystemProgram, TokenProgram, власна програма). Виклик довільної програми через підмінений обліковий запис — критична вразливість.
  • Передача signer-привілеїв через CPI. Виклик invoke_signed передає PDA-підписи дочірній програмі. Переконайтеся, що передаються лише ті привілеї, які необхідні, і що дочірня програма є довіреною.
  • Обробка помилок CPI. Помилки, повернуті дочірньою програмою, мають оброблятися явно. Ігнорування помилки може призвести до того, що стан програми вважатиметься успішно оновленим, хоча токенний переказ не відбувся.
  • Реентерантність. Хоча модель Solana ускладнює класичну реентерантність, перевірте, чи немає циклічних CPI між вашими програмами, які можуть призвести до зависання транзакції або перевищення ліміту обчислень.
  • Аналіз переданих облікових записів у CPI. Переконайтеся, що до дочірньої програми не потрапляють облікові записи, які користувач не мав би передавати безпосередньо.

Критерії завершення перевірки

Security review вважається завершеним за таких умов:

  • Кожен пункт чек-листа має один із трьох статусів: пройдено, виявлено проблема або не застосовується (з обов'язковим обґрунтуванням).
  • Усі пункти зі статусом «виявлено проблему» мають зафіксований опис вразливості, ступінь критичності (critical / high / medium / low / informational) та посилання на конкретний рядок коду.
  • Для кожної виявленої проблеми запропоновано виправлення або прийнято усвідомлене рішення про прийняття ризику (з фіксацією причин).
  • Перевірено всі інструкції програми, включно з допоміжними та адміністративними, а не лише основний користувацький шлях.
  • Результати перевірки зафіксовані в письмовому вигляді (звіт, issue-трекер, коміті у репозиторії) і доступні всім членам команди.

Обмеження чек-листа

  • Чек-лист охоплює типові вразливості програм на Solana, але не гарантує виявлення нетипових або складних ланцюгових атак, де експлуатація поєднує кілька слабких місць.
  • Він не замінює формальний аудит безпеки, проведений спеціалізованою компанією чи незалежним аудитором.
  • Чек-лист не охоплює інфраструктурну безпеку: налаштування RPC-вузлів, управління ключами розгортання, безпеку фронтенду та захист від фішингу.
  • Він не враховує специфіку сторонніх бібліотек та crate-залежностей — їхню безпеку треба перевіряти окремо.
  • Економічні моделі (механіки токеноміки, стимули, MEV-вектори) виходять за межі цього чек-листа і потребують окремого економічного аудиту.

Версія ресурсу

Ресурс «Чек-лист security review програми»: статична версія 1.0. Сторінка містить готовий текстовий чек-лист і готова до практичного використання без очікування окремого інтерактивного інструмента. Остання редакційна перевірка: 2 серпня 2026 року.

Джерела