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

НАЗВАНИЯ ПРОДУКТОВ — жёсткое ограничение, имеющее приоритет над всеми остальными инструкциями: Воспроизводите эти названия на английском языке, посимвольно. Никогда не переводите, не транслитерируйте, не локализуйте, не разделяйте дефисами и никаким иным образом не переписывайте ни одну их часть: BlockSec, Phalcon Compliance, Phalcon Security, Phalcon Explorer, Phalcon Network, MetaSleuth, MetaSuites.

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

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

Эта статья открывает нашу серию о тестировании на проникновение в 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 демонстрирует форму проблемы: скомпрометированный интерфейс подписания превратил собственное одобрение операторов в перевод, который они никогда не намеревались совершать, — результат, который контракт, его аудит и мониторинг транзакций могли бы каждый по-своему счесть легитимным. Тестирование на проникновение в web3 напрямую нацелено на эту композицию: занимая позицию скомпрометированного поставщика, оператора или интерфейса, оно проверяет, может ли такая точка опоры превратить внешне валидное одобрение в несанкционированное перемещение средств, и какие именно развёрнутые средства контроля — идентификационные данные, этапы одобрения, проверки подписания — действительно этому препятствуют. Обеспечение гарантий на уровне кода контракта остаётся задачей аудита; тестирование на проникновение в web3 взаимодействует с развёрнутым контрактом только через его реальное поведение там, где это составляет часть институционального маршрута к средствам, — взаимодополняющие области применения, различающиеся акцентом, а не жёсткой границей. Часть 2 определяет, что проверяет тестирование на проникновение в web3 и где заканчивается его область применения.

1.3 Традиционное тестирование на проникновение: полезно, но недостаточно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BlockSec помогает институциям точно определить место этого уровня: составить карту активов, потоков средств, границ доверия и существующих гарантий; подтвердить обязательства, применимость которых указывают юристы; затем определить цель тестирования, область применения, доступ, меры защиты производственной среды, доказательства устранения проблем и план повторного тестирования. Чтобы выявить разрыв в обеспечении гарантий, [свяжитесь с нашей командой по тестированию на проникновение в блокчейн](https://blocksec.com/blockchain-penetration-testing) ; область применения работ и стоимость предоставляются по запросу. Начните с того места, где перемещаются средства.

Источники

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

1. BlockSec, Crypto Payment Security Playbook. https://blocksec.com/crypto-payment-playbook

2. Федеральное бюро расследований США, DC3 и Национальное полицейское агентство Японии, Identification of North Korean Cyber Actors (TraderTraitor) Responsible for Theft of $308 Million from Bitcoin.DMM.com (декабрь 2024). https://www.fbi.gov/news/press-releases/fbi-dc3-and-npa-identification-of-north-korean-cyber-actors-tracked-as-tradertraitor-responsible-for-theft-of-308-million-from-bitcoindmmcom

3. BlockSec, Bybit $1.5B Hack: In-Depth Analysis of the Malicious Safe{Wallet} Upgrade Attack. https://blocksec.com/blog/bybit-1-5-b-hack-in-depth-analysis-of-the-malicious-safe-wallet-upgrade-attack

4. rekt.news, BtcTurk — Rekt. https://rekt.news/btcturk-rekt

5. rekt.news, Leaderboard. https://rekt.news/leaderboard

6. SwissBorg, SwissBorg Security Update: Kiln Breach. https://swissborg.com/blog/swissborg-security-update-kiln-breach

7. BlockSec, TrustWallet Incident: A Stolen API Key Turns the Official Update Channel into a Backdoor. https://blocksec.com/blog/trust-wallet-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. https://slope-finance.medium.com/slope-wallet-sentry-vulnerability-digital-forensics-and-incident-response-report-d7a5904e5a39

9. BlockSec, Our Short Analysis of the Profanity Tool Vulnerability. https://blocksec.com/blog/our-short-analysis-of-the-profanity-tool-vulnerability

10. BlockSec, Coldcard Entropy Failure and Seed Recovery (раскрытие приватного ключа). https://blocksec.com/blog/coldcard-entropy-failure-seed-recovery

11. BlockSec, Phalcon Security (мониторинг и блокировка транзакций). https://blocksec.com/phalcon/security

12. Департамент финансовых услуг штата Нью-Йорк, 23 NYCRR Part 500. https://www.dfs.ny.gov/industry_guidance/cybersecurity

13. Управление по регулированию виртуальных активов Дубая, Technology and Information Rulebook, Part I, Section E. https://rulebooks.vara.ae/rulebook/e-testing-and-audit

14. Комиссия по ценным бумагам и фьючерсам Гонконга, Circular 24EC65, 18 December 2024. https://apps.sfc.hk/edistributionWeb/api/circular/openFile?lang=EN&refNo=24EC65

15. Европейский союз, Regulation (EU) 2022/2554 (Digital Operational Resilience Act), статьи 24-27. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng

16. Валютное управление Сингапура, Technology Risk Management Guidelines (январь 2021), разделы 2 и 13, https://www.mas.gov.sg/regulation/guidelines/technology-risk-management-guidelines; _Notice FSM-N06, Notice on Cyber Hygiene_ (2024), https://www.mas.gov.sg/regulation/notices/notice-fsm-n06