Звіт про безпеку DeFi протоколу виявляє слабкі місця в управлінні ризиками та закликає виховувати свідомість фінансових інженерів

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

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

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

Це виявило кілька ключових проблем:

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

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

3. Чому багаторазовий аудит безпеки все ще не виявив проблем заздалегідь? Це відображає поширене непорозуміння: проєктні команди надмірно покладаються на аудит безпеки, розглядаючи його як золотий сертифікат звільнення від відповідальності. Однак інженери з аудиту безпеки зосереджуються на виявленні вразливостей у коді, їм важко передбачити, що система може породити такі нерозумні обмінні курси.

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

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

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

Зі зростанням зрілості галузі технологічні вразливості на рівні коду поступово зменшаться, а "свідомі вразливості" бізнес-логіки з нечіткими межами та розмитими обов'язками стануть найбільшою проблемою. Аудиторські компанії можуть забезпечити відсутність вразливостей у коді, але реалізація "логічних меж" потребує від команди проекту більш глибокого розуміння та контролю над сутністю бізнесу.

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