インシデントから規制へ：暗号資産機関にブロックチェーンペネトレーションテストが必要な理由

暗号資産機関やサービスプロバイダー——暗号資産取引所、決済会社、デジタル資産カストディアン、カストディアル型・非カストディアル型ウォレットプロバイダーを含む——にとって、ブロックチェーンペネトレーションテストは、対象範囲に該当する組織にとって任意の予防策ではありません。侵害が署名や資金に到達しうる場合、あるいは適用されるルールが敵対的検証を求めている場合、それは保証の必要不可欠な層となります。この主張は2つの柱に基づいています。すなわち、コントラクトコードを超えたリスクの発生源と、敵対的検証に関する規制要件または期待です。

機関のエクスポージャーは、コントラクトのバグにとどまらず、署名、カストディ、鍵、人、サプライチェーン、インフラにまで及びます[1]。そのため、この攻撃対象領域は、おなじみのweb3セキュリティソリューション——コードレベル監査やトランザクションレベルの監視——や、従来型のペネトレーションテスト単独では完全にはカバーされません。これは、人、ベンダー、インターフェース、アプリケーションが署名、承認、入金、移動の対象に影響を与えうるあらゆる組織——カストディが外部委託されている場合も含む——に当てはまります。同時に、複数の市場の規制当局は、範囲、頻度、独立性のルールが異なる要件、条件付き義務、または監督上の期待を課しています。

この記事は、当社のブロックチェーンペネトレーションテストシリーズの第1弾です。このシリーズを通じて、blockchain penetration testing(ブロックチェーンペネトレーションテスト)とblockchain penetration testing(ブロックチェーン侵入テスト)は同じ分野を指します。私たちは前者を主要な用語として使用し、後者を業界で一般的な同義語として使用します。本稿では、必要性についての大局的・全体像を示す主張を提示し、以降の記事ではこの分野、その運用上の境界、機関の攻撃対象領域を詳細に定義します。

第1部:リスクの発生源

1.1 スマートコントラクトを超えたリスク

スマートコントラクトの脆弱性は依然として重要ですが、近年発生した最大規模の損失の多くは、それ以外の場所——特に鍵、署名システム、運用インフラ——に起因しています。2024年、攻撃者はウォレットソフトウェアプロバイダーを侵害し、正規のトランザクションリクエストを操作することで、DMM Bitcoinから約3億500万ドルを盗みました[2]。2025年には、Bybitがサプライチェーン侵害によって署名インターフェースが操作され、約15億ドルを失い[3]、BtcTurkのホットウォレットの損失も同様に、侵害された秘密鍵に起因していました[4]。私たちの調査も同じ方向性を示しています。2026年に私たちが追跡した10万ドル超の損失を伴うインシデントのうち、コントラクト外の障害は件数ではおよそ8件に1件に過ぎませんでしたが、総損失額の4分の3以上を占めていました。2026年8月時点で、rekt.newsの公開リーダーボード上位10件の大規模ハッキング(詐欺やその他のハッキング以外の項目を除く)のうち7件がコントラクト外の侵害であり、件数・金額の両方でおよそ70%を占めていました[5]。

ウォレットとカストディシステムは、このパターンを具体的に示しており、ウォレットセキュリティは近年、特にインシデントが活発に発生する領域であり続けています。私たちの調査では、障害を鍵の取り扱い、トランザクション署名パイプライン、サプライチェーンおよび依存関係、機密データの露出、暗号実装に分類しています。

* Coldcardの約9,000万ドルは、オンチェーンで検証済みの下限値(約1,405 BTC)です。民間の推定では最大約1億3,000万ドルに達するとされています。

これらをペネトレーションテストと結びつけるのは、単にそれらがコントラクトの範囲外にあるという事実だけではなく、それらが悪用可能かどうかは、多くの場合、展開された各要素——アイデンティティ、依存関係、署名制御、承認、資金ロジック——が、攻撃者が侵入口から資金まで最初から最後までたどり得る経路として並ぶかどうかに左右されるという点です。

1.2 コードレベル監査とトランザクションレベル監視:不可欠だが限定的

既存のよく知られたweb3セキュリティソリューションはそれぞれ特定のレベルで機能します。コードレベル監査はコードを検査します(コード監査)——コントラクト、ウォレット、あるいはサービスロジックのコードを検査します。トランザクションレベルの監視(モニタリング)は、トランザクションがチェーンに到達する際にそれを検査します。例えばPhalconは実行時に悪意ある活動を検知し、アラートを出し、ブロックします[11]。

これらのソリューションは有用ですが、暗号資産機関の資金取扱チェーン——エントリーポイントから資金移動アクションへと価値が移動する際に経由する、接続されたアイデンティティ、クラウドインフラ、署名ワークフロー、承認チェーン、ウォレット、ベンダー、オペレーターコンソール——に関しては限界があります。攻撃者が到達可能な経路とは、このチェーンを横断するルートです。それはweb、dApp、モバイル、API、クラウド、あるいはアイデンティティのエントリーポイントから始まり、署名、承認、資金ロジックを経由し、実際の稼働環境下でコントラクトがどのように振る舞うかを通過して、最終的に資金移動アクションへと至ることがあります。コードをレビューしてもその経路は組み立てられませんし、トランザクションを監視してもそれを予測することはできません。両者を併用しても、なお組み合わせのギャップが残る場合があります。監査はコードが記述された通りに健全であることを示すものであり、展開されたアイデンティティ、承認、署名者がそれを依然として強制していることを示すものではありません。また監視は、技術的には有効であるものの、オペレーターが決して意図していなかった移動を通過させてしまう可能性があります。このギャップを埋めるのが、制御が実稼働システムにおいて正しく組み合わさっているかを独立して敵対的に検証することです。

ブロックチェーンペネトレーションテストは、組み立てられた稼働中のシステムに対して実際に働きかけ、インシデントが発生する前に、そのような経路が資金に到達し得るかどうかを発見・実証します。Bybitのパターンは、この問題の形を示しています。侵害された署名インターフェースが、オペレーター自身の承認を、彼らが決して意図していなかった資金移動に変えてしまいました——この結果は、コントラクト、そのコントラクトの監査、そしてトランザクション監視のいずれも、正当なものと読み取ってしまう可能性があったものです。ブロックチェーンペネトレーションテストは、この組み合わせを直接標的とします。侵害されたベンダー、オペレーター、インターフェースの立場に立ち、その足がかりが一見有効に見える承認を不正な資金移動に変え得るかどうか、そしてどの展開済み制御——アイデンティティ、承認ステップ、署名チェック——が実際にそれを阻止するのかをテストします。コントラクトコードレベルの保証は引き続き監査の役割ですが、ブロックチェーンペネトレーションテストは、展開済みのコントラクトが機関レベルの資金への経路の一部を形成する場合に限り、その実際の挙動を通じてそのコントラクトに関与します——これは重点の違いによって区別される補完的な範囲であり、厳密な境界ではありません。第2部では、ブロックチェーンペネトレーションテストが検証する内容と、その範囲がどこで終わるかを定義しています。

1.3 従来型のペネトレーションテスト:有用だが十分ではない

従来型のペネトレーションテストは、クラウド、web・API、アイデンティティ、特権アクセスの各領域において依然として価値があります。その限界は範囲と業界コンテキストにあります。従来のエンゲージメントは、暗号資産の業務セマンティクスや、結合されたセキュリティとコンプライアンスのモデルを扱わない場合があります。

暗号資産の世界では、署名が不可逆的な価値移動を承認する場合があります。引き出しの承認は単なるフォーム送信ではなく、資金制御の意思決定です。入金計上、残高会計、内部送金は資金ロジックです。アドレスやトランザクションも、制裁対象や資金源に関する意味を持つ場合があります。テスターは認証バイパスを発見しても、それが署名表示の不一致、弱い承認ポリシー、あるいは丸め誤差とどのように組み合わさって資金への経路になるかを見落とすことがあります。

ブロックチェーンペネトレーションテストは、確立された敵対的手法を従来の領域に加えて、稼働中のシステム全体にわたるweb3固有の署名、承認、資金ロジック、コントラクトの動的な領域に適用します。その差別化要因は、新しいツールではなくweb3セキュリティに特化した専門的判断です。テスターはカストディ、トランザクションの意図、資金フロー、コンプライアンス制御を攻撃者の視点で解釈します。その違いは目的にあります。従来型のテストは通常、ITコントロールへの影響——管理者セッションの乗っ取り、サーバーへの到達——を証明することを目的としますが、ブロックチェーンテストは価値の移動そのものを終了条件として扱います。そこで止まらず、正当な署名リクエスト内の受取人や金額を改変し、承認者が目にするもの、承認ポリシー、そして実際に移動する資金が依然として整合しているかを確認します。

まとめると、これは補完的な保証であり、静的対動的の壁ではありません。コードレベル監査、トランザクションレベル監視、従来型のペネトレーションテストは引き続き必要です。ブロックチェーンペネトレーションテストは、到達可能な経路を検証することでそれらを結びつけますが、それらに取って代わるものではなく、侵害の発見や予防を保証するものでもありません。

第2部:規制当局が要求する内容

要件は法域によって異なり、特定の事業体やシステムに対するライセンス、継続的、および規制当局主導の義務のスペクトルを形成しています。

これらの例は例示的なものであり、法的助言ではありません。組織は、自らの状況、免除、システム、義務について弁護士に確認する必要があります。

• 米国、ニューヨーク州:明示的要件と限定的免除。 NYDFS 23 NYCRR Part 500[12]の対象事業体(DFSライセンスを持つ仮想通貨事業を含む)は、リスク評価に基づき、少なくとも年1回、境界の内外から情報システムをテストしなければなりません。適格な内部または外部当事者がテストを行うことができます。適格な小規模事業体は、このテスト条項について限定的な免除を受けますが、Part 500のその他の適用条項には引き続き従う必要があります。

• ドバイ:年次および変更時トリガー要件。 ライセンスを受けたVASPは、少なくとも年1回、および新しいシステム、アプリケーション、製品を導入する前に、適格な独立した第三者を用いて脆弱性評価およびペネトレーションテストを実施しなければなりません[13]。スマートコントラクト監査は、VASPの事業・活動に関連する場合に適用されます。脅威主導型ペネトレーションテストには一律の頻度はありません。VARAはリスクに基づき必要かつ適切な場合にこれを要求することができます。

• 香港:みなしライセンス申請者に対するライセンス条件要件。 みなしライセンス取得済みの仮想資産取引プラットフォーム申請者は、制限付き運用開始前に、満足のいく結果を伴うペネトレーションテストおよび脆弱性評価を完了しなければなりません[14]。新設法人申請者には別途ガイダンスが適用されます。独立した第三者は、アプリケーション層とネットワーク層にわたる指定のインフラおよびアプリケーションをカバーしなければなりません。制限付き運用開始前に、経営陣は中〜高リスクの検出事項について、すべての主要かつ重大な是正措置を完了しなければなりません。

• 欧州連合:比例原則に基づく枠組み;識別を条件とするTLPT。 DORAは、暗号資産サービスプロバイダーを含む金融事業体を対象としています[15]。DORAは、重要または重大な機能をサポートするシステムについて、少なくとも年1回、適切なテスト——ペネトレーションテストに限定されない——を要求しています。ペネトレーションテストは、リスクと比例性に応じて選択される手法の一つです。脅威主導型ペネトレーションテストは、所管当局によって識別された事業体にのみ適用され、実稼働の本番システムで実施され、一般に少なくとも3年ごとに要求されます。当局はリスクに基づいてこの頻度を調整することができます。DORAはまた、テスターの独立性に関する条件も課しています。零細企業はこのテストプログラム要件の対象外です。

• シンガポール:非拘束的な監督上の期待。 MASのテクノロジーリスク管理ガイドラインは、金融機関がペネトレーションテストを実施すべきであるとし、インターネットに接続可能なシステムについては少なくとも年1回、または重要な変更・更新の後にテストされることを期待しています[16]。これは非拘束的な監督ガイダンスであり、独立した第三者を必要とするものではありません。拘束力のある、銀行を対象としたサイバー衛生通知はペネトレーションテストを明記していません。拘束力のある決済またはデジタル決済トークン通知は本記事の対象範囲外です。

これらを総合すると、これらの規制体制はペネトレーションテストを要求または期待していますが、それはブランド化された「web3」カテゴリーではありません。web3専門版は、対象範囲となるシステムから導かれるものです。それらが暗号資産の価値を承認、署名、カストディ、または計上する場合、それらを適切にテストするには、第1部で説明した署名および資金フローに関する同様の専門知識が求められます。

結論は明確です。特定の法域における多数のライセンス事業体は、すでに要件または監督上の期待に直面していますが、それはすべての市場で同一の義務ではありません。その違いは、範囲、頻度、テスターの独立性、是正措置、証拠、そしてそのテストがライセンス取得、継続的なコンプライアンス、または規制当局主導の演習のいずれを支援するものかを決定します。

結論:2つの柱の収束

リスクの発生源と規制要件・期待は、同じ結論を示しています。すなわち、対象範囲に該当する機関にとって、ブロックチェーンペネトレーションテストは必要不可欠な保証層である、ということです。それは、既存の制御を補完しながら、アクセス、承認、署名、資金にわたる到達可能な経路を検証します。それは予防を保証したり、過去の特定のインシデントを阻止できたことを証明したり、悪用可能なすべての経路を発見したりすることはできません。その目的は、単発の報告書ではなく、立ち上げ、運用、検知、対応、規制上の証拠にわたる継続的な保証です。

シリーズの続きをご覧ください:

• 第2部:ブロックチェーンペネトレーションテストとは何か?定義と境界

• 第3部:機関向けブロックチェーンペネトレーションテストにおける交戦規定と本番環境の安全性

• 第4部:Web3攻撃対象領域:ペネトレーションテストの概観

このシリーズでは、近日中に以下も公開予定です:

• 第5部:認可と署名のセキュリティ:Web、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年12月)。
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(2024年12月18日、PDF)。
15. 欧州連合、Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA)、第24条〜第27条。
16. シンガポール金融管理局、Technology Risk Management Guidelines(2021年1月)、Section 2および13;Notice FSM-N06: Notice on Cyber Hygiene(2024年)。