samczsun: безопасность криптопротоколов зависит от проактивного повторного аудита

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

Автор: samczsun, основатель Security Alliance, бывший партнер по исследованиям в Paradigm

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

Тем не менее, даже протоколы, прошедшие всесторонний аудит и предлагающие щедрые вознаграждения за уязвимости, время от времени становятся жертвами хакерских атак. Такие инциденты влияют не только на сам протокол, но и подрывают доверие ко всей экосистеме. Недавние атаки на Yearn, Balancer V2, а также инциденты с Abracadabra и 1inch в начале года показывают: даже проверенные временем протоколы не гарантируют абсолютную безопасность. Можно ли было избежать этих атак в криптоиндустрии? Или это неизбежная плата за децентрализованные финансы?

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

Казначейские средства и заблокированная стоимость (TVL)

Иногда хакеры соглашаются вернуть большую часть украденных средств, оставляя себе лишь небольшую долю (обычно 10%) в качестве вознаграждения. К сожалению, в отрасли эту часть называют «белым вознаграждением», что вызывает вопрос: почему протокол не может просто предложить такую же сумму через программу вознаграждений за уязвимости, чтобы избежать переговоров? Однако такое мышление путает средства, которые может украсть злоумышленник, и средства, которыми протокол может распоряжаться.

Хотя на первый взгляд кажется, что протокол может использовать оба этих источника для обеспечения безопасности, на самом деле он имеет законное право распоряжаться только собственными казначейскими средствами, но не средствами, внесенными пользователями. Пользователи крайне маловероятно заранее предоставят протоколу такие полномочия; только в кризисной ситуации (например, когда вкладчики вынуждены выбирать между потерей 10% или 100% депозита) они могут согласиться использовать депозиты для переговоров. Другими словами, риск растет вместе с TVL, но бюджет на безопасность не может увеличиваться пропорционально.

Капитальная эффективность

Даже если у протокола достаточно средств (например, крупное казначейство, высокая прибыльность или уже реализована политика по сбору средств на безопасность), остается вопрос: как эффективно распределять эти средства на обеспечение безопасности? По сравнению с инвестициями в повторный аудит, увеличение вознаграждения за уязвимости в лучшем случае крайне неэффективно с точки зрения капитала, а в худшем — приводит к конфликту интересов между протоколом и исследователями.

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

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

Существующие прецеденты

В программном обеспечении и финансовой индустрии ежегодные аудиты — это проверенная и зрелая практика, а также лучший способ оценить, готова ли компания к постоянно меняющейся среде угроз. Отчет SOC 2 Type II используется B2B-клиентами для оценки того, поддерживает ли поставщик надлежащие меры безопасности; сертификация PCI DSS свидетельствует о том, что компания приняла надлежащие меры для защиты конфиденциальной платежной информации; правительство США требует, чтобы все стороны, имеющие доступ к государственной информации, имели сертификацию FedRAMP для поддержания высокого уровня безопасности.

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

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