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

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

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

この記事は、ブロックチェーンペネトレーションテストシリーズの開幕編です。本シリーズを通じて、blockchain penetration testing と web3 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] は、実行時に悪意のある活動を検知し、アラートを発し、ブロックします。

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

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

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

従来型のペネトレーションテストは、クラウド、ウェブとAPI、アイデンティティ、特権アクセスといった対象領域全般において依然として価値があります。その限界は、範囲とドメインの文脈にあります。すなわち、従来型のエンゲージメントは、暗号資産のビジネス意味論や、結びついたセキュリティとコンプライアンスのモデルを必ずしも持ち込みません。

暗号資産の世界では、署名は不可逆な価値移動を承認し得るものであり、出金承認は単なるフォーム送信ではなく資金管理上の意思決定です。入金の記帳、残高の会計処理、内部送金は資金のロジックです。アドレスとトランザクションはまた、制裁措置や資金源としての意味を帯びることもあります。テスターが認証バイパスを発見したとしても、それが署名表示の不一致、脆弱な承認ポリシー、あるいは端数処理の欠陥とどう組み合わさって資金への経路になり得るのかを見落とす可能性があります。

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

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

パート2：規制当局が求めるもの

要件は法域によって異なり、特定の事業体やシステムに対して、ライセンス取得時、継続的、または規制当局からのトリガーによる義務のスペクトラムを生み出しています。

これらの事例は例示であり、法的助言ではありません。機関は、自らの地位、適用除外、システム、義務について、必ず弁護士に確認してください。

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

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

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

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

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

これらを総合すると、これらの制度はペネトレーションテストを要求または期待しているのであって、ブランド化された「web3」カテゴリーを要求または期待しているわけではありません。web3専門版のペネトレーションテストは、対象範囲に含まれるシステムから自然に導かれるものです。それらのシステムが暗号資産価値を承認、署名、カストディ、または会計処理する場合、それらを適切にテストするには、パート1で述べたのと同じ署名・資金フローへの精通が求められます。

結論は精緻です。特定の法域における相当数のライセンス事業体は、すでに要件または監督上の期待に直面しています——ただし、すべての市場で同一の義務が課されているわけではありません。こうした違いが、範囲、頻度、テスターの独立性、是正措置、証拠、そしてそのテストがライセンス取得、継続的コンプライアンス、あるいは規制当局トリガーの取り組みのいずれを支えるものかを決定づけます。

結論：二本の柱が交わるところ

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

シリーズを引き続きお読みください：

• パート2：ブロックチェーンペネトレーションテストとは何か？定義と境界

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

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

本シリーズでは、以下も近日公開予定です：

• パート5：認可と署名セキュリティ：ウェブ、dApp、モバイル
• パート6：クラウドとCI/CDセキュリティ：自動化された運用の攻撃対象領域
• パート7：トレジャリー・コントロールプレーンのセキュリティ：署名と出金承認
• パート8：取引所台帳のセキュリティ：窃取経路とデータプレーンのロジック

BlockSecは、機関がこの保証の層を正確に位置づけられるよう支援します。資産、資金フロー、信頼境界、既存の保証状況をマッピングし、弁護士が適用対象であると判断した義務を確認した上で、テストの目的、範囲、アクセス、本番環境の安全対策、是正措置の証拠、再テスト計画を定義します。保証のギャップを特定するには、当社のブロックチェーンペネトレーションテストチームにお問い合わせください。エンゲージメントの範囲と価格はお問い合わせに応じてご案内いたします。資金が動く場所から始めましょう。

参考文献

初出順に番号を付与。

1. BlockSec, Crypto Payment Security Playbook.
2. U.S. Federal Bureau of Investigation, DC3, and Japan National Police Agency, Identification of North Korean Cyber Actors (TraderTraitor) Responsible for Theft of $308 Million from Bitcoin.DMM.com (December 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. New York State Department of Financial Services, 23 NYCRR Part 500 — Cybersecurity Requirements for Financial Services Companies.
13. Dubai Virtual Assets Regulatory Authority, Technology and Information Rulebook, Part I, Section E.
14. Hong Kong Securities and Futures Commission, Circular 24EC65 (18 December 2024, PDF).
15. European Union, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA), Articles 24–27.
16. Monetary Authority of Singapore, Technology Risk Management Guidelines (January 2021), Sections 2 and 13; Notice FSM-N06: Notice on Cyber Hygiene (2024).