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

暗号資産関連の機関やサービスプロバイダー——暗号資産取引所、決済会社、デジタル資産カストディアン、カストディアル/ノンカストディアルなウォレットプロバイダーを含む——にとって、blockchain penetration testingは、対象範囲に含まれる者にとっては任意の予防策ではありません。侵害が署名や資金にまで及びうる場合、あるいは適用されるルールが敵対的検証を求める場合、それは保証の必要な層となります。この主張は2つの柱に基づいています:コントラクトコードを超えたリスクの発生源、そして敵対的検証に関する規制要件または期待です。

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

この記事は、私たちのblockchain-penetration-testingシリーズの第一弾です。このシリーズを通じて、blockchain penetration testingとblockchain penetration testingは同じ分野を指します:前者を主要な用語として、後者を業界で一般的に使われる同義語として使用します。本稿は必要性についての大局的・全体像の主張を提示し、以降の記事でこの分野の定義、その運用上の境界、そして機関レベルの攻撃対象領域を詳しく取り上げます。

Part 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]。

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

コントラクト外の障害	代表的なインシデント	報告された概算損失額
鍵の取り扱い	BtcTurk [4]、SwissBorg [6]	約5,170万ドル(BtcTurk)、約4,150万ドル(SwissBorg)
トランザクション署名パイプライン	Bybit [3]	約15億ドル
サプライチェーンおよび依存関係	TrustWallet [7]	約850万ドル
機微データの露出	Slope [8]	約410万ドル
暗号実装	Wintermute [9]、Coldcard [10]	約1億6,000万ドル(Wintermute)、約9,000万ドル(Coldcard)*

* Coldcardの約9,000万ドルは検証済みのオンチェーン下限額(約1,405 BTC)であり、非公開の推定では最大約1億3,000万ドルに達する。

これらがペネトレーションテストと結びつく点は、単にそれらがコントラクトの範囲外にあるということではなく、それらが悪用されうるかどうかは、多くの場合、実際に展開されている構成要素——アイデンティティ、依存関係、署名管理、承認、資金ロジック——が、攻撃者が侵入口から資金まで最初から最後まで辿ることのできる経路として整合してしまうかどうかにかかっているということです。

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

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

これらのソリューションは有用ですが、暗号資産機関の資金取扱いチェーン——侵入口から資金移動アクションへと価値が移動していく、相互接続されたアイデンティティ、クラウドインフラ、署名ワークフロー、承認チェーン、ウォレット、ベンダー、オペレーターコンソール——に関しては限定的です。攻撃者が到達可能な経路とは、そのチェーンを横断するルートです:それはweb、dApp、モバイル、API、クラウド、あるいはアイデンティティといった侵入口から始まり、署名、承認、資金ロジックを経由し、その実運用のコンテキストの中でコントラクトがどう振る舞うかを通過して、最終的な資金移動アクションに至ることがあります。コードを見直すことでその経路が組み上がることはなく、トランザクションを監視してもそれを予見することはできません。両者を併用しても、なお構成上のギャップが残ることがあります:監査が示すのは、記述された通りにコードが健全であったということであり、実際に展開されているアイデンティティ、承認、署名者がそれを今も担保しているということではありません。そして監視は、技術的には正当であっても、オペレーターが意図したものとはまったく異なる送金を通してしまうことがあります。このギャップを埋めるのが、稼働中のシステムにおいて各コントロールが正しく組み合わさっていることを検証する、独立した敵対的検証です。

Blockchain penetration testingは、組み上がった状態で稼働しているシステムを実際に動かして検証し、インシデントが露呈させる前に、そのような経路が資金に到達し得るかどうかを発見し、実証します。Bybitのパターンはこの問題の輪郭を示しています:侵害された署名インターフェースが、オペレーター自身の承認を、彼らが決して意図していなかった送金へと変えてしまいました——これはコントラクト自体、それに対する監査、そしてトランザクション監視のいずれもが正当なものとして読み取りかねない結果です。Blockchain penetration testingはその構成そのものを直接標的とします:侵害されたベンダー、オペレーター、あるいはインターフェースの立場に立ち、そうした足掛かりが、正当に見える承認を不正な資金移動へと変えられるかどうか、そして実際に展開されているどのコントロール——アイデンティティ、承認ステップ、署名チェック——がそれを本当に阻止するのかをテストします。コントラクトのコードレベルの保証は引き続き監査の役割であり、blockchain penetration testingが展開済みのコントラクトに関与するのは、それが機関レベルの資金への経路の一部を形成する範囲において、その実際の挙動を通じてのみです——これは強い境界線ではなく、重点の置き方によって区別される補完的な範囲です。Part 2では、blockchain penetration testingが何を検証し、その範囲がどこで終わるかを定義しています。

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

従来型ペネトレーションテストは、クラウド、web/API、アイデンティティ、特権アクセスといった領域全体において依然として価値があります。その限界は、範囲とドメインの文脈にあります:通常のエンゲージメントは、暗号資産特有のビジネス上の意味論や、密接に結びついたセキュリティとコンプライアンスのモデルを持ち込まないことがあります。

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

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

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

Part 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専門版は、対象範囲に含まれるシステムから必然的に導かれます:それらが暗号資産の価値を承認、署名、カストディ、または記帳する場合、それらを適切にテストするには、Part 1で述べたのと同じ署名・資金フローに関する熟達度が求められます。

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

結論:2つの柱の収束

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

シリーズの続きへ:

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

Part 5: 認可と署名のセキュリティ:Web、dApps、および
Part 6: クラウドおよびCI/CDセキュリティ:自動化された運用の攻撃対象領域
Part 7: トレジャリー制御プレーンのセキュリティ:署名および引き出し承認
Part 8: 取引所台帳のセキュリティ:窃取経路とデータプレーンのロジック

BlockSecは、各機関がこの保証層を正確に配置できるよう支援します:資産、資金フロー、信頼境界、既存の保証を洗い出し、弁護士が適用対象と判断する義務を確認し、その上でテストの目的、範囲、アクセス、本番環境における安全対策、是正措置の証拠、再テスト計画を定義します。ご自身の保証ギャップを特定するには、私たちのblockchain penetration testingチームにご相談ください。エンゲージメントの範囲と料金はお問い合わせに応じてご案内します。資金が動く場所から始めましょう。

参考文献

初出順に番号を付与。

BlockSec、Crypto Payment Security Playbook。
米国連邦捜査局、DC3、および日本の警察庁、Identification of North Korean Cyber Actors (TraderTraitor) Responsible for Theft of $308 Million from Bitcoin.DMM.com(2024年12月)。
BlockSec、Bybit $1.5B Hack: In-Depth Analysis of the Malicious Safe{Wallet} Upgrade Attack。
rekt.news、BtcTurk — Rekt。
rekt.news、Leaderboard。
SwissBorg、SwissBorg Security Update: Kiln Breach。
BlockSec、TrustWallet Incident: A Stolen API Key Turns the Official Update Channel into a Backdoor。
Slope、Slope Wallet Sentry Vulnerability: Digital Forensics and Incident Response Report。
BlockSec、Our Short Analysis of the Profanity Tool Vulnerability。
BlockSec、Coldcard Entropy Failure and Seed Recovery。
BlockSec、Phalcon Security。
ニューヨーク州金融サービス局、23 NYCRR Part 500 — Cybersecurity Requirements for Financial Services Companies。
ドバイ・バーチャルアセット規制当局、Technology and Information Rulebook、Part I、Section E。
香港証券先物委員会、Circular 24EC65(2024年12月18日、PDF)。
欧州連合、Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA)、第24~27条。
シンガポール金融管理局、Technology Risk Management Guidelines(2021年1月)、Section 2およびSection 13;Notice FSM-N06: Notice on Cyber Hygiene(2024年)。