Last Updated on 2026年10月19日 by oba3
セキュリティ企業ハッケン（Hacken）は2026年第3四半期の暗号資産セキュリティ報告で、7月から9月までに107件のインシデントが発生し、被害額が11.8億ドルに達したと報告した。前四半期比では55％増加した。損失額の48％をスマートコントラクトのエクスプロイト、40％をアクセス制御や運用上の障害が占めたという。
同社が同時に強調したのが、大型被害ではサプライチェーン攻撃、秘密鍵の侵害、署名・出金インフラの障害が目立ったことだ。さらに、公開済みのセキュリティ修正が実際の攻撃より前に存在していた事例も複数確認された。今回のデータは「コード監査が役に立たない」ことを示すものではない。重要なのは、監査済みという表示だけでシステム全体の安全性を判断せず、何を、いつ、どこまで検証し、その後の変更や修正をどう管理しているかを見ることだ。
何が起きたのか？
Hackenの2026年第3四半期セキュリティ・コンプライアンス報告によると、期間中の被害額は11.8億ドル、インシデント数は107件だった。第2四半期の被害額から55％増え、2026年でも被害の大きい四半期の一つになった。
損失額ベースではスマートコントラクトのエクスプロイトが48％を占めた。前四半期の12％から大きく上昇している。一方、アクセス制御と運用上の障害は40％で、第2四半期の88％から低下した。
ここで48％と40％は、インシデントの直接的な原因を分類した数字として読む必要がある。Hackenは別の観点として、大型の単発被害ではサプライチェーン攻撃、秘密鍵侵害、署名・出金インフラの障害が目立ったとも説明している。
さらに同社は、第3四半期の傾向として、公開済みのセキュリティ修正が複数の高額被害より前に存在していたことを挙げた。脆弱性が発見され、修正方法まで公開されていても、本番環境へ適用されなければ攻撃面は残る。
一方、被害額の77％が監査対象外や供給網に関連したという数字については、Hackenの公開Web版では一次資料として確認できないため、本稿では使用しない。確認できる公式情報だけでも、コード、鍵、署名、出金、外部依存、修正適用を別々に管理する必要性は十分に読み取れる。
なぜ重要なのか？
暗号資産サービスでは「監査済み」という表示が、プロジェクト全体の安全性を保証するものとして受け取られやすい。しかし実際のセキュリティ監査には明確な対象範囲がある。
Hackenが公開する個別監査では、Review Scopeとして対象リポジトリやコミット、監査対象コンポーネントを明示する。たとえばQANplatformの監査記録でも、対象コード、監査項目、修正後のファイルまで具体的に示されている。
これは監査の弱点ではなく、監査という作業の性質そのものだ。特定のコードが検証済みでも、後から追加された外部ライブラリ、クラウド環境、管理者鍵、署名サーバー、フロントエンドまで自動的に同じ保証が及ぶわけではない。
そのため安全性を評価する際には「監査を受けたか」という一問だけでは足りない。「どのバージョンを監査したか」「本番環境はその状態と一致しているか」「指摘された修正は導入済みか」まで確認する必要がある。
市場構造への影響
暗号資産市場が大規模になるほど、最大損失経路はスマートコントラクトだけでは決まらなくなる。取引所、カストディアン、ブリッジ、ステーキング事業者では、管理者鍵や署名システムが大量の資産を動かせる場合がある。
この場合、スマートコントラクトが正しくても、署名権限を奪われれば資産は流出する。外部セキュリティ製品や開発ツールが侵害されれば、監査済みコードへ直接脆弱性がなくても内部システムへの侵入経路になり得る。
Hackenが第3四半期の大型被害でサプライチェーン、鍵、署名・出金インフラを取り上げたことは、セキュリティ評価の単位をコードから資産移動経路全体へ広げる必要性を示している。
今後は監査会社の名前だけでなく、どのリポジトリ、どのコミット、どの署名経路、どの外部依存まで検証されたかを比較することが重要になる。サービスごとに資産が動く経路が違う以上、すべての事業者を同じ監査項目だけで評価することには限界がある。
資金・規制・流動性との関係
セキュリティ事故は技術上の問題だけでなく、資金管理の問題でもある。署名鍵や出金基盤へ強い権限が集中していれば、一つの障害が短時間で大規模な資産移動につながる。
そのため機関投資家や銀行が暗号資産事業者を評価する場合、コード監査報告だけでなく、鍵管理、権限分離、外部ベンダー管理、変更管理、修正適用、異常検知まで確認する必要がある。
特に修正適用は重要だ。Hackenは第3四半期の傾向として、公開されたセキュリティ修正が複数の高額被害より前に存在していたと指摘した。これは脆弱性を発見する工程と、本番へ安全に反映する工程が別の管理課題であることを示す。
規制面でも同じ方向が見える。Hackenは、規制当局が一時点の確認だけでなく、セキュリティ統制が継続運用の中で実際に機能しているかを検証し始めていると報告している。監査証明書を一度取得するだけでなく、その後も統制を維持できるかが重要になる。
この変化が進めば、セキュリティ予算の配分も変わる。外部監査の取得だけでなく、再監査、依存ソフトの更新、署名基盤の分離、継続監視、修正適用までを恒常的な運用コストとして組み込む必要がある。
初心者向け補足
スマートコントラクト監査は、建物でいえば設計図や特定設備を専門家が検査する作業に近い。検査した設備が安全でも、建物の鍵、警備会社、入退室管理が同時に安全だとは限らない。
暗号資産でも同様に、監査対象のコードが安全でも、秘密鍵を管理するサーバーや外部ソフトウェアが侵害されれば資産を失う可能性がある。
また監査には時点がある。監査後にコードを書き換えたり、新しい外部サービスを追加したりすれば、その部分は以前の監査結果では評価されていない場合がある。
そのため「監査済みか」だけではなく、監査日、対象リポジトリ、コミット、対象機能、指摘事項の修正状況を見ると、実際に何が検証されたかを判断しやすくなる。
Web3Timesの視点
今回のHacken報告で重要なのは、11.8億ドルという被害額だけではない。スマートコントラクトとアクセス制御の双方で大きな損失が発生し、さらに大型事件では供給網、秘密鍵、署名・出金インフラまで問題になったことだ。
第一の観測点は監査範囲である。スマートコントラクトだけを対象とした監査と、署名基盤、ウォレット、インフラまで含めた評価では、同じ「監査済み」でも確認されている安全性の範囲が違う。
第二は監査後の差分だ。監査時点のコミットが安全でも、その後のアップグレードや外部ライブラリ変更で本番環境が変われば、以前の報告書だけでは現在の状態を説明できない。
第三は修正の導入状況である。公開済みの修正が攻撃前に存在していた事例が繰り返されるなら、脆弱性検出能力だけでなく、パッチを本番へ展開する速度と責任分担もセキュリティ指標になる。
第四は実際に資産を動かせる権限だ。管理者鍵、マルチシグ、署名サーバー、出金承認、第三者製品のどこに資産移動能力が集中しているかを把握しなければ、最大損失経路は評価できない。
暗号資産セキュリティの次の段階では、監査バッジの有無ではなく、対象、時点、修正、変更、運用統制までを継続的に確認できるかが重要になる。Hackenの第3四半期データは、セキュリティ保証を一度のコード監査から、資産が実際に動く全経路を継続検証する仕組みへ広げる必要性を示している。
