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

Что такое аудиты безопасности в криптоиндустрии?

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

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

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

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

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

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

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

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

Простое определение аудита безопасности

Аудит безопасности — это подробная проверка криптосистемы на наличие слабых мест до ее запуска или крупных обновлений.

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

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

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

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

Однако аудит не доказывает, что протокол полностью защищен от рисков.

Он лишь показывает, что конкретный объем работ был проверен конкретными аудиторами в определенный период.

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

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

Смарт-контракт DeFi-кредитования может хранить залог и учитывать долговые позиции.

В пуле ликвидности могут находиться токены, предоставленные пользователями.

Мост может контролировать обернутые активы в разных сетях.

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

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

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

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

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

Что обычно проверяют при аудите безопасности криптопроекта

Аудит безопасности криптопроекта обычно начинается с изучения документации и модели угроз.

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

Затем они построчно изучают код смарт-контрактов.

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

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

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

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

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

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

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

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

Полезны оба процесса, но это не одно и то же.

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

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

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

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

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

Аудит безопасности и формальная верификация

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

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

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

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

Если спецификация неполная или неверная, доказательство может не защитить от реального риска.

Аудит и формальная верификация эффективнее всего работают вместе.

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

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

Аудит безопасности и программы вознаграждения за поиск ошибок

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

Программа вознаграждения за поиск ошибок — это постоянно действующая программа, в рамках которой внешним исследователям платят за ответственное раскрытие уязвимостей.

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

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

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

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

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

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

Распространенные виды аудита безопасности криптопроектов

Аудит смарт-контрактов

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

Это наиболее распространенное значение термина «аудит безопасности» в криптоиндустрии.

Аудиторы проверяют токен-контракты, контракты кредитования и стейкинга, хранилища, контракты управления, пулы ликвидности, NFT-контракты и контракты мостов.

Проверка охватывает как технические ошибки, так и проблемы бизнес-логики.

Аудит архитектуры протокола

При аудите архитектуры протокола проверяют взаимодействие контрактов, сервисов, участников и офчейн-систем.

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

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

Аудит архитектуры помогает выявить системные риски.

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

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

Мосты сопряжены с высоким риском, поскольку часто управляют активами в нескольких сетях.

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

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

Аудит безопасности кошельков

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

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

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

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

Аудит инфраструктуры

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

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

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

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

Как проходит аудит безопасности смарт-контракта

Аудит безопасности смарт-контракта обычно начинается с определения объема проверки.

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

Затем аудиторы изучают предполагаемую логику проекта и модель угроз.

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

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

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

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

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

Что следует включить в объем аудита?

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

В него следует включить смарт-контракты, запланированные к развертыванию.

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

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

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

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

Узкий объем проверки может снизить стоимость аудита, но одновременно повысить вероятность пропустить системный риск.

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

Распространенные уязвимости, выявляемые при аудитах

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

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

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

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

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

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

В списке OWASP Smart Contract Top 10 представлены актуальные категории основных рисков смарт-контрактов для разработчиков и специалистов по безопасности.

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

Уровни серьезности в отчетах об аудите

В отчетах об аудите результаты обычно классифицируют по уровню серьезности.

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

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

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

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

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

Оценка серьезности зависит как от технических факторов, так и от контекста.

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

Аудит безопасности и контроль доступа

Контроль доступа — одна из важнейших составляющих аудита безопасности криптопроекта.

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

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

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

В отчете аудиторы должны четко указывать привилегированные роли.

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

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

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

Аудит безопасности и обновляемые контракты

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

Это помогает командам исправлять ошибки и улучшать функции.

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

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

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

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

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

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

Аудит безопасности и оракулы

Оракулы передают в смарт-контракты внешние данные, например цены, ставки, резервы или случайные числа.

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

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

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

Риск оракула связан не только с кодом.

Это также экономический вопрос и вопрос структуры рынка.

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

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

Аудит безопасности и экономические атаки

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

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

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

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

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

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

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

Поэтому аудитам DeFi часто требуются как инженерные знания, так и анализ финансовых рисков.

Аудит безопасности и автоматизированные инструменты

Автоматизированные инструменты помогают аудиторам быстро находить известные типы уязвимостей.

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

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

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

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

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

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

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

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

Тестирование — основа качественного аудита.

До внешнего аудита команде следует подготовить модульные, интеграционные, фаззинг- и инвариантные тесты, если они применимы.

Модульные тесты проверяют отдельные функции.

Интеграционные тесты проверяют взаимодействие компонентов.

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

Инвариантные тесты проверяют, сохраняются ли важные правила.

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

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

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

Стандарты безопасности помогают командам и аудиторам применять единые критерии.

Стандарт OWASP Smart Contract Security Verification Standard устанавливает требования и тесты безопасности для смарт-контрактов, dApp и блокчейн-систем на базе EVM.

Спецификация EEA EthTrust Security Levels определяет требования к уровням сертификации безопасности смарт-контрактов.

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

Они также помогают командам подготовиться к аудиту.

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

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

Четкое описание методологии упрощает оценку аудита.

Что должен содержать отчет об аудите

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

В нем следует дать общее описание протокола.

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

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

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

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

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

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

Как пользователям читать отчет об аудите

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

Аудит старой версии кода может не иметь отношения к текущему развертыванию.

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

Следует изучить неустраненные замечания, а не просто искать слово «проверен».

Проект может пройти аудит и при этом иметь серьезные риски, о которых команда знает.

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

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

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

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

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

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

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

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

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

До начала аудита команда должна зафиксировать версию кода.

Если код постоянно меняется в ходе проверки, объем аудита становится нестабильным.

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

Аудиты безопасности после развертывания

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

Криптопротоколы не являются статичными.

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

Каждое изменение может создавать новые риски.

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

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

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

Безопасность — это непрерывный процесс, а не разовое мероприятие.

Аудит безопасности протоколов DeFi

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

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

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

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

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

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

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

Статус аудита — лишь одна из составляющих комплексной проверки DeFi-проекта.

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

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

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

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

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

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

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

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

В отчете об аудите моста эти допущения должны быть четко изложены.

Аудит безопасности NFT и игровых проектов

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

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

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

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

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

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

Важны также сайт, запросы кошелька на подписание, разрешения маркетплейса и полномочия администратора.

Если возможно, аудит NFT должен охватывать весь пользовательский сценарий.

Аудит безопасности кошельков

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

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

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

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

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

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

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

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

Аудит безопасности и риски управления

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

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

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

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

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

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

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

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

Аудит безопасности и операционная безопасность

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

Код протокола может быть безопасным, а операционные процессы — нет.

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

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

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

Система оповещений может не сработать во время атаки.

Если операционные допущения влияют на средства пользователей, аудит должен охватывать и их.

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

Ограничения аудитов безопасности

Аудит безопасности не может выявить все возможные ошибки.

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

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

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

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

Он не делает безопасными будущие обновления, которые не проходили проверку.

Поэтому не следует воспринимать слово «аудирован» как однозначную отметку безопасности.

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

Тревожные признаки при оценке аудита безопасности

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

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

Неразрешенные критические замечания в отчете — серьезный предупреждающий признак.

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

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

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

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

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

Рекомендации командам перед запросом аудита

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

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

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

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

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

Аудиторам нужно предоставить достаточно времени для тщательной проверки.

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

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

Рекомендации после аудита

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

Важно попросить аудиторов проверить существенные исправления.

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

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

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

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

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

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

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

Сначала следует убедиться, что отчет об аудите настоящий и общедоступный.

Проверьте, охватывает ли он текущие развернутые контракты.

Обратите внимание на неустраненные критические замечания и проблемы высокого уровня.

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

Изучите контроль администратора, возможность обновления, архитектуру оракулов, хранение активов и зависимости от мостов.

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

Учитывайте общую заблокированную стоимость: чем она выше, тем сильнее может быть интерес злоумышленников.

Аудит может повысить уверенность, но не должен отменять осторожность.

Аудиты безопасности и страхование

Некоторые пользователи криптовалют после аудита ищут страхование или защиту от убытков.

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

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

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

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

Страхование, аудит, программы вознаграждения и мониторинг — разные инструменты управления рисками.

У каждого из них есть свои ограничения.

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

Аудиты безопасности и требования регулирования

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

Аудит безопасности может показать, что проект серьезно отнесся к техническим рискам.

Однако аудит смарт-контракта — не то же самое, что соблюдение законодательства.

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

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

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

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

Не следует путать техническую безопасность с одобрением регулятора.

Распространенные заблуждения об аудитах безопасности

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

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

Другое заблуждение — считать одного аудита достаточным для всех будущих версий.

Новый код, активы, сети и интеграции могут создавать новые риски.

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

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

Еще одно заблуждение — считать, что аудит безопасности нужен только смарт-контрактам.

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

FAQ

Что такое аудит безопасности в криптоиндустрии?

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

Что такое аудит смарт-контракта?

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

Означает ли аудит, что криптопроект безопасен?

Нет. Аудит повышает уверенность, но не гарантирует полную безопасность проекта или защиту от будущих атак.

Что должен содержать отчет об аудите?

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

Зачем проводить аудит смарт-контрактов?

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

Чем аудит отличается от программы вознаграждения за поиск ошибок?

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

Могут ли автоматизированные инструменты заменить аудиторов безопасности?

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

Какие проблемы часто выявляют при аудите?

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

Как часто криптопроектам нужно проходить аудит?

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

Что означает объем аудита?

Объем аудита — это конкретный перечень кода, контрактов, систем, документации и допущений, включенных в проверку.

Почему хеш коммита важен при аудите?

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

Могут ли взломать аудированные контракты?

Да. Аудиторы могут пропустить ошибки, код может измениться позднее, допущения могут оказаться неверными, а злоумышленники — атаковать области, не входившие в объем аудита.

Стоит ли доверять проекту только потому, что он прошел аудит?

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

Заключение

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

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

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

Однако аудит безопасности не дает гарантий.

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

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

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

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