大门セキュリティ講座 03｜Gate & GoPlus：監査レポートをどう読み解き、コントラクトの脆弱性をどう見抜くか

安全性は動的な状態であり、一枚の証明書ではありません。今年被害に遭ったプロジェクトの中には、監査を受けていたものも少なくなく、そのうちいくつかは複数回の監査を受けていました。これは監査に価値がないという意味ではなく、監査が答えられる問いの範囲は、多くの人が思っているよりずっと狭いというだけのことです。

監査報告書が記述しているのは、ある日、あるチームが見たあるバージョンにすぎません。しかしコントラクトはアップグレードされ、権限は変更され、プロジェクトが依存するオラクルやクロスチェーンブリッジは変わり、新しい攻撃手法は毎週のように出現します。報告書が納品された瞬間から、それは陳腐化し始めます。さらに厄介なのは、数年前にデプロイされ、当時無事に監査を通過した古いコントラクトが、今になって一括で再スキャンされていることです。長年稼働してきたコントラクトの深層の脆弱性が、わずか十数分で見つかってしまうこともあります。

これは Gate 特別企画「大門セキュリティ講座」の第3回です。Web3 セキュリティサービスプロバイダーの GoPlus Security と Gate セキュリティチームを招き、セキュリティサービスプロバイダーと取引プラットフォームという2つの視点から、監査と脆弱性調査について語り合います。監査済みのプロジェクトがなぜ事故を起こすのか、報告書はどう読むべきか、プラットフォームは上場前後にどのようなチェックを行っているのか、そして一般ユーザーが署名前にどのように自己点検できるのかについてです。

ゲスト紹介

GoPlus パートナー Adam：Adam は GoPlus のパートナーであり、セキュリティ研究院の責任者です。

GoPlus Security は Web3 と AI のための初の分散型セキュリティレイヤーを構築しており、ブロックチェーンと最先端の人工知能セキュリティソリューションを活用することで、ユーザーにスマートで効率的、かつ分散型のセキュリティ製品とサービスを提供しています。2022 年以来、GoPlus は指数関数的な成長を遂げ、1日の API 呼び出し量は3000万回に達し、ユーザーを約1000億ドル相当の潜在的損失から防いでいます。

Gate セキュリティチーム：Gate のセキュリティ部門は、プラットフォームのアカウント、取引、資産のセキュリティ体制の構築を担当すると同時に、長年にわたりユーザーの異常アカウントに関する申し立てや協査依頼にも対応しています。

Gate は2013年に設立され、業界で初めて100%準備金証明を導入した取引プラットフォームであり、現在世界で6000万人以上のユーザーにサービスを提供しています。セキュリティはこのビジネスが成立する前提であり、私たちは「大門セキュリティ講座」を通じて、こうした実際のリスクの背後にある共通のメカニズムを明らかにしたいと考えています。

Q1. なぜ多くのプロジェクトは監査を通過した後もなお盗まれ、権限の濫用が発生するのでしょうか？

GoPlus パートナー Adam：「一度の監査」は「ずっと安全」とイコールではありません。従来のコントラクト監査サービスには、現在4つの構造的な機能不全が存在します。

1）スナップショット式のチェック。監査は本質的に、監査エンジニアが特定の時点で行う半手作業のチェックであり、その効果はツールの品質、個人のスキル、作業状態に依存します。しかしコントラクトのコードはアップグレードされ、管理権限は変更され、パラメータ設定は調整されます。一度きりの監査報告書は、納品された瞬間から「陳腐化」していくのです。

2）未来を予測できない。新しい脆弱性の種類や新しい攻撃手法は次々と出現し、過去の監査では将来のリスクをカバーできません。

3）外部依存の制御不能。プロジェクトは一般にオラクル、クロスチェーンブリッジ、サードパーティプロトコルに依存しており、こうした依存項目のリスク変化は従来の監査の範囲外です。

4）旧コントラクトの集中爆発。数年前にデプロイされ、当時「監査済み」だったコントラクトが、自動化ツールによって一括で再び脆弱性を掘り起こされています。例えば Balancer や Yearn のように、正式稼働から数年経っても発見されなかった深層の脆弱性などです。

権限の濫用については、それはむしろコントラクトのコード自体ではなく運営段階で発生します。その原因には、Owner 権限が過大であること（自由に追加発行、ブラックリスト登録、取引の一時停止が可能）、管理者の秘密鍵の漏洩、マルチシグ管理の不備、悪意ある提案やガバナンス攻撃などが含まれます。これらはすべて運営段階で発生しやすいセキュリティ問題です。監査報告書に権限リスクが記載されていたとしても、その後誰が見張るのか、操作が安全で合理的かどうかは答えられません。

コントラクト監査後の上場はセキュリティ作業の終点ではなく、起点にすぎません。プロジェクトに必要なのは、コントラクトのライフサイクル全体をカバーする継続的なセキュリティであり、一度きりの監査報告書ではありません。

Gate セキュリティチーム：監査はユーザーにコードが何をできるかを伝えることはできますが、プロジェクト側が何をしようとしているかは伝えられません。

これは私たちが上場審査を行ってきた中で最も強く実感している点です。多くの事故の根源はプロジェクト側の意図にあります。あるコントラクトは技術的には完全に準拠しており、所有者権限の設計も正常な範囲内にあるかもしれませんが、プロジェクト側はそれでもある時点でこれらの権限を使い始めることができます。取引ルールの変更、ブラックリストの有効化、トークンの追加発行などです。これらの動作はコードレベルではすべて合法的であり、監査報告書も脆弱性として指摘しません。なぜならそれらは元々設計の一部だからです。

したがって、技術監査のほかにもう一层の制約が必要です。Gate のやり方は、上場段階で厳格なプロジェクトの選別と審査を行い、同時にプロジェクト側と不作為の宣言に署名し、さらに履行状況を監督することです。この層が解決すべきは、監査では解決できない部分です。コードに脆弱性がないからといって、そのチームがユーザーに損害を与える選択をしないとは限りません。

上場済みのプロジェクトについては、定期的なセキュリティ監査を実施し、同時にオンチェーンイベントのモニタリングでコントラクトの状態を追跡しています。ユーザーもいつでもあるコントラクトの現在のリスク項目を確認できます。

Q2. 一度の監査がずっと安全とイコールでないなら、プロジェクト側と業界全体はどのように調整すべきでしょうか？

Gate セキュリティチーム：暗号資産業界には構造的な特徴があります。すなわち、ビジネスの大部分、特に DeFi は、その運営モデルがモジュール型金融に近いということです。各種プラットフォームは共有コンポーネントから構築されており、コントラクト、ソフトウェアライブラリ、ウォレット、価格オラクル、クロスチェーンブリッジ、接続サービスプロバイダー、ウェブインターフェース、そしてアップデートを配信するシステムなどがあります。

したがって、自分のコントラクトが安全かどうかだけでなく、依存するあらゆる环节が依然として信頼できるかを問う必要があります。上流のあるコンポーネントに障害が発生すると、損失はチェーンに沿って下流に伝播します。過去の重大な攻撃を振り返ると、問題はしばしばプロトコルのロジックよりも前の段階、つまりサプライヤー、開発ツール、ソフトウェアがユーザーに到達する方法、あるいはユーザーが送金を承認するプロセスにありました。

GoPlus パートナー Adam：ハッカーが自動化ツールを利用して効率的に脆弱性を掘り起こす攻撃パラダイムはすでに形成され、急速に蔓延しています。攻撃は「専門家による手作業の研究」から「流水ライン」へと変わりました。業界の思考が依然として「上場前に監査会社に報告書を出してもらう」あるいはリスクを発見してからセキュリティ会社に「後手の埋め合わせ」を求めるにとどまるなら、それは弓矢で機関銃に対抗するようなものです。同じように効率的なツールで攻撃に対抗することこそが、唯一有効な道です。

業界レベルの調整の方向性は、「一度きりの監査」または「問題発生後に専門家を探す」から、「ライフサイクル全体の継続的セキュリティ」へとアップグレードすることです。GoPlus DeepScan の「コントラクトセキュリティ三種の神器」を例にすると、これは実装可能な閉ループです。

上場前、Token セキュリティ自己点検：数分で素早くハニーポット、悪意ある追加発行（Mint）、ブラックリスト、異常な取引税、Owner 権限などのバックドアリスクを自己チェック。

上場時、AI コントラクト監査：ソースコード、権限管理、ビジネスロジックを深く分析し、構文層とビジネスロジック層の脆弱性をスキャンし、構造化された監査報告書を納品。

上場後、継続的なセキュリティモニタリングと定期健診：新たな脆弱性情報、攻撃イベント、外部依存（オラクル、クロスチェーンブリッジ、サードパーティプロトコル）のリスクをリアルタイムで追跡し、プロジェクトが影響を受けているかどうかを継続的に判断し、常態的な早期警告を行う。定期的にコントラクトのセキュリティ健診を実施し、継続的に監査。

Q3. この2年で脆弱性の掘り起こし方はどのように変化しましたか？同じ資産でも、オンチェーンに置く場合と取引所に置く場合で、セキュリティモデルはどう違うのでしょうか？

GoPlus パートナー Adam：率直に言えば、短期的に見ると、現在の攻撃側の脆弱性の掘り起こし方はより多様化しています。理由は3つあります。

1）自動化ツールが脆弱性発見のハードルを大幅に下げました。かつてはトップクラスのセキュリティ研究者が数週間かけて行う作業を、今では攻撃の流水ラインが数分で走り終えます。

2）オンチェーンには「当時監査済み」の旧コントラクトが大量に蓄積されており、攻撃者にとっては埋蔵量豊富な「金鉱」です。

3）攻撃は一方向の現金化であり、「一つ」の脆弱性を見つければ十分ですが、防御側は「すべて」の脆弱性を守らなければなりません。

ハッカーがこの資金を掘り出して持ち去るのに数分かかりましたが、防御側が同じ脆弱性を見つけるのも実はわずか数分で済みます。違いはただ、プロジェクト側がハッカーより先にツールを正しく使ったかどうかだけです。

さらに重要なのは、防御側には攻撃側にはない3つの構造的優位性があることです。

1）先手の優位性：防御者は上場前にも運営中にも無限に再チェックできますが、攻撃者は防御者が再チェックをしていないことにかけるしかありません。

2）コストの優位性：AI 監査は回数課金や年間パッケージで提供され、コストは常態化・全量化できるほど低くなります。

3）知識の複利：セキュリティ知識ベースは新たな攻撃イベントごとに進化し続け、防御システムは使うほど強くなります。

オンチェーンとオフチェーンの2つのモデルでは、「誰があなたの資産を守っているか」と「あなたが直面するリスクの種類」がまったく異なります。

オンチェーン自己管理：セキュリティ = 秘密鍵のセキュリティ + コントラクトのセキュリティ。あなたが唯一のセキュリティ責任者です。秘密鍵の紛失・盗難には「カスタマーサポート」への申し立てはできません。毎回のインタラクションがオンチェーンリスク（承認の脆弱性、フィッシング署名、ハニーポット）を負います。利点は資産がどのプラットフォームの信用にも依存しないことです。

取引所のカストディ：セキュリティ = プラットフォームのセキュリティ + アカウントのセキュリティ。秘密鍵はプラットフォームが管理し（コールドウォレットとホットウォレットの分離、マルチシグ、リスク管理）、「技術的セキュリティ」を取引所にアウトソーシングするのに相当します。ただし取引所アカウントのセキュリティ（パスワード、2FA、フィッシング、API Key など）を適切に保護する必要があり、同時にプラットフォームの信用が保証された取引所を選ぶよう注意しなければなりません。

総じて、オンチェーンは「秘密鍵の保護 + 自己操作のリスク」、取引所は「プラットフォームの信用 + セキュリティインフラのリスク」です。前者はあなたの Web3 セキュリティ意識を試し、後者は取引所プラットフォームのインフラとあなたのアカウントセキュリティ習慣を試します。

Q4. 取引プラットフォームとして、Gate はセキュリティ面でどのような向上を遂げていますか？

Gate セキュリティチーム：まず、上場済みプロジェクトに対して定期的なセキュリティ監査を実施し、同時にオンチェーンイベントのモニタリングを通じてコントラクトの状態を継続的に追跡しています。コントラクトがアップグレードされたか、権限が変更されたか、異常な大口操作が発生していないか、これらは継続的に見ていく必要があります。上場時のチェック結論も、Adam が話した監査報告書と同じく、賞味期限があるからです。ユーザーもいつでもあるコントラクトの現在のリスク項目を照会できます。

次にプラットフォーム自身についてです。Gate のセキュリティ脆弱性バウンティプログラムは常時開設されており、世界中のセキュリティ研究者が問題を発見すれば提出できます。窓口は3つあります。sec@gate.com、チケット、そして HackenProof プラットフォームです。私たちはプロジェクト側に検査を受けるよう求めていますが、自分たちも検査を受けるべきです。これは一方通行の要求であるべきではありません。

コインとプラットフォームについて話しましたが、次はアカウントについてです。

私たちの提案は、「最も安全な場所」を探すのではなく、使用頻度に応じて資金を分散して置く方が現実的だということです。頻繁に取引するものは現物アカウントに置いて、いつでも使えるようにします。半年や一年動かさないものは Gate 金庫に入れます。

金庫は MPC と