テクニカルサマリー：ワークフローにおけるセキュリティ – 脆弱性処理のためのロールベース・エージェンティック・アーキテクチャの探求

問題提起

産業界におけるセキュアなソフトウェアエンジニアリングは、脆弱性分析、修正、および修正検証という、構造化された多段階のワークフローで構成されています。しかし、現在の大規模言語モデル（LLM）を用いたソフトウェアセキュリティへのアプローチは、検出やパッチ生成といった孤立したタスクに焦点を当てがちであり、現実世界のセキュリティプロセスで使用されるエンドツーエンドのエージェンティックなワークフローを反映しているとは言えません。これにより、既存のLLM手法と、実用的なセキュアソフトウェアエンジニアリングとの間に乖離が生じています。特にCやC++のような低レベルのシステム言語において、この傾向は顕著です。これらの言語では、脆弱性は複雑なメモリセマンティクス、ポインタ操作、バッファ管理に依存するため、LLMにとって診断と修正は困難な課題となります。さらに、ツール拡張型のエージェンティックなワークフローや、Model Context Protocol (MCP) によるスキル統合に関する、これらの低レベルなコンテキストに特化した探索も限られています。

メソドロジー

著者らは、脆弱性処理を「調査計画」、「脆弱性分析」、「パッチ生成」、「修正検証」という明示的なステージに分解するように設計された、ロールベースのエージェンティックなワークフローを提案し、評価しています。

ワークフロー設計

本研究では、CrewAIフレームワークを用いて、3つのオープンソースLLM（nemotron-cascade-2:30b、qwen3-coder-next、gpt-oss:120b）でインスタンス化された2つのワークフロー・バリアントを実装しています。ワークフローは以下の4つの異なる役割で構成されます。

1. Planner（プランナー）: 正規表現を用いて入力されたCコードを事前定義された脆弱性パターン（例：バッファオーバーフロー、ヌルポインタ参照）でスキャンする、ルールベースの静的モジュール（LLMではない）。Analyzerを導くための優先度の高い調査領域とテーマを出力します。
2. Analyzer（アナライザー）: 技術的な診断を担当するLLMエージェント。主要な脆弱性を特定し、共通脆弱性タイプ一覧（CWE）IDを割り当て、脆弱な行を特定し、根本原因を説明し、ソースからシンクへのフローを追跡します。
   • Workflow 1: AnalyzerはPlannerのガイダンスのみに依存します。
   • Workflow 2: AnalyzerはMCP CodeQL統合によって拡張され、診断中に静的解析機能を提供します。
3. Fixer（フィクサー）: Analyzerの診断に基づき、最小限の安全なパッチを生成するLLMエージェント。再診断を避け、パッチとその簡潔な説明のみを生成するように制約されます。
4. Verifier（ベリファイア）: 生成されたパッチが特定された脆弱性を解決しているか、根本原因を除去しているか、およびデグレ（退行）を導入していないかを評価する独立したLLMエージェント。

実験設定

• データセット: 5つのCWEカテゴリ（CWE-787: Out-of-bounds Write、CWE-476: Null Pointer Dereference、CWE-190: Integer Overflow、CWE-125: Out-of-bounds Read、CWE-191: Integer Underflow）にわたる、厳選された25件の実世界のC/C++ CVE（共通脆弱性識別子）。
• グラウンドトゥルース（正解）: National Vulnerability Database (NVD) の記述および開発者が提供したパッチ済みコードから派生。
• 評価: 2人の著者による、グラウンドトゥルースと比較した手動のルーブリックベースの評価（Cohen's kappa $\kappa = 0.83$）。指標には、検出精度（CWE割り当て、行特定、根本原因）および修正精度（信頼できる修正との意味的類似性）が含まれます。
• スコープ: 本研究は、大規模なベンチマークではなく、150回のワークフロー実行（25 CVE $\times$ 3 モデル $\times$ 2 バリアント）に焦点を当てた、探索的かつ手法指向の評価です。

主な貢献

1. ロールベース・エージェンティック・アーキテクチャ: 計画、分析、修正、検証を分離したエンドツーエンドのワークフローを提案・評価し、明示的な役割の分離がいかにセキュリティ活動を構造化できるかを実証しました。
2. 静的プランナーの設計: 産業界に関連するCプロジェクトにおける脆弱性調査を導くためのルールベースのプランナーを実装し、それが検出の質に決定的な影響を与えることを示しました。
3. 精選されたリファレンスセット: グラウンドトゥルースのメタデータ、開発者による修正、LLM生成の出力を含む、25件の実世界のC/C++脆弱性インスタンス、および再現性のためのオープンソースのCrewAIフレームワークコードを提供します。
4. ツール統合の分析: マルチエージェント・ワークフローの分析ステージに、MCPベースの静的解析（CodeQL）を統合することの有効性を調査しました。

結果

本研究は、以下のパフォーマンス指標を報告しています（比較用の主要モデルとしてnemotron-cascade-2:30bを使用）：

• 検出精度:
  • Workflow 1 (CodeQLなし): 44% の検出精度を達成し、GPT-5.5のベースラインに匹敵しました。
  • Workflow 2 (CodeQLあり): 精度が**31%**に低下しました。これは、エージェントがツールのヒントを正しく解釈または優先順位付けできない場合、ツール統合だけでは改善を保証できないことを示唆しています。
  • アブレーション（要素除去）: Plannerを削除すると、検出精度は（CodeQLなしで25%、CodeQLありで**19%**に低下し、Plannerの決定的な役割が浮き彫りになりました。
• 修正精度:
  • 全体的な修正精度は、Workflow 1で19%、Workflow 2で**13%**と低迷しました。
  • 修復は検出よりも著しく困難であることが判明しました。一部のパッチはグラウンドトゥルースと「同等」あるいは「より優れて」いましたが（特にCWE-476およびCWE-787）、多くは不要なロジックを含んでいたり、新たなバグを導入したりしていました。
• Verifier（検証）精度:
  • Verifierはnemotron-cascade-2:30bにおいて**69%**の精度を達成しており、生成よりも事後的な修復評価において強い能力があることを示しました。
• CWEの変動性:
  • CWE-787とCWE-476は最も検出しやすく、一方でCWE-191（Integer Underflow）はすべてのモデルと設定を通じて最も困難な課題であり続けました。

意義と主張

本論文は、本研究を決定的なベンチマークではなく、初期の探索的研究として位置付けています。その主な意義は以下の通りです：

• プロセスの改善: セキュリティタスクを構造化されたロールベースのステージ（計画、分析、修正、検証）に分解することで、セキュリティ活動をより再現可能かつ透明にできることを実証しました。
• Human-in-the-Loop（人間による介入）の必要性: LLMの進歩にもかかわらず、生成されたパッチの質のばらつきや、ツール統合の混合した有効性は、セキュリティクリティカルな環境における継続的な人間の監視が必要であることを裏付けています。
• モデルよりもワークフロー: 「最高のモデル」を選択することから、基礎となるワークフローのアーキテクチャと統合技術を洗練させることへと焦点を移しています。著者らは、モデルのスクリーニングは不可欠であるものの、ワークフロー設計自体が改善のための主要なレバーであると述べています。
• ツール統合のニュアンス: CodeQLのようなツールを統合するには、ヒントを正しく優先順位付けできるように注意深いエージェント設計が必要であることを強調しています。単にツールを追加するだけでは、性能は自動的には向上しません。

著者らは、ロールベースのエージェンティックなアーキテクチャは、セキュアなソフトウェアプロセス向上のための有望な方向性であり、より大規模なデータセット、リポジトリレベルの分析、および洗練されたワークフローの代替案（複数のアナライザーやリファインメント・ループなど）に関する将来の研究を動機付けるものであると結論付けています。