利益:
- 人工知能は監査人の範囲を拡大するが、それに代わるものではなく、カテゴリのスキャンや草案の発見に役立つことを理解する能力。
- 人工知能が元の脆弱性とビジネス ロジック エラーを見逃したこと、および流暢な「安全」ステートメントは保証ではないことを認識できること
- 重大度のレベルに応じて調査結果を分類し、最終的な承認と専門的責任は有能な監査人にあることを理解する能力。
セキュリティ監査 (スマート コントラクトの脆弱性の体系的な検査) は、Web3 の最も責任のある仕事です。監査人がたった 1 行でも見逃しただけで、数百万ドルの損失が発生する可能性があります。この単元では、AI を監査アシスタントとして使用する方法を学びます。手がかりの生成から調査結果の概要の作成までを学びます。しかし、最も重要な文はこれです。AI は制御しません。監査人の目を研ぎ澄ますアシスタントです。最終的な承認は専門的責任を負う有能な監査人が行います。
監査がセキュリティクリティカルである理由
監査報告書は、プロジェクトと投資家に「このコードはレビューされている」ということを安心させます。この保証が間違っている場合、プロトコルの悪用、資金の損失、プロジェクトの崩壊など、悲惨な結果が生じます。したがって、検査における AI の使用は、このモジュールの中で最も慎重な部分です。 AI は監査者の範囲を拡大します (より多くのパターンを呼び出し、より速く読み取ります) が、監査者に取って代わるものではありません。
なぜ通らないのでしょうか？なぜなら:
- AI は、トレーニング データにない固有の新しい脆弱性を認識できません。
- AI は、プロトコルのビジネス ロジックの欠陥、つまりコードは技術的には正しいが経済的に悪用可能であるという欠陥を見逃すことがよくあります。
- AI は流暢な言葉で「安全」と言うことで誤った安心感を与える可能性があります。これは最も危険な結果です。
AI を制御に使用するレイヤー
1. 初期スキャンとパターンリマインダー。 AI は、再入、アクセス制御、オラクル操作、フロントランニングなどの既知の脆弱性パターンをチェックリストのように検討します。これにより、監査人がカテゴリを見逃すことがなくなります。
2. コードの説明。 AI に複雑な機能を平易な言葉で説明することで、監査人はロジックをすぐに理解できます。ただし、説明は常にコードと比較されます。
3. 調査結果の草稿を書く。監査人が脆弱性を発見すると、AI はレポートの草稿 (説明、影響、提案された解決策) を作成する時間を節約します。
4. 反対仮説を生成する。 AIに「この機能をどのように悪用できるのか?」と尋ねます。 」と尋ねると、攻撃的な視点が思い出されます。
注意: AI が「このコードには脆弱性が見つかりませんでした」と言ったからといって、「このコードは安全である」という意味ではありません。不在の証拠は証拠の不在ではありません。 AI が何かを見つけられないからといって、監査人がその領域を調査する必要がなくなるわけではありません。
重大度レベルの検索
監査結果は重大度レベルに応じて分類されます。 AI はドラフトを生成するときにこのフレームワークを使用する必要があります。
レベル
意味
例
クリティカル
資金損失/ロックアウトが直接可能
リエントランシーによる資金の出金
高い
特定の状況では重大な影響が発生する
不正印刷（ミント）
中程度
限定的な影響または困難な状態
Oracle偏差による損失が小さい
低い
軽微なリスク、適正慣行違反
イベント放送がありません
情報
非セキュリティ、可読性
NatSpec の欠如
弱いプロンプト / 強いプロンプト
弱いプロンプト:
この契約は安全ですか?
この質問は、AI に「はい/いいえ」のような絶対的で不当な判断を強いることになりますが、これはまさに私たちが望んでいないことです。
強力なプロンプト:
あなたの役割: 上級スマート コントラクト監査人のアシスタント。セキュリティのために次の契約をスキャンします。次のカテゴリを 1 つずつ検討します: 再入可能、アクセス制御、整数演算、入力検証、Oracle/外部データ、フロントランニング、ガス制限。各調査結果: (1) 関連するコード行、(2) 原因リスク、(3) 推定重大度 (重大/高/中/低)、(4) 解決策の提案。これらは確認されるべき仮説です。 「安全」という判定を下さないでください。不明な点は「監査人に確認してください」と明記してください。
コピー可能な 4 つのテンプレート
1) カテゴリベースのブラウジング:
このコントラクトをスキャンして、再入可能、アクセス制御、整数オーバーフロー、入力検証、オラクル依存関係、フロントランニング、DoS/ガスのカテゴリを調べます。カテゴリごとに、「リスクはあります/リスクはありません/よくわかりません」と述べ、その理由をコード内の行に結び付けます。最終的な判断をしないでください。
2) 攻撃者の観点からの反仮説:
攻撃者の立場になって考えてみましょう。この機能を悪用するにはどのような方法があるでしょうか?各シナリオを段階的に記述し、どのような条件が必要かを示します。これらのシナリオはテストされる仮説です。実際のエクスプロイト コードを生成せず、リスクを説明するだけにしてください。
3) 調査結果報告書草案:
次の検証済みの結果を正式な監査言語で報告します: タイトル、重大度、説明、影響、影響を受けるコード、再現手順、提案された解決策。慎重かつ専門的な言葉を使用します。過言。所見は監査人によって確認されたものとみなし、新たな所見をでっち上げないでください。
4) 修正検証:
以下は脆弱性と開発者によって適用された修正です。修正によって実際に脆弱性が解消されるかどうかを調べます。新しい副作用や脆弱性が生じるかどうかをマークします。絶対に「閉店」とは言わないでください。 「テストで確認する必要がある」で終わります。
ミニケース 3個（個数）
ケース 1 — AI がカテゴリーホッピングを防止しました。監査人は 400 行の契約に焦点を当て、オラクル カテゴリをスキップしようとしていました。 AIのカテゴリースキャンでは、「価格データは単一ソースからのものであり、操作される可能性がある」という警告が発せられた。監査人がそれを調査したところ、確かに中程度のリスクであることがわかりました。教訓: AI は報道規律を維持します。
ケース 2 — 誤った「安全」保証。別のチームはAIに「これは安全ですか？」と尋ねました。彼は尋ねた。 AIは「重大な問題はないようだ」と述べた。乗組員検査は軽めでした。その後、独立監査人はビジネス ロジックの欠陥、つまり技術的には正しい計算であるが、そのインセンティブが悪用可能であることを発見しました。教訓: AI はビジネス ロジック エラーを見逃します。彼が「安全」と言うのは信用できない。
ケース 3 — レポートの作成に 3 時間を節約しました。監査人は 8 件の発見事項を手作業で報告するのに半日を費やしていました。検証された結果を AI に渡し、正式な草案を印刷すると、時間が最大 3 時間短縮されました。監査人は時間をかけて深めました。教訓: 調査結果は人間によってすでに検証されているため、AI は安全かつ効率的にレポートを作成できます。
ビジネス ロジックの脆弱性: AI の盲点
最も高価な脆弱性は、多くの場合、コード内の技術的なエラーからではなく、ビジネス ロジックの悪用可能性から発生します。たとえば、報酬口座の丸め込み悪用、フラッシュ ローンによる投票のハイジャック、価格の瞬間的な操作などです。これらは、コードは「正しく」動作しますが、プロトコルは経済的に騙される可能性があるケースです。 AI はそのようなエラー、特にプロトコル固有のエラーを見逃す可能性があります。したがって、ビジネス ロジックのレビューは、監査人にとって最も人力が集中する領域であり、AI への依存度が最も低い領域です。
ヒント: AI に「このプロトコルの経済的インセンティブはどのように活用できるでしょうか?」と尋ねます。そして、思いついたシナリオを出発点として使用します。ただし、実際の分析はあなたとあなたのチームが行う必要があることに注意してください。
よくある間違い
- AIに「安全ですか？」と尋ねます。尋ねて、あなたの「はい」を信頼してください。絶対的な判断は必要ありません。
- AIが「見つかりませんでした」と言うとレビューを中止します。欠席は証拠にならない。
- ビジネスロジックのレビューをAIに委任する。それは彼の最大の盲点だ。
- 独立したツール（Slitherなど）は使用しません。 AIだけでは十分ではありません。
- AIが作り上げた発見を検証せずにレポートに載せる。幻覚の危険性。
- AIに制御責任を負わせようとしている。責任は専門家にあります。
要約すると
- 監査は安全性を重視します。 AI は監査人の範囲を拡大しますが、それに代わるものではありません。
- AI は元の脆弱性とビジネス ロジックのバグを見逃します。 「安全」と言っても保証はありません。
- 調査結果は重大度レベルに応じて分類されます。 AIは原稿作成に役立ちます。
- 対抗仮説とカテゴリー スクリーニングは、包含の規律を維持します。
- 最終的な承認と専門的責任は常に有能な監査人にあります。
アプリケーションタスク
既知の脆弱性を含むサンプル契約を見つけます (教育目的のために、「脆弱な契約」の例がオープンソースで入手可能です)。 「カテゴリベースのスキャン」プロンプトを AI に適用します。 AI が (1) 本当の脆弱性を発見したか、(2) 捏造/虚偽の発見を生成したか、(3) 「安全である」などの絶対的な判断を下したかに注目してください。次に、静的解析ツールと比較します。
チェックリスト
- [ ] AI に「安全ですか?」と尋ねます。代わりに、カテゴリベースのスキャンを実行しました。
- [ ] 私はそれぞれの発見を仮説として扱いました。
- [ ] 私は自分自身/チームでビジネス ロジックのレビューを行いました。
- [ ] 独立した静的解析ツールを使用して相互検証しました。
- [ ] AIが所見を捏造しないことを確認しました。
- [ ] 所見を重症度に応じて分類しました。
- [ ] 最終的な承認は管轄の監査人にあることを受け入れました。