Більшість засновників вважають, що безпека — це просто забезпечення смартконтракту. Але ось кілька поширених міфів проти реальності, які повинен розуміти кожен засновник. > Міф: Після того як ми пройшли аудит, ми безпечні. Реальність: За моїми даними, це один із найбільших заблуджень у Web3. Аудит — це не сертифікат безпеки, а огляд вашого коду на певний момент часу. Момент, коли ви запускаєте нову функцію, інтегруєте інший протокол, оновлюєте оракула або змінюєте інфраструктуру бекенду, — це змінює ваш профіль ризиків. Аудит допомагає зменшити ризики, але кожне оновлення після нього вимагає такого ж рівня уваги. > Міф: Хакери експлуатують лише смартконтракти. Реальність: Я більше не вважаю це правдою. За останні кілька років ми бачили, що найбільші втрати виникли не через баги Solidity, а через скомпрометовані приватні ключі, фішинг, невдачі контролю доступу, інфраструктуру бекенду, підписувачів оракулів та операційні помилки. Ваш фронтенд, API, конвеєр розгортання, гаманці та інфраструктура — усе це частина вашої поверхні атаки. За моїм переконанням, засновникам потрібно думати далі за межі смартконтракту. Ваша інфраструктура, ключі та операційні процеси мають таку ж важливість. > Міф: Нас замало, щоб бути мішенню. Реальність: Зловмисники зазвичай не цікавляться тим, скільки підписників має ваш проект. Їх цікавить одне: чи можна отримати з цього цінність. Якщо ваш протокол зберігає активи або має користувачів — ви вже цікаві для когось. Чекати, поки ви станете достатньо великими, щоб інвестувати у безпеку — часто занадто пізно. > Міф: Одного довіреного підписувача або адмін-ключа достатньо. Реальність: За моїм переконанням, кожен привілейований ключ слід розглядати як ваш скарбницю. Ключі оракулів, ключі розгортання, ключі оновлення, підписувачі мультисигу, облікові дані бекенду — кожен з них може стати єдиною точкою вади. Один скомпрометований обліковий запис може поставити під загрозу весь протокол. > Міф: Ми покращимо безпеку після запуску. Реальність: Зловмисники не будуть чекати до цього моменту. Засновники часто вважають, що безпеку можна додати пізніше, у наступних ітераціях. На жаль, експлуатації не дотримуються розкладу продукту. Найкращий час для створення моніторингу, реагування на інциденти та операційної безпеки — до того, як користувачі довірятимуть вам свої активи. > Міф: Внутрішнє тестування достатнє. Реальність: Ваша команда знає, як протокол має працювати. Зовнішній дослідник думає про те, як він може зламатися. Саме тому аудити, конкурентні огляди, програми баг-баунтів та постійне тестування виконують різні ролі. Безпека користується з нових перспектив. > Міф: Відкрите джерело означає, що хтось знайде баги. Реальність: Відкрите джерело покращує прозорість. Це не гарантує, що хтось перевірить кожен рядок коду чи повідомить про кожну вразливість відповідально. Публікація коду — це не те саме, що його перевірка. > Міф: Безпека — це відповідальність аудитора. Реальність: Це, мабуть, найважливіша зміна мислення, яку повиннi зробити засновники. Аудитори допомагають зменшити ризики. Але безпеку створюють всі: засновники, що приймають рішення щодо продукту; розробники, що пишуть код; команди DevOps, що керують інфраструктурою; та операційнi команди, що захищають доступ. Я завжди вважав, що безпека — це не те, що можна завершити; це те, що потрiбно постiйно покращувати. Остаточний висновок: Ландшафт безпеки змiнився. І я вважаю, що наше ставлення до безпеки також має змiнитися. Бiльше недостатньо зосереджуватися лише на смартконтрактах. Як засновники, ми повиннi думати про захист усього протоколу — вiд контрактiв та інфраструктури до ключiв, контролю доступу та кожної системи, що забезпечує роботу протоколу.