Mono Audit logo

Роудмэп безопасности для Web3 проектов

Дорожная карта безопасности для Web3 протокола - это стратегический документ, который помогает командам на протяжении всего жизненного цикла протокола планировать и выполнять задачи связанные с безопасностью.

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

Дорожная карта развивается вместе с продуктом и отражает как запланированные, так и выполненные действия, направленные на повышение безопасности протокола.

 

Этапы жизненного цикла

Этапы жизненного цикла

Дорожная карта охватывает все этапы жизни протокола, от идеи до обслуживания после запуска.

Она делит действия, связанные с безопасностью, на четыре этапа: планирование, разработка, пред-релиз и после развертывания.

Этап планирования начинается, когда фаундеры принимают решение о запуске протокола. Именно здесь начинается основная работа, даже если написание кода еще не началось.

Этап разработки начинается, когда инженеры приступают к написанию кода, и может продолжаться циклами на протяжении всего срока жизни протокола, особенно при частых обновлениях.

Этап пред-релиза наступает после завершения этапа разработки, но до непосредственного запуска. Это рискованный период: команды часто находятся под давлением, чтобы запустить продукт, но спешка может иметь катастрофические последствия. Этот этап должен быть сосредоточен на проверке готовности к безопасному релизу и устранении любых критических проблем.

Этап после развертывания включает рутинные операции, такие как мониторинг, обновления и миграции, поддерживающие долгосрочную стабильность протокола.

 

Обязательность пунктов дорожной карты

Дорожная карта использует три уровня обязательности.

Обязательные действия являются не подлежащими обсуждению для любого протокола, ориентированного на безопасность.

Желательные действия могут применяться не во всех случаях, но должны считаться необходимыми, когда это уместно.

Необязательные действия могут быть пропущены командой в зависимости от контекста, хотя их реализация может добавить дополнительный уровень защиты.

 

Публикация дорожной карты

Обнародование Дорожной карты безопасности позволяет команде завоевывать доверие пользователей, четко сообщая о своей стратегии безопасности.

Ранние версии Дорожной карты будут описывать только намерения. По мере развития разработки пункты плана безопасности будут превращаться из деклараций в констатацию фактов.

По мере развития протокола Дорожная карта должна поддерживаться как репозиторий с контролем версий и историей изменений, что позволит пользователям и участникам легко отслеживать прогресс и понимать состояние безопасности протокола.

 

Web3 Security Roadmap

 

Планирование

Логика протокола

Документация

Важно документировать основную логику протокола на ранней стадии планирования.

Будь то в форме whitepaper или интерактивной документации, это помогает членам команды согласовать детали реализации, служит надежным справочником для аудиторов и дает пользователям четкий обзор предполагаемой функциональности протокола.

Эта документация должна быть общедоступной и поддерживаться в актуальном состоянии.

Моделирование угроз

Моделирование угроз должно начинаться после определения архитектуры протокола, но до начала этапа разработки.

Это включает в себя анализ движения средств и данных через протокол, анализ зависимостей и выявление потенциальных векторов атак.

Полученный документ должен описывать риски, их потенциальные последствия и стратегии предотвращения.

Если моделирование угроз выявляет критические недостатки, логика протокола должна быть пересмотрена.

Публикация этой информации демонстрирует приверженность команды проактивной безопасности.

 

Разработка

Смарт контракты

Надежный фреймворк

После начала разработки команда должна принять решение по выбору современного, широко распространенного фреймворка для смарт контрактов.

Это решение упрощает внутренние рабочие процессы и облегчает сообществу, аудиторам и контрибьюторам взаимодействие с кодовой базой.

Такие фреймворки обычно предлагают интеграцию с линтерами и плагинами.

Автоматизированные тесты

Тестирование является фундаментальным требованием на этапе разработки.

Написание модульных тестов, интеграционных тестов и, где применимо, фаззинг-тестов гарантирует надежность кодовой базы.

Хорошо интегрированный CI-конвейер должен автоматически запускать эти тесты после каждого изменения, предотвращая слияние сломанного кода.

Прозрачность в отношении покрытия тестов и их результатов повышает доверие пользователей.

Лучшие практики

Соблюдение установленных лучших практик в разработке и безопасности смарт контрактов помогает командам избежать распространенных ошибок.

Включая эти практики в разработку через фреймворки и CI-автоматизацию, команды закладывают прочную основу для безопасности протокола.

Документация для разработчиков

Поддержание актуальной документации для разработчиков служит как внутренним целям передачи знаний, так и коммуникации с внешними пользователями.

По мере обновления команды документация обеспечивает преемственность.

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

Инкрементный аудит безопасности

Традиционные аудиты предоставляют слепок безопасности в определенный момент времени, но инкрементный аудит непрерывно следует за процессом разработки.

Такой аудит начинаются с первого коммита кода и отслеживает уязвимости по мере развития кода.

Каждый раз, когда добавляется новый код, аудитор фокусируется только на последних изменениях.

Этот подход сокращает цикл обратной связи, помогает разработчикам быстрее устранять проблемы и снижает нагрузку на специалистов по безопасности.

Бэкенд и фронтенд

Менеджмент ключей

Безопасность не ограничивается смарт контрактами.

Любые внутренние или внешние системы требуют осторожного обращения, особенно при работе с ключами горячих кошельков или административными привилегиями.

Утечки ключей остаются основной причиной взломов протоколов, поэтому команды должны полагаться на проверенные решения для управления секретами.

CI-конвейеры для безопасности

В дополнение к базовым CI-конвейерам для тестирования, интеграция инструментов, которые сканируют зависимости на наличие уязвимостей, может защитить от атак на цепочки поставок.

Эти инструменты помогают выявлять устаревшие или уязвимые пакеты во время процесса сборки и могут быть автоматизированы как часть рабочих процессов CI/CD.

Команда

Верификация команды

Необходимо учитывать человеческий фактор.

Угрозы со стороны инсайдеров реальны, особенно в проектах с высокой капитализацией.

Команды должны использовать систему доступа на основе ролей для минимизации риска.

Услуга верификации команды поможет выявить подозрительных лиц или ограничить их действия вовремя.

Публичное раскрытие членов команды и участников также может укрепить доверие пользователей.

 

Пред-релиз

Исходный код

Открытый исходный код и верификация смарт контрактов

По мере приближения продукта к запуску важно сделать исходный код открытым и верифицировать смарт контракты.

В Web3 закрытый исходный код скорее является красным флагом, чем мерой безопасности.

Злоумышленники все еще могут анализировать байт-код, в то время как прозрачность поощряет сообщество вносить свой вклад в безопасность.

Предварительный аудит

Предварительный аудит - это упрощенный процесс, предназначенный для выявления проблем до формального аудита.

Он заблаговременно выявляет отсутствующую документацию, неудачные тесты и неработающие контракты, экономя время и деньги на этапе полного аудита.

Аудит безопасности

Полный аудит остается краеугольным камнем безопасности Web3.

Хотя он не гарантирует абсолютную безопасность, профессиональный обзор значительно снижает риск деплоя с явными уязвимостями.

Явное раскрытие неустраненных уязвимостей

После аудита решение не исправлять какую-либо из выявленные уязвимостей должно быть публично объяснено, включая обоснование и любые потенциальные последствия.

Аудит токеномики

По мере усложнения протоколов становится все труднее понимать их экономическую модель.

Аудиты, ориентированные на бизнес-логику, становятся все более важными, особенно для выявления ошибок во взаимосвязанных системах или токеномике.

Эти аудиты устраняют проблемы, которые могут быть пропущены базовыми аудитами смарт контрактов.

Формальная верификация

Формальная верификация, хотя и ресурсоемкая и дорогая, может обеспечить математическую достоверность критических частей логики протокола.

Она уменьшает влияние человеческого фактора при аудите безопасности, что делает ее мощным инструментом при выборочном применении к наиболее чувствительным компонентам.

Документация

Пользовательская документация

Пользовательская документация помогает не только конечным пользователям.

Для разработчиков и аудиторов этот уровень документации заполняет пробел между технической реализацией и фактической функциональностью.

Она способствует созданию точных ментальных моделей, особенно когда код является абстрактным или низкоуровневым.

Публикация точек доверия

Четкое изложение точек доверия, лежащих в основе вашего протокола, является еще одним признаком зрелости.

От зависимости от сторонних контрактов до мультиподписей и административных разрешений, пользователи должны знать, что находится вне вашего прямого контроля.

Это включает внутреннюю инфраструктуру, кошельки или оффчейн-системы, участвующие в экосистеме протокола.

Публикация Дорожной карты безопасности и ее статуса

Публикация самой Дорожной карты безопасности, наряду с ее статусом, гарантирует, что пользователи могут увидеть намерения команды по усилению безопасности и отслеживать их прогресс.

Она должна быть представлена ​​явно и включать ссылки на аудиты, дашборды и другие материалы, связанные с безопасностью.

Тестовая сеть

Полное развертывание

Развертывание полной версии протокола в тестовой сети предоставляет возможность отрепетировать сам процесс развертывания и протестировать функции протокола в безопасной среде.

Тестнет версия должна использовать те же интерфейсы, что и мэйннет, для имитации реального пользовательского опыта.

Тестирование интеграций и симуляция инцидентов

На тестнете также можно проводить интеграционное тестирование и упражнения по реагированию на инциденты.

Стресс-тест

Тестовые сети также могут поддерживать маркетинг и помогать в получении обратной связи от пользователей.

Стимулируя пользователей к использованию тестовой сети, команды могут выявлять проблемы с юзабилити и производительностью при реалистичных условиях нагрузки, одновременно выстраивая коммуникацию с сообществом.

Подготовка к инциденту

План реагирования на инцидент

Даже если ваш протокол кажется абсолютно безопасным, наличие плана реагирования на инциденты является необходимым.

Этот план должен подробно описывать роли, протоколы коммуникации, процедуры аварийного отключения, координацию с правоохранительными органами и экспертами по безопасности, а также другие критически важные задачи реагирования.

Он должен регулярно пересматриваться и должны проводиться регулярные учения.

Соглашения с внешними экспертами по экстренному реагированию

Партнерство с внешней командой безопасности для реагирования на инциденты заранее может сэкономить драгоценные минуты при возникновении инцидента.

Публичное раскрытие этого партнерства показывает, что вы серьезно относитесь к безопасности.

Страхование убытков

Интеграция с децентрализованными протоколами страхования может предоставить пользователям возможность защитить свои средства.

Эти услуги позволяют пользователям разделять риски и создавать дополнительную подушку безопасности, что положительно отражается на приверженности вашего проекта безопасности пользователей.

 

После развертывания

Обслуживание

Мониторинг блокчейна

Постоянный мониторинг активности в блокчейне становится передовой линией защиты.

Внезапные аномалии должны инициировать оповещения, чтобы ваша команда могла быстро отреагировать и предотвратить ущерб.

Своевременно выявленная попытка атаки может быть остановлена ​​активацией аварийного протокола.

Bug Bounty

Запуск публичной программы Bug Bounty приглашает этичных хакеров тестировать ваш протокол.

Благодаря понятной процедуре для сообщения о находке и значительным вознаграждениям эти программы привлекают внимание хакеров и поощряют раскрытие информации о найденных уязвимостях вместо их эксплуатации.

Миграции

Учебные миграции в тестовой сети

Тестовые сети также активно используются после запуска.

Тестирование сценариев миграции и новых развертываний в тестовых сетях может помочь выявить недостатки в скриптах миграции и самом коде до того как вы сломаете прод.

Актуальная документация

Поддержание актуальной технической и пользовательской документации демонстрирует ваше ответственное отношение к обязанностям перед пользователями и партнерами.

Любые изменения в логике, зависимостях или процессе развертывания должны быть задокументированы.

Инкрементный аудит безопасности

Каждое обновление протокола должно проходить аудит безопасности.

Непрерывный аудит позволяет командам эффективно реагировать на изменения, не затрачивая слишком много усилий на повторный пересмотр старого кода.

Повторное моделирование угроз

Крупные обновления должны запускать пересмотр модели угроз протокола.

Даже небольшие изменения в интеграции или зависимостях могут привести к возникновению новых поверхностей для атаки.

Обновленные модели должны быть доступны публично.

Управление версиями фронтенда и бэкенда

Применение разумных практик управления версиями как для кода фронтенда, так и для бэкенда облегчает возврат к стабильным версиям во время инцидентов.

Этот подход поможет уменьшить панику среди пользователей и предотвратить ущерб репутации во время непредвиденных простоев.

Разработка дорожной карты безопасности для Web3

Помощь в разработке и реализации дорожной карты по безопасности Web3 для вашего протокола. Выстраивайте отношения с ведущими экспертами по безопасности.
 

Связанные статьи