ai-ml

脆弱性トリアージのためのマルチエージェント・ディベート

数ヶ月前、私たちはあるfindingを偽陽性としてクローズしました。それはSSRFに対して脆弱に見えるエンドポイントでした:ユーザーからURLを受け取り、バックエンドで処理し、コンテンツを返します。私たちのシングルモデル・パイプラインは、それを「偽陽性の可能性が高い — URLは許可リストに対して検証されているように見える」とマークしました。私たちはそれを見逃しました。

3週間後、クライアントから連絡がありました:外部の研究者がまさにそのエンドポイントを報告したのです。許可リストのバイパスは些細でした(URLのuserinfo内の@を使ったトリック)。イメージへのダメージ、気まずい会話、そして教訓:単一モデルは悪いトリアージャーだ、特に証拠が曖昧な場合は。

なぜ単一モデルは悪いトリアージャーなのか

  • コンテキストへの追従性。Sharma et al. (2023) は、現代のモデルはユーザーが客観的に間違っている場合でも同意することを示しています。
  • 最初の仮説への固執。Liang et al. (2023) はこれをDegeneration-of-Thoughtと呼びます:もっともらしい解決策が固定されると、モデルは真の代替案を生成しません。
  • 敵対的チェックの欠如。人間のトリアージャーは「この検証をどう破るか?」と考えます。zero-shot LLMは「これは妥当か?」と考えます。

Self-consistency (Wang et al., 2022) はノイズを軽減しますが、体系的バイアスは軽減しません。

マルチエージェント・ディベート:Du et al. (2023)

Improving Factuality and Reasoning through Multiagent Debate が提案するのは:複数のインスタンスが独立して応答し、その後、各エージェントが他のエージェントの応答を受け取り、条件付けされた新しい応答を生成します。これをN回繰り返します。出力:コンセンサスまたは投票。

興味深いのは、fine-tuningも外部の審判も特別なアーキテクチャも必要としないということです。プロンプティングです。改善は、各エージェントが反対の議論を見ると、孤立した状態では当然と思っていた推論の部分を見直すことから来ます。

私たちの実装:3つの役割、3ラウンド、1人の審判

  • Gandalf — 批判モード。findingが本物であると仮定し、最悪の悪用シナリオを構築します。
  • Beorn — 証拠モード。アーティファクトについてのみ推論します:HTTPレスポンス、ヘッダー、ボディ、トレース。実証されていない動作の推論を禁止しています。
  • Gwaihir — 技術モード。アーキテクチャについて推論します:スタック、フレームワーク、既知の防御、セクターコンテキスト。

3者は同じパッケージを受け取ります。ラウンド1で独立した判定を生成します。ラウンド2-3では、各自が他者を見て、改訂版を作成します。審判エージェントがクロージングを発行します:true_positivefalse_positiveneeds_manual

ラウンド2後に3者が収束した場合、ラウンド3をスキップします。ラウンド3後も意見の相違が続く場合、人間にエスカレートします。このルールは意図的なものです — 直交する役割間の持続的な意見の相違は、情報的なシグナルです。

トレース例:SSRF候補

ラウンド1 — 独立した判定:

Gandalf:「SSRFの可能性あり。フロントエンド(nginx)とは異なるServer: gunicornは、バックエンドがリクエストを行うことを示唆します。?url=http://169.254.169.254/は403を返しましたが、?url=http://localhost:8080はHTMLで200を返しました。高信頼度のtrue positive。」

Beorn:「2つのリクエスト:1つはバイパス付き(200)、もう1つはメタデータに対して(403)。403は許可リストかクラウドファイアウォールかもしれません。needs manual。」

Gwaihir:「AWS上のnginxの背後にあるPython + gunicornのスタック。403は強制IMDSv2と一致し、エンドポイントの緩和策とは一致しません。true positiveの可能性が高い。」

ラウンド2:

Gandalf:「403が緩和策の証拠ではないというBeornの指摘は正しい。しかしlocalhost:8080に対する200は確かに内部アクセスを実証しています。true positiveを維持します。」

Beorn:「再考します。200レスポンスには内部管理パネルのHTMLが含まれています。高信頼度のtrue positiveに変更します。」

Gwaihir:「同意します。@トリックのペイロードも許可リストを通過します。テストをレポートに追加することを推奨します。」

ラウンド2で収束。審判:true_positive。3つの異なる証拠ラインを持つレポート。

メトリクス

3ヶ月、1,847のfinding(412のground-truth):

  • true positivesでのPrecision:0.71(シングル)→ 0.89(ディベート)。
  • Recall:0.68 → 0.83。Recallはprecisionより重要です。
  • 中央値レイテンシ:finding当たり8秒 → 47秒。
  • トークンコスト:シングルモデルの約4.2倍。
  • 人間へのエスカレーション:3% → 11%。ディベートは真に曖昧なケースをより多く検出します。

ディベートを使わない場合

  • 明確な証拠を伴う低重大度(欠落しているセキュリティヘッダー)。決定論的チェックで十分です。
  • 些細な二項決定(これはAPI keyか?)。Regexまたはcritique付きsingle-call。
  • 高頻度パイプライン。コストが蓄積します。

クイック比較

CoT-SC:ノイズには良いが、体系的バイアスには悪い。
Tree of Thoughts:構造化された空間(Game of 24)には優れている。トリアージにはオーバーキル。
self-critique付きsingle-call:同じモデルが同じ仮説を批判し、同じ固定点に崩壊します。
マルチエージェント・ディベート:役割の多様性が必要で、証拠が曖昧な場合に勝利します。

結論

クライアントのSSRFが誤ってクローズされるべきではありませんでした。私たちが学んだことは、LLMが悪いトリアージャーであるということではなく — どんなに優れていても、単一のLLMは見方が1つしかないということです。よく定義された役割を通じて多様性を強制することはエレガントではありません;それは実用的なエンジニアリングです。あなたのパイプラインがディベートなしで曖昧なfindingsをクローズしているなら、おそらく真の脆弱性を見逃しているでしょう。

参考文献