Роздуми про напад на Cetus: рівень захисту безпеки завдяки аудиту коду

Нещодавно децентралізована біржа Cetus в екосистемі SUI зазнала атаки, що викликало обговорення ефективності аудиту безпеки коду в галузі. У цій статті буде зроблено огляд аудиту коду Cetus та досліджено фактичний вплив аудиту коду на безпеку проєкту.

Огляд аудиту коду Cetus

Cetus приймав аудити коду від кількох організацій, включаючи MoveBit, OtterSec та професійні аудиторські компанії Move мови, такі як Zellic. Результати аудиту від різних організацій наведені нижче:

1. Звіт аудитора MoveBit:

   • Виявлено 18 ризикових проблем, з яких 1 є фатальним ризиком, 2 - основними ризиками, 3 - помірними ризиками та 12 - незначними ризиками.
   • Усі питання вирішено

2. Звіт аудиту OtterSec:

   • Виявлено 1 високо ризиковану проблему, 1 проблему середнього ризику та 7 інформаційних ризиків
   • Високі та помірні ризикові питання вирішено, частина інформаційних ризиків все ще існує

3. Звіт про аудит Zellic:

   • Виявлено 3 інформаційні ризики, які в основному стосуються нормативності коду, але не становлять суттєвої загрози безпеці.

Попри те, що Cetus пройшов багатоетапний аудит і усунув більшість високих ризиків, він все ж став жертвою атаки. Ця подія підкреслює, що навіть проекти, які були перевірені кількома установами, можуть мати проблеми з безпекою.

Обмеження аудиту коду

1. Аудит не може гарантувати 100% безпеку: навіть після кількох раундів аудиту можуть залишатися не виявлені вразливості.

2. Швидка ітерація технологічних оновлень: нові методи атак постійно з'являються, аудит може не встигнути охопити всі потенційні ризики.

3. Складність взаємодії контрактів: проекти DeFi зазвичай передбачають складну взаємодію між кількома контрактами, що ускладнює всебічний аудит.

4. Якість аудиту варіюється: професійний рівень та глибина аудиту можуть відрізнятися у різних аудиторських установ.

Рекомендації щодо підвищення безпеки проекту

1. Множинний аудит: обрати кілька професійних аудиторських організацій для проведення аудиту, особливо спеціалізованих установ для певних публічних блокчейнів (наприклад, мова Move).

2. Постійний аудит: Регулярно проводити аудити безпеки, слідкуючи за останніми загрозами безпеці.

3. Програма винагороди за вразливості: встановлення високих винагород, щоб заохотити білих хакерів виявляти та повідомляти про потенційні вразливості.

4. Конкурс аудитів: проведення конкурсу аудитів для залучення більшої кількості фахівців з безпеки до аудиту проекту.

5. Відкритий код: дозволяє спільноті перевіряти код, збільшуючи прозорість.

6. Тестування безпеки: провести всебічне тестування безпеки, включаючи імітацію атак та стрес-тестування.

7. Страховий механізм: розглянути можливість придбання страхування для активів користувачів, щоб надати додатковий захист.

Заключення

Інцидент з атакою на Cetus ще раз нагадує нам, що хоча аудит коду важливий, він не є єдиним гарантом безпеки. Команді проекту потрібно вжити всебічних заходів безпеки, включаючи багаторазові аудити, постійні оцінки безпеки, програми винагород за вразливості тощо. Водночас користувачі, беручи участь у DeFi проектах, також повинні залишатися обережними, звертаючи увагу на заходи безпеки та можливості контролю ризиків проекту. Лише спільна увага проектної команди та користувачів до безпеки може створити більш безпечну та надійну екосистему блокчейну.