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

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

Институциональная уязвимость выходит за рамки ошибок в контрактах и затрагивает подписание, кастодиальное хранение, ключи, людей, цепочки поставок и инфраструктуру [1]. Таким образом, эта поверхность атаки не полностью покрывается привычными решениями web3-безопасности — аудитом на уровне кода и мониторингом на уровне транзакций — или только традиционным пентестингом. Это применимо к любой институции, где человек, поставщик, интерфейс или приложение могут влиять на то, что подписывается, одобряется, зачисляется или перемещается — включая случаи, когда кастодиальное хранение передано на аутсорсинг. Параллельно регуляторы в ряде рынков вводят требования, условные обязательства или надзорные ожидания с разным охватом, периодичностью и правилами независимости.

Эта статья открывает нашу серию, посвящённую пентестингу блокчейна. На протяжении всей серии термины "пентестинг блокчейна" и "пентестинг web3" относятся к одной и той же дисциплине: мы используем первый термин как основной, а второй — как его распространённый отраслевой синоним. В статье представлена общая, целостная аргументация в пользу необходимости этого подхода; последующие статьи подробно определяют дисциплину, границы её применения и поверхность атаки на институциональном уровне.

Часть 1: Откуда исходит риск

1.1 Риск за пределами смарт-контракта

Уязвимости смарт-контрактов остаются важными, но многие из крупнейших недавних потерь произошли в других местах, в частности в ключах, системах подписания и операционной инфраструктуре. В 2024 году злоумышленники украли около 305 миллионов долларов у DMM Bitcoin, скомпрометировав провайдера программного обеспечения для кошельков и манипулируя легитимным запросом на транзакцию [2]. В 2025 году Bybit потерял приблизительно 1,5 миллиарда долларов после компрометации цепочки поставок, которая привела к манипуляции интерфейсом подписания [3], в то время как потеря горячего кошелька BtcTurk также была связана со скомпрометированными приватными ключами [4]. Наши исследования указывают в том же направлении: среди инцидентов с потерями более 100 000 долларов, отслеженных нами в 2026 году, сбои за пределами контракта составили примерно один из восьми инцидентов, но более трёх четвертей от общей суммы потерь. По состоянию на август 2026 года семь из десяти крупнейших взломов в публичном рейтинге rekt.news, за исключением мошенничества и других записей, не связанных со взломами, представляли собой компрометации за пределами контракта, составляющие примерно 70% как по количеству инцидентов, так и по денежной стоимости [5].

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

* Показатель ~$90 млн для Coldcard — это подтверждённый минимум по данным блокчейна (около 1405 BTC); частные оценки достигают ~$130 млн.

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

1.2 Аудит на уровне кода и мониторинг на уровне транзакций: необходимы, но ограничены

Каждое из существующих известных решений web3-безопасности работает на определённом уровне. Аудит на уровне кода (аудит кода) проверяет код — логику контракта, кошелька или сервиса. Мониторинг на уровне транзакций (мониторинг) проверяет транзакции по мере их поступления в блокчейн; например, Phalcon [11] обнаруживает, оповещает и блокирует злонамеренную активность в режиме реального времени.

Эти решения полезны, но ограничены, когда речь идёт о цепочке обращения средств криптоинституций — связанных идентификационных данных, облачной инфраструктуры, рабочих процессов подписания, цепочек утверждения, кошельков, поставщиков и консолей операторов, через которые ценность перемещается от точки входа до действия по перемещению средств. Достижимый путь злоумышленника — это маршрут через эту цепочку: он может проходить от точки входа через веб, dApp, мобильное приложение, API, облако или идентификационные данные через подписание, утверждение и логику работы со средствами, а также может проходить через то, как контракт функционирует в этом реальном контексте, до действия по перемещению средств на другом конце. Проверка кода не собирает этот путь, а наблюдение за транзакциями не предвидит его. Даже используемые вместе, эти два подхода могут оставлять пробел в композиции: аудит показывает, что код был корректен в написанном виде, но не то, что развёрнутые идентификационные данные, утверждения и подписанты по-прежнему это обеспечивают; а мониторинг может пропустить перевод, который технически валиден, но никогда не был тем, что оператор намеревался сделать. Что закрывает этот пробел — это независимая состязательная валидация того, что элементы контроля правильно взаимодействуют в работающей системе.

Пентестинг блокчейна воздействует на собранную, работающую систему, чтобы обнаружить и продемонстрировать, может ли такой путь достичь средств до того, как инцидент раскроет это. Паттерн Bybit показывает форму проблемы: скомпрометированный интерфейс подписания превратил собственное одобрение операторов в перевод, который они никогда не намеревались совершать — результат, который контракт, его аудит и мониторинг транзакций могли бы каждый по отдельности воспринять как легитимный. Пентестинг блокчейна напрямую нацелен на эту композицию: занимая позицию скомпрометированного поставщика, оператора или интерфейса, он проверяет, может ли такая точка опоры превратить внешне валидное одобрение в неавторизованное перемещение средств, и какие развёрнутые элементы контроля — идентификационные данные, шаги утверждения, проверки подписания — фактически это останавливают. Гарантии на уровне кода контракта остаются задачей аудита; пентестинг блокчейна взаимодействует с развёрнутым контрактом только через его реальное поведение там, где это формирует часть маршрута к средствам на институциональном уровне — взаимодополняющие области применения, различающиеся по акценту, а не по жёсткой границе. Часть 2 определяет, что проверяет пентестинг блокчейна и где заканчивается его область применения.

1.3 Традиционный пентестинг: полезен, но недостаточен

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

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

Пентестинг блокчейна применяет установленные состязательные методики к традиционным поверхностям, а также к специфичным для web3 поверхностям подписания, утверждения, логики работы со средствами и динамики контрактов во всей работающей системе. Его отличие — это специализированная экспертная оценка в области web3-безопасности, а не новые инструменты: тестировщики интерпретируют кастодиальное хранение, намерение транзакции, потоки средств и механизмы контроля соответствия требованиям так, как это сделал бы злоумышленник. Разница заключается в цели: обычный тест, как правило, доказывает влияние на IT-контроль — захваченную сессию администратора, достигнутый сервер — в то время как тест блокчейна рассматривает перемещение ценности как конечное условие. Он идёт дальше: изменяет получателя или сумму внутри легитимного запроса на подписание и проверяет, соответствуют ли друг другу то, что видит одобряющий, политика утверждения и средства, которые фактически перемещаются.

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

Часть 2: Что требуют регуляторы

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

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

• Соединённые Штаты, Нью-Йорк: явное требование с ограниченным исключением. Организации, подпадающие под действие NYDFS 23 NYCRR Part 500 [12], включая лицензированные DFS предприятия по работе с виртуальной валютой, должны тестировать информационные системы как изнутри, так и снаружи их границ, на основе оценки риска, не реже одного раза в год. Тестирование может проводить квалифицированная внутренняя или внешняя сторона. Квалифицируемые малые организации получают ограниченное исключение из этого положения о тестировании, но остаются подчинёнными другим применимым положениям Part 500.

• Дубай: ежегодное требование, инициируемое изменениями. Лицензированные VASP должны проводить оценку уязвимостей и пентестинг не реже одного раза в год и перед внедрением новых систем, приложений или продуктов [13], используя квалифицированную независимую третью сторону. Аудит смарт-контрактов применяется там, где это релевантно бизнесу и деятельности VASP. Пентестинг, инициированный на основе анализа угроз, не имеет универсальной периодичности: VARA может требовать его, когда это необходимо и соразмерно на основе риска.

• Гонконг: требование, являющееся условием лицензии, для заявителей, считающихся имеющими лицензию. Заявители на статус торговых платформ виртуальных активов, считающихся имеющими лицензию, должны завершить пентестинг и оценку уязвимостей с удовлетворительными результатами до начала ограниченной эксплуатации [14]. Отдельные рекомендации применяются к заявителям — новым корпорациям. Независимая третья сторона должна охватить указанную инфраструктуру и приложения на уровнях приложений и сети. До начала ограниченной эксплуатации руководство должно завершить все основные и критические шаги по устранению недостатков для результатов со средним и высоким уровнем риска.

• Европейский союз: пропорциональная система; TLPT обусловлено идентификацией. DORA охватывает финансовые организации, включая поставщиков услуг криптоактивов [15]. Требуется соответствующее тестирование — не конкретно пентестинг — не реже одного раза в год для систем, поддерживающих критически важные или значимые функции. Пентестинг — это один из методов, выбираемых в соответствии с риском и пропорциональностью. Пентестинг, инициированный на основе анализа угроз, применяется только к организациям, идентифицированным компетентными органами, проводится на реальных производственных системах и, как правило, требуется не реже одного раза в три года; органы могут корректировать эту периодичность на основе риска. DORA также вводит условия независимости тестировщика. Микропредприятия не подпадают под требование о программе тестирования.

• Сингапур: необязательное надзорное ожидание. Руководящие принципы управления технологическими рисками MAS указывают, что финансовые организации должны проводить пентестинг, и ожидается, что доступные из интернета системы будут тестироваться не реже одного раза в год или после существенных изменений или обновлений [16]. Это необязательное надзорное руководство, которое не требует привлечения независимой третьей стороны. Обязательное уведомление о кибергигиене, применимое к банкам, не указывает пентестинг конкретно. Обязательное уведомление, касающееся платежей или цифровых платёжных токенов, находится за рамками данной статьи.

В совокупности эти режимы требуют или ожидают проведения пентестинга — не как отдельной, обособленной категории "web3". Специализированная для web3 версия следует из систем, подпадающих под область применения: там, где они авторизуют, подписывают, осуществляют кастодиальное хранение или учитывают криптовалютную стоимость, надлежащее их тестирование требует того же уровня владения вопросами подписания и потоков средств, который описан в Части 1.

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

Заключение: Два основания сходятся

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

Продолжение серии:

• Часть 2: Что такое пентестинг блокчейна? Определения и границы

• Часть 3: Правила проведения работ и безопасность продакшн-среды для институционального пентестинга блокчейна

• Часть 4: Поверхности атак Web3: обзор пентестинга

Также в этой серии, скоро в публикации:

• Часть 5: Безопасность авторизации и подписания: веб, dApps и мобильные приложения
• Часть 6: Безопасность облака и CI/CD: поверхности атак автоматизированных операций
• Часть 7: Безопасность плоскости управления казначейством: подписание и одобрение выводов средств
• Часть 8: Безопасность биржевого реестра: пути кражи и логика плоскости данных

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

Ссылки

Пронумерованы в порядке первого появления.

1. BlockSec, Crypto Payment Security Playbook.
2. Федеральное бюро расследований США, DC3 и Национальное полицейское агентство Японии, Identification of North Korean Cyber Actors (TraderTraitor) Responsible for Theft of $308 Million from Bitcoin.DMM.com (декабрь 2024).
3. BlockSec, Bybit $1.5B Hack: In-Depth Analysis of the Malicious Safe{Wallet} Upgrade Attack.
4. rekt.news, BtcTurk — Rekt.
5. rekt.news, Leaderboard.
6. SwissBorg, SwissBorg Security Update: Kiln Breach.
7. BlockSec, TrustWallet Incident: A Stolen API Key Turns the Official Update Channel into a Backdoor.
8. Slope, Slope Wallet Sentry Vulnerability: Digital Forensics and Incident Response Report.
9. BlockSec, Our Short Analysis of the Profanity Tool Vulnerability.
10. BlockSec, Coldcard Entropy Failure and Seed Recovery.
11. BlockSec, Phalcon Security.
12. Департамент финансовых услуг штата Нью-Йорк, 23 NYCRR Part 500 — Cybersecurity Requirements for Financial Services Companies.
13. Регуляторное управление виртуальных активов Дубая, Technology and Information Rulebook, Part I, Section E.
14. Комиссия по ценным бумагам и фьючерсам Гонконга, Circular 24EC65 (18 декабря 2024, PDF).
15. Европейский союз, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA), Articles 24–27.
16. Валютное управление Сингапура, Technology Risk Management Guidelines (январь 2021), Sections 2 и 13; Notice FSM-N06: Notice on Cyber Hygiene (2024).