Журнал "Information Security/ Информационная безопасность" #1, 2026

По данным аналитической платформы DeFiLlama, которая отслеживает крупные инциденты в Web3, с 2018 г. совокупные потери превысили $15,8 млрд. Из них более $7,1 млрд пришлось на взломы DeFi-протоколов и около $2,9 млрд – на атаки на кроссчейн-мосты. При этом инциденты отличаются не только мас- штабом, но и природой уязвимостей – от ошибок в расчетах внутри контракта до некорректных параметров внешних зависимостей. Март 2026 г. подарил нам несколько характерных примеров. dTRINITY dLEND потерял $257 тыс. в результате атаки на инфляцию депозита (манипуляция коэф- фициентом начисления долей при вне- сении средств, позволившая увеличить баланс без эквивалентного ввода лик- видности). Venus Core Pool – минус $3,7 млн, уязвимость в механике пожертво- ваний (некорректная обработка донатов в пул, влияющая на расчет долей участ- ников). Goose Finance – $8,4 тыс., ошибка в учете акций (расхождение между внут- ренним учетом долей и фактическим балансом активов). Есть и более сложные кейсы. Aave V3 потерял $27,78 млн из-за параметров оракулов CAPO (некорректная настройка источника цен, позволившая использо- вать искаженные данные для расчета залога и заимствований). SolvBTC – $2,7 млн, ошибка в логике резерва минта (некорректная проверка обеспе- ченности при выпуске токенов). Molt EVM – $127 тыс., уязвимость в модифи- каторе владельца (ошибка в проверке прав доступа, позволившая выполнить привилегированную функцию). Полагаю, примеров достаточно. Обра- тите внимание, что уязвимости в них затрагивают разные уровни – от ариф- метики внутри контракта до зависимости от внешних данных. Часть ошибок локальна, часть проявляется только при определенных сценариях взаимодей- ствия с другими компонентами. Очевидно, что смарт-контакты надо изучать и проверять перед запуском. Ручной аудит смарт-контрактов Ручной аудит смарт-контрактов – это последовательная проверка кода и логи- ки протокола перед его развертыванием. Основная задача – найти уязвимости, которые могут привести к потере средств, нарушению логики работы или получению несанкционированного досту- па. Аудит выполняется разработчиками или специалистами по безопасности и опирается на разбор кода, сценариев его использования и возможных атак. Работа обычно начинается не с кода, а с документации. Аудитору важно понять, как именно должен работать контракт: какие роли предусмотрены, как рассчитываются балансы, при каких условиях возможны изменения состоя- ния. Без этого дальнейший анализ теряет смысл – ошибки часто возни- кают не в синтаксисе, а в расхождении между задуманной и реализованной логикой. Далее идет статический анализ. Про- веряется структура кода, типы перемен- ных, корректность проверок входных данных, обработка исключений. На этом этапе находят типовые проблемы: отсут- ствие require-проверок (базовых условий, ограничивающих выполнение функции, например проверок баланса или прав доступа), небезопасные внешние вызо- вы, ошибки в арифметике, потенциаль- ные переполнения или некорректные условия перехода состояния. После этого контракт прогоняется вручную по типовым и граничным сце- нариям использования. Проверяются функции: как меняются балансы, кор- ректно ли учитываются доли, что про- исходит при граничных значениях. Отдельно смотрят последовательности вызовов – многие ошибки проявляются не в одной функции, а в их комбинации. Параллельно разбираются возможные векторы атак. Проверяется устойчивость к Reentrancy (повторный вход в функцию до завершения предыдущего вызова), Race Condition (зависимость результата от порядка транзакций), манипуляции с ценами через оракулы, переполнения и другие типовые сценарии. Особое вни- мание к операциям с токенами и управ- лению правами: именно здесь чаще всего возникают критические последствия. Далее проверка эффективности. Ана- лизируется расход газа: лишние записи в Storage, избыточные вычисления, неэффективные циклы. Это не всегда напрямую влияет на безопасность, но критично для эксплуатации протокола. Результат аудита оформляется в отчет: перечень найденных уязвимо- стей, уровень критичности, описание сценария эксплуатации и рекомендации по исправлению. В хороших отчетах отдельно указывается, какие допущения сделаны при анализе и какие части системы не покрыты проверкой. Чем сложнее протокол и чем больше внешних зависимостей, тем сильнее растет объем ручной работы. В какой-то момент основной проблемой становится именно масштаб, а не сложность отдель- ных уязвимостей. Аудит смарт-контрактов с помощью ИИ Аудит с использованием ИИ – это не отдельный класс инструментов, а про- должение того же процесса, что и ручная 58 • ТЕХНОЛОГИИ ИИ в аудите смарт-контрактов и проблема масштаба март-контракты пишутся быстрее, чем их успевают нормально проверять. Ошибки при этом каждый раз разные – от про- стых просчетов в логике до сложных сценариев с оракулами и внешними протоколами. Разбор каждого инцидента занима- ет время, а их становится все больше и больше. В какой-то момент проблема сводится уже не к сложности, а к объему: ручной аудит не успевает покрывать все, что появляется. С Александр Подобных, руководитель отдела аналитики и крипторасследований VeroTrace, руководитель комитета по безопасности цифровых активов и противо- действию мошенничеству АРСИБ, судебный эксперт (компьютерно-техническая и экономическая экспертиза), член СРО АСЭ “Центр судебной экспертизы” Фото: А. Подобных