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

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

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

Эта статья открывает нашу серию о тестировании на проникновение в блокчейн. На протяжении всей серии термины "тестирование на проникновение в блокчейн" (blockchain penetration testing) обозначают одну и ту же дисциплину: мы используем первый вариант как основной термин, а второй — как его распространенный отраслевой синоним. Статья представляет высокоуровневое, целостное обоснование необходимости; последующие статьи подробно определяют дисциплину, границы ее применения и институциональную поверхность атаки.

Часть 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 работает на определенном уровне. Аудит на уровне кода изучает код (code audit) — код контракта, кошелька или логики сервиса. Мониторинг на уровне транзакций (monitoring) изучает транзакции по мере их поступления в блокчейн; например, 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).