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

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

Цифры неприятны именно для команд, которые считают завершенный аудит финальным security milestone. В отчетном периоде взломали 14 протоколов, проходивших аудит. Это не доказательство дефекта аудита как метода. Это доказательство дефекта в архитектуре процесса безопасности.

Код больше не единственная граница доверия

Согласно приведенным данным, компрометация ключей и инфраструктуры дала 88,3% всех похищенных средств — около $674,5 млн. Ошибки смарт-контрактов при этом оставались самым частым классом инцидентов: 44 из 67. Но на них пришлось лишь примерно 11% ущерба.

Это важное различие, которое часто теряется в маркетинговом шуме. Частота уязвимостей и денежный ущерб — разные метрики. Контрактная логика может генерировать много мелких или средних эксплойтов. Один скомпрометированный signer, облачный аккаунт или привилегированный ключ способен обнулить весь threat model быстрее, чем сложная ошибка в Solidity.

Аудит проверяет конкретную кодовую базу в заданном scope и в определенный момент времени. Он не обязан покрывать устройства подписантов, облачную инфраструктуру, операционные разрешения, развернутый байткод, последующие апгрейды, внешние зависимости и старые контракты, которые все еще доступны для вызова. Подменять эту границу словом «безопасность» — методологическая ошибка.

PDF не контролирует multisig

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

В материале отмечается, что лишь 9% отслеживаемых проектов ведут непрерывный мониторинг, а аудиты, bug bounty и мониторинг реального времени совмещают только 4%. На этом фоне печать «Audited» выглядит не как гарантия, а как узкий артефакт старого состояния репозитория.

Показателен и отдельный сигнал от Bitget: в результате взлома контракта WEMIX была проведена дополнительная эмиссия более 5,22 млн WEMIX, после чего средства перевели через кроссчейны в Ethereum и BSC. Даже без дополнительных деталей здесь виден знакомый паттерн: критична не только корректность бизнес-логики, но и наличие прав, позволяющих изменить денежную массу или маршрут активов.

Что проверять до взаимодействия с протоколом

Для пользователя и интегратора вопрос «был ли аудит?» слишком примитивен. Нужна следующая проверка: опубликован ли scope, соответствует ли он текущим адресам контрактов, покрывает ли deployed-версия заявленный код, были ли апгрейды после аудита и какие роли обладают административными полномочиями.

Для команды критерий еще жестче. Привилегированные операции должны быть отделены от обычной логики приложения; доступы — минимизированы; ключи — не превращены в single point of failure. Мониторинг должен отслеживать изменения ролей, подозрительные вызовы и движение средств, а не появляться после инцидента как раздел в post-mortem.

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