利益:
- 再入、アクセス制御、オラクル操作、フロントランニングなどの一般的な脆弱性パターンを認識し、静的分析ツール + 人工知能 + 人間を使用してそれらをスキャンする機能
- ツールの出力を説明し、MEV とビジネス ロジックの誤検知と弱点に優先順位を付ける際に、AI の強みを区別する能力
- 「クリーン スキャン」はセキュリティ証明書ではなく、スキャンは制御の 1 層にすぎないことを理解する
前の単元では、監査の全体的な規律について説明しました。この単元では、より技術的なトピックである脆弱性スキャン、つまりコード内の既知の脆弱性パターンを体系的に検索することに焦点を当てます。ここでは、既知の脆弱性パターンをスキャンして説明するアシスタントとして AI を静的分析ツールと組み合わせて使用します。目標は、最も一般的な脆弱性を詳しく知り、AI が信頼できる部分とスキャンが不十分な部分を区別することです。
静的および動的スキャン
スキャンには2種類あります。静的分析 — コードを実行せずに検査する: Slither や Mythril などのツールはコントラクト コードをスキャンし、既知のパターンにフラグを立てます。動的/シンボリック分析 (さまざまな入力でコードを実行する、または数学的に探索する): ファジング (ランダムな入力を大量に入力する) およびシンボリック実行 (考えられるすべてのパスを探索する) がこのグループに分類されます。
AI はこれらのツールを置き換えるのではなく、それらを補完します。車両が警告を発すると、AI は警告を平易な言葉で説明します。 AI は、ツールがパターンを見逃したときにリマインドすることができます。ただし、AI だけではスキャン量を保証できません。適切なワークフロー: ツール + AI + 人間。
ヒント: AI に静的分析ツールの出力 (Slither レポートなど) を与え、「各アラートをわかりやすい言葉で説明してください。どれが本当のリスクで、どれが誤検知の可能性がありますか?」と尋ねます。聞く。 AI は、生のツールの出力を人間が理解できるようにし、優先順位を付けられるようにする上で非常に貴重です。
最も一般的な脆弱性パターン
1. 再入可能。関数が状態を更新せずに外部コントラクトを呼び出した場合、呼び出されたコントラクトは戻って同じ関数を再度トリガーし、資金を複数回引き出すことができます。解決策: チェック、効果、インタラクションの順序と再入ガード。
2. アクセス制御の欠如。重要な機能 (引き出し、撤退、アップグレード) が誤って公開されてしまいます。これは最も一般的で、高くつく間違いの 1 つです。
3. Oracle の操作。契約は外部の価格ソース (オラクル) に盲目的に依存します。攻撃者は価格を瞬時に操作し、プロトコルを欺きます。解決策: 時間加重平均価格 (TWAP)、マルチソース。
4. 整数のオーバーフロー/アンダーフォール。数値が最大許容値を超えて最初に戻った場合。最新の Solidity はそのほとんどを自動的に検出しますが、リスクは低レベル (アセンブリ) コードに残ります。
5. フロントランニング。トランザクションは確認される前にパブリック プール (mempool) に表示されます。攻撃者はあなたのトランザクションを見て、その前に自分のトランザクションを挿入することができます。 MEV (Maximal Extractable Value — トランザクション シーケンスから抽出された値) は、この主題の一般名です。
6. サービス拒否 (DoS)。ループのコストが高くなりすぎて関数が使用できなくなったり、アドレスへの依存関係がロックされたりします。
7. アップグレードのリスク。ストレージの衝突とアップグレード可能な契約における権限の乱用。
脆弱性
AIスキャンの信頼性
なぜ
再入可能
高い
よく知られた明確なパターン
アクセス制御
高い
金型をスキャン可能
整数演算
高い
標準制御
オラクルの操作
中程度
コンテキストが必要です
フロントランニング/MEV
中～低
プロトコル固有の
ビジネスロジックエラー
低い
本物、状況に応じた
弱いプロンプト / 強いプロンプト
弱いプロンプト:
このコードに抜け穴はありますか?
強力なプロンプト:
あなたの役割: セキュリティ検査アシスタント。以下の契約を調べて、再入、アクセス制御、整数演算、oracledependency、フロントランニング、DoS、セキュリティのアップグレードの既知のパターンと、それぞれの「リスクがある/なし/不明」を調べます。各決定を関連する行にリンクし、リスクがある理由を説明します。これらは、静的分析ツールと監査人を使用して検証される仮説です。誤検知が発生する可能性があることに注意してください。
コピー可能な 4 つのテンプレート
1) ツール出力の説明:
以下は静的解析ツール（Slither）のレポートです。各アラートをわかりやすい言葉で説明します。それは何を意味するのか、それは実際のリスクなのか、それとも誤検知の可能性があるのか、何を優先すべきなのか。しっかりとした決断をしないでください。監査人の確認を優先します。
2) 再入に重点を置いたスクリーニング:
このコントラクトで外部呼び出しを行うすべての関数を検索します。それぞれのチェック - 効果 - インタラクションの順序に従っているかどうか、および再入可能ガードがあるかどうかを調べます。危険なものを線で示します。よくわからない場合はマークしてください。エクスプロイトコードを生成しています。
3) アクセス制御マップ:
このコントラクト内のすべての外部/パブリック関数をリストし、それぞれに「呼び出すことができる人」(全員/所有者/役割) を指定します。重要な操作 (引き出し、印刷、アップグレード) を実行し、それらの操作に弱いアクセス制御をマークします。表とともに提示します。
4) 誤検知の排除:
このスキャン警告が実際のリスク (誤検知) ではない理由を検討してください。この警告が無効になるコンテキストまたはコード条件は何ですか?しかし、「まったく問題ない」とは言わないでください。確認が必要な点を列挙します。
ミニケース 3個（個数）
ケース 1 — 車両 + AI により効率が 2 倍になりました。あるチームは 12 件の契約プロジェクトで Slither を実行し、140 件の警告を受けました。 AI にアラートの説明と優先順位を付けさせたところ、140 件のアラートのうち 95 件が誤検知であることが判明しました。チームは45人の実際の候補者に焦点を当てた。トリアージ時間は 2 日から 5 時間に短縮されました。教訓: AI は車両の出力を人間化するのに強力です。
ケース 2 — AI が MEV をハイジャックした。 DEX (分散型取引所) コントラクトでは、AI は標準パターンがクリーンであることを発見しましたが、最前線の脆弱性を検出できませんでした。これはプロトコルの操作順序に固有のものであるためです。人間の監査とシミュレーションをキャプチャ。教訓: MEV/フロントランニングなどのプロトコル固有のリスクは AI の弱点です。
ケース 3 — 誤検知による時間の無駄を回避しました。 AI が再入警告が実際には誤検知である (関数はすでに保護されていた) と説明したため、チームは不必要な書き換えを免れました。しかし、チームは 1 回のテストでそれを確認しました。教訓: AI は優先順位を付ける。確認にはテストが伴います。
スキャンの限界
スキャンにより既知のパターンが見つかります。ツールも AI も、新しい固有の脆弱性またはプロトコル固有の脆弱性を検出することは保証されていません。したがって、スクリーニングは監査の一部です。彼自身ではありません。 「スキャンがクリーンだから安全である」という考えは、この分野における最も危険な誤解の 1 つです。浚渫は簡単に実現できる成果を上げます。深くて独特なリスクの場合、人間の専門知識、テスト、ファジング、正式な監査が不可欠です。
注意: スキャン ツールまたは AI の「クリーン」レポートはセキュリティ証明書ではありません。そのように提示することは、特に投資家に対しては誤解を招き、非倫理的です。
よくある間違い
- 検査の代わりにスクリーニングを行うこと。スキャンは 1 つのレイヤーであり、全体ではありません。
- ツールを使わずに AI を活用する。静的解析＋AI＋人間の連携。
- 確認なしの誤検知を排除します。各画面はテストされ、人間による検証が行われます。
- AI を活用することでプロトコル固有のリスク (MEV) を回避します。 AIの苦手分野。
- 「きれいにスキャン」＝「安全」と考えます。未知のものを見つけることはできません。
- エクスプロイトコードを生成しています。防御的リスクの説明のみが正当です。
要約すると
- 脆弱性スキャンでは、車両 + AI + 人間を使用して既知の脆弱性パターンを探します。
- AI は、静的分析ツールの出力を説明し、優先順位を付けるのに強力です。
- 再入性やアクセス制御などの明確なパターンで信頼性が高くなります。 MEVとビジネスロジックが苦手。
- 誤検知を排除するにも確認が必要です。
- 「クリーン スキャン」はセキュリティ証明書ではありません。監督に代わるものではありません。
アプリケーションタスク
(可能であれば) サンプル コントラクトに対して静的分析ツールを実行するか、既製の Slither レポートを見つけます。 「ツール出力の説明」プロンプトを AI に適用します。 AI が (1) 警告を正しく説明するか、(2) 誤検知を区別するのに意味があるか、(3) プロトコル固有のリスクを見逃すかどうかを評価します。表の「車両発見/AI説明/人間確認」の欄に記入します。
チェックリスト
- [ ] ハッチをコントロールのレイヤーとして配置しました。
- [ ] 静的解析ツール＋AI＋人間を併用しました。
- [ ] 既知のパターンをカテゴリごとに検索しました。
- [ ] 確認により誤検知を排除しました。
- [ ] MEV/ビジネスロジックなどの苦手な分野は人間に頼っていました。
- [ ] 私は保証として「完全な一掃」を提供したわけではありません。
- [ ] 私は防衛のためだけに働いていました。私はエクスプロイトを作成しませんでした。