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

機関のエクスポージャーは、コントラクトのバグを超えて、署名、カストディ、鍵、人、サプライチェーン、インフラストラクチャにまで及ぶ [1]。そのため、このサーフェスは、おなじみのweb3セキュリティソリューション——コードレベルの監査とトランザクションレベルの監視——だけでも、従来のペネトレーションテストだけでも、完全にはカバーされない。これは、人、ベンダー、インターフェース、アプリケーションが署名、承認、入金計上、資金移動に影響を与えうるあらゆる機関に当てはまる——カストディが外部委託されている場合も含む。並行して、いくつかの市場の規制当局は、範囲、頻度、独立性の規則が異なる要件、条件付き義務、または監督上の期待を課している。
本記事は、私たちのweb3ペネトレーションテストシリーズの幕開けである。本シリーズを通じて、ブロックチェーンペネトレーションテストとweb3ペネトレーションテストは同じ分野を指す——前者を主要用語として、後者を業界で一般的な同義語として使用する。本記事は、その必要性についての大局的かつ全体像を捉えた論拠を提示する。以降の記事では、この分野、その運用境界、機関の攻撃対象領域を詳細に定義する。
パート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万ドルに達する。
これらとペネトレーションテストを結びつけるのは、単にそれらがコントラクトの範囲外にあるという事実だけではなく、それらが悪用可能かどうかは、往々にして、展開された各要素——ID、依存関係、署名制御、承認、資金ロジック——が、攻撃者がエントリーポイントから資金まで端から端まで歩き通せる経路として整列するかどうかにかかっている、という点である。
1.2 コードレベルの監査とトランザクションレベルの監視:不可欠だが限界がある
既存のよく知られたweb3セキュリティソリューションはそれぞれ、特定のレベルで機能する。コードレベルの監査はコードを検証する(コード監査)——コントラクト、ウォレット、またはサービスロジックを検証する。トランザクションレベルの監視(モニタリング)は、トランザクションがチェーンに到達する時点でそれを検証する。例えばPhalconは実行時に悪意ある活動を検出し、警告し、ブロックする [11]。
これらのソリューションは有用だが、暗号資産機関の資金取扱チェーン——価値がエントリーポイントから資金移動アクションへと移動する際に経由する、連携したID、クラウドインフラストラクチャ、署名ワークフロー、承認チェーン、ウォレット、ベンダー、オペレーターコンソール——に関しては限界がある。攻撃者が到達可能な経路は、そのチェーンを横断するルートである。それはウェブ、dApp、モバイル、API、クラウド、またはIDのエントリーポイントから始まり、署名、承認、資金ロジックを経由し、コントラクトがそのライブなコンテキストでどのように振る舞うかを通過して、反対側の資金移動アクションに至りうる。コードを検証しても、その経路は組み上がらず、トランザクションを監視しても、それを予期することはできない。両方を併用しても、依然として構成上のギャップが残りうる——監査は、書かれたコードが健全であったことを示すにすぎず、展開されたID、承認、署名者が今もそれを実施しているかどうかは示さない。そして監視は、技術的には有効であるが、オペレーターが意図したものでは決してなかった転送を通過させてしまう可能性がある。そのギャップを埋めるのは、稼働中のシステムにおいて、制御が正しく組み合わさっていることを検証する独立した敵対的検証である。
ブロックチェーンペネトレーションテストは、組み上げられた稼働中のシステムを実際に動かし、インシデントがそれを露呈させる前に、そのような経路が資金に到達しうるかどうかを発見し、実証する。Bybitのパターンは、この問題の輪郭を示している——侵害された署名インターフェースが、オペレーター自身の承認を彼らが決して意図しなかった転送に変えてしまった。これはコントラクト、そのコントラクトの監査、トランザクション監視のいずれもが正当なものとして読み取りうる結果である。web3ペネトレーションテストは、その構成を直接標的とする——侵害されたベンダー、オペレーター、またはインターフェースの立場に立ち、そのような足がかりが有効に見える承認を不正な資金移動に変えうるかどうか、そして展開されている制御——ID、承認ステップ、署名チェック——のうちどれが実際にそれを阻止するかをテストする。コントラクトコードレベルの保証は引き続き監査の仕事であり、web3ペネトレーションテストは、展開されたコントラクトが機関レベルの資金への経路の一部を形成する限りにおいて、そのライブな振る舞いを通じてのみそれに関与する——これは強い境界線ではなく、重点の違いによって区別される補完的な範囲である。パート2では、web3ペネトレーションテストが何を検証し、その範囲がどこで終わるかを定義する。
1.3 従来のペネトレーションテスト:有用だが十分ではない
従来のペネトレーションテストは、クラウド、ウェブおよびAPI、ID、特権アクセスのサーフェス全体にわたって依然として価値がある。その限界は範囲とドメインの文脈にある——従来のエンゲージメントは、暗号資産のビジネスセマンティクスや結合したセキュリティおよびコンプライアンスモデルを持ち込まない場合がある。
暗号資産の世界では、署名が不可逆な価値移動を承認しうる。出金の承認は、単なるフォーム送信ではなく、資金制御の決定である。入金の計上、残高会計、内部振替は資金のロジックである。アドレスやトランザクションは、制裁措置や資金源に関わる意味を持つこともある。テスターは認証バイパスを発見しても、それが署名表示の不一致、弱い承認ポリシー、丸め誤差とどう組み合わさって資金への経路を形成するかを見逃す可能性がある。
ブロックチェーンペネトレーションテストは、確立された敵対的手法を、従来のサーフェスに加えて、稼働中のシステム全体にわたるweb3特有の署名、承認、資金ロジック、コントラクトの動的なサーフェスにも適用する。その差別化要因は、新しいツールではなく専門的なweb3セキュリティの判断力である——テスターは、カストディ、トランザクションの意図、資金フロー、コンプライアンス制御を攻撃者のように解釈する。その違いは目的の違いでもある——従来のテストは通常、ITコントロールへの影響——管理者セッションの乗っ取り、サーバーへの到達——を証明するのに対し、web3テストは価値の移動を終了条件として扱う。それはそこで止まらない——正規の署名リクエスト内の受取人や金額を変更し、承認者が見るもの、承認ポリシー、実際に移動する資金が依然として整合しているかどうかを確認する。
要約すると、これは静的対動的という壁ではなく、補完的な保証である。コードレベルの監査、トランザクションレベルの監視、従来のペネトレーションテストは依然として必要である。web3ペネトレーションテストは、到達可能な経路を検証することでそれらを結びつける——それらを置き換えるものでも、侵害の発見を保証するものでも、防止を保証するものでもない。
パート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]。これは拘束力のない監督ガイダンスであり、独立した第三者を要求するものではない。拘束力のある、銀行を対象としたサイバー衛生通達では、ペネトレーションテストは規定されていない。拘束力のある決済またはデジタル決済トークン通達は、本記事の範囲外である。
総合すると、これらの制度はペネトレーションテストを要求または期待しているのであって、ブランド化された「web3」カテゴリーを求めているわけではない。web3専門版は、対象となるシステムから必然的に導かれる——それらが暗号資産の価値を承認、署名、カストディ、または計上する場合、それらを適切にテストするには、パート1で述べたのと同じ署名および資金フローへの精通が求められる。
結論は明確である——特定の法域における多数のライセンス事業体は、すでに要件または監督上の期待に直面しているが、それはすべての市場で同一の義務というわけではない。区別は、範囲、頻度、テスターの独立性、是正措置、証拠、そしてテストがライセンス取得、継続的コンプライアンス、または規制当局主導の演習のいずれを支えるものかを決定する。
結論:2つの柱が収束する
リスクの発生源と規制上の要件または期待は、同じ結論を指し示している——対象範囲に含まれる機関にとって、web3ペネトレーションテストは必要な保証層である。それは、アクセス、承認、署名、資金にわたる到達可能な経路を検証し、既存の制御を補完する。それは防止を保証することも、過去の特定のインシデントを阻止できたことを証明することも、悪用可能なあらゆる経路を発見することもできない。目的は、単発の報告書ではなく、立ち上げ、運用、検知、対応、規制上の証拠にわたる継続的な保証である。
シリーズを続けてご覧ください:
また、本シリーズでは近日公開予定:
- パート5:認可と署名のセキュリティ:ウェブ、dApps、モバイル
- パート6:クラウドとCI/CDセキュリティ:自動化された運用の攻撃対象領域
- パート7:トレジャリー・コントロールプレーンのセキュリティ:署名と出金の承認
- パート8:取引所台帳のセキュリティ:窃取経路とデータプレーンのロジック
BlockSecは、機関がこの層を正確に配置できるよう支援する——資産、資金フロー、信頼境界、既存の保証を洗い出し;弁護士が適用対象だと判断した義務を確認し;その上で、テストの目的、範囲、アクセス、本番環境の保護策、是正の証拠、再テスト計画を定義する。あなたの保証ギャップを特定するには、私たちのブロックチェーンペネトレーションテストチームにご相談ください ;エンゲージメントの範囲と料金はお問い合わせに応じて提供いたします。資金が動く場所から始めましょう。
参考文献
初出順に番号を付与。
-
BlockSec, Crypto Payment Security Playbook. https://blocksec.com/crypto-payment-playbook
-
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). 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
-
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
-
rekt.news, BtcTurk — Rekt. https://rekt.news/btcturk-rekt
-
rekt.news, Leaderboard. https://rekt.news/leaderboard
-
SwissBorg, SwissBorg Security Update: Kiln Breach. https://swissborg.com/blog/swissborg-security-update-kiln-breach
-
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
-
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
-
BlockSec, Our Short Analysis of the Profanity Tool Vulnerability. https://blocksec.com/blog/our-short-analysis-of-the-profanity-tool-vulnerability
-
BlockSec, Coldcard Entropy Failure and Seed Recovery (private-key exposure). https://blocksec.com/blog/coldcard-entropy-failure-seed-recovery
-
BlockSec, Phalcon Security (transaction monitoring and blocking). https://blocksec.com/phalcon/security
-
New York State Department of Financial Services, 23 NYCRR Part 500. https://www.dfs.ny.gov/industry_guidance/cybersecurity
-
Dubai Virtual Assets Regulatory Authority, Technology and Information Rulebook, Part I, Section E. https://rulebooks.vara.ae/rulebook/e-testing-and-audit
-
Hong Kong Securities and Futures Commission, Circular 24EC65, 18 December 2024. https://apps.sfc.hk/edistributionWeb/api/circular/openFile?lang=EN&refNo=24EC65
-
European Union, Regulation (EU) 2022/2554 (Digital Operational Resilience Act), Articles 24-27. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng
-
Monetary Authority of Singapore, Technology Risk Management Guidelines (January 2021), Sections 2 and 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



