Большинство основателей считают, что безопасность — это просто защита смарт-контракта. Но вот некоторые распространённые мифы и реальность, которые должен понять каждый основатель. > Миф: Как только мы прошли аудит, мы безопасны. Реальность: По моему мнению, это одно из самых больших заблуждений в Web3. Аудит — это не сертификат безопасности, а проверка вашего кода на определённый момент времени. С момента, как вы запускаете новую функцию, интегрируете другой протокол, обновляете оракул или меняете инфраструктуру бэкенда, ваш профиль рисков меняется. Аудит помогает снизить риски, но каждое последующее обновление требует такого же уровня внимания. > Миф: Хакеры эксплуатируют только смарт-контракты. Реальность: Я больше не думаю, что это правда. За последние несколько лет мы видели, что самые крупные потери возникали не из-за ошибок в Solidity — они происходили из-за скомпрометированных приватных ключей, фишинга, сбоев в контроле доступа, инфраструктуре бэкенда, подписчиков оракулов и операционных ошибок. Ваш фронтенд, API, конвейер развертывания, кошельки и инфраструктура — всё это часть вашей атакуемой поверхности. По моему мнению, основателям нужно думать шире, чем просто смарт-контракт. Ваша инфраструктура, ключи и операционные процессы важны не меньше. > Миф: Мы слишком малы, чтобы быть целью. Реальность: Злоумышленники обычно не интересуются, сколько подписчиков у вашего проекта. Их интересует одно: можно ли извлечь из него ценность. Если ваш протокол хранит активы или имеет пользователей — вы уже интересны кому-то. Ждать, пока вы станете достаточно крупным, чтобы инвестировать в безопасность — часто уже слишком поздно. > Миф: Одного надёжного подписчика или админ-ключа достаточно. Реальность: По моему мнению, каждый привилегированный ключ следует рассматривать как казну проекта. Ключи оракулов, ключи развертывания, ключи обновления, мультиподписчики, учётные данные бэкенда — каждый из них может стать единой точкой отказа. Один скомпрометированный ключ может поставить под угрозу весь протокол. > Миф: Мы улучшим безопасность после запуска. Реальность: Злоумышленники не будут ждать этого момента. Основатели часто думают, что безопасность можно добавить позже, в следующих итерациях. К сожалению, эксплойты не подчиняются срокам разработки продукта. Лучшее время для внедрения мониторинга, реагирования на инциденты и операционной безопасности — до того, как пользователи доверят вам свои активы. > Миф: Внутреннего тестирования достаточно. Реальность: Ваша команда знает, как протокол должен работать. Внешний исследователь думает о том, как он может сломаться. Вот почему аудиты, конкурентные обзоры, баг-баунти и непрерывное тестирование играют разные роли. Безопасность выигрывает от свежих взглядов. > Миф: Открытый исходный код означает, что кто-то найдёт баги. Реальность: Открытый исходный код повышает прозрачность. Он не гарантирует, что кто-то проверит каждую строку кода или ответственно сообщит о каждой уязвимости. Публикация кода — это не то же самое, что его проверка. > Миф: Безопасность — это ответственность аудитора. Реальность: Это, пожалуй, самое важное изменение мышления, которое должны принять основатели. Аудиторы помогают снижать риски. Но безопасность создаётся всеми: основателями при принятии продуктовых решений, разработчиками при написании кода, командами DevOps при управлении инфраструктурой и операционными командами при защите доступа. Я всегда считал, что безопасность — это не то, что можно завершить; это то, что нужно постоянно улучшать. Итог: Ландшафт безопасности изменился. И я считаю, что наше отношение к безопасности должно измениться вместе с ним. Больше недостаточно сосредотачиваться только на смарт-контрактах. Как основателям, нам нужно думать о защите всего протокола — от контрактов и инфраструктуры до ключей, контроля доступа и всех систем, которые поддерживают работу протокола.