RuleForge: Web 脆弱性検出のための大規模自動化生成と検証の技術的概要

本論文は、AWS 社内で開発された「RuleForge」というシステムを紹介するものです。このシステムは、膨大かつ急速に増加する共通脆弱性識別子（CVE）の検出ルールを、人手に頼らず大規模に自動生成・検証することを目的としています。以下に、問題定義、手法、主要な貢献、結果、および意義について詳細にまとめます。

1. 背景と課題 (Problem)

現代のサイバーセキュリティ環境では、新たな脆弱性の発見速度が、検出メカニズム（ルール）の開発速度を大きく上回っています。

• 課題: 2025 年、米国国立脆弱性データベース（NVD）には 48,000 件以上の新しい脆弱性が登録されました。これに対し、セキュリティチームが手動で検出ルールを作成する能力には限界があり、2025 年の高深刻度脆弱性の数は、内部チームが手動で対応できる数の 15 倍以上に達しました。
• ボトルネック: 既存のオープンソースツール「Nuclei」は構造化されたテンプレート（YAML 形式）で脆弱性を記述できますが、これをクラウド規模で運用可能な検出ルール（JSON 形式）に変換し、本番環境に展開するプロセスは依然として手動であり、時間とリソースを要します。
• 要件: 検出ルールは、悪意のあるリクエストを見逃さないこと（高リコール）と、正常なリクエストを誤ってブロックしないこと（高精度）の両方が求められます。特に、誤検知（False Positive）は一般ユーザーを攻撃者と誤認させるため、精度が最優先事項です。

2. 手法とアーキテクチャ (Methodology)

RuleForge は、生成 AI（Amazon Bedrock を通じた LLM）を活用し、Nuclei テンプレートから直接検出ルールを生成する自動化パイプラインです。

2.1 システムアーキテクチャ

システムは以下の 4 つの主要コンポーネントで構成されます。

1. CVE リポジトリ: Nuclei テンプレートから CVE データを週次で取得し、脅威インテリジェンス（CISA KEV など）に基づいて優先順位付けを行います。
2. ルール生成エンジン: AWS Fargate と Amazon Bedrock（DSPy フレームワーク利用）上で稼働。各 CVE に対して、異なる設定（温度パラメータなど）で5 つの並列候補ルールを生成します。
3. 検証パイプライン: 生成されたルールが本番環境に耐えうる品質かを確認する 5 段階のプロセス。
4. フィードバック統合: 検証失敗や人間によるレビューからのフィードバックをループし、ルールの品質を継続的に改善します。

2.2 主要な戦略

• 5×5 生成戦略: 1 つの CVE に対して 5 つの並列候補を生成し、それぞれが最大 5 回までの反復的改善（リファインメント）を行うことで、高品質なルールの出現確率を最大化します。
• LLM-as-a-Judge（裁判官としての LLM）: 従来の合成テストに加え、LLM に「裁判官」としてルールと CVE のペアを評価させる新しい検証手法を導入しました。

2.3 検証パイプラインの詳細

1. 合成テスト: 7 つの悪意あるリクエストと 3 つの正常なリクエストでテストし、8/10 以上の正解率を要求します。
2. LLM-as-a-Judge による信頼性スコアリング:
   • LLM に「このルールが特定の CVE 記述の悪意あるリクエストを見逃す確率（False Negative）」と「脆弱性そのものではなく、関連する特徴を誤って検知する確率（False Positive）」を質問します。
   • これらを「感度（Sensitivity）」と「特異度（Specificity）」のスコアに変換し、総合的な信頼度スコアを算出します。
   • スコアが閾値（感度 0.5、特異度 0.7）を下回る場合、その理由（推論）をフィードバックとして生成エンジンに返し、ルールの再生成を促します。
3. IP 検証: 本番トラフィック（月間 50 億件のサンプリング）に対してルールを実行し、マッチした IP の 70% 以上が悪意あるもの（MadPot 等による評価）であるかを確認します。
4. IP 増強: マッチした IP の脅威インテリジェンスとの照合。
5. 人間によるレビュー: 最終的にセキュリティエンジニアによるコードレビューを行い、承認されます。

2.4 拡張機能（研究段階）

• 非構造化データからの生成: Nuclei テンプレートに依存せず、ブログ記事や NVD 記述などの非構造化データからルールを生成する試み。
• エージェントワークフロー: 複数のイベントタイプ（HTTP, Process, DNS, CloudTrail）に対応するため、ReAct アーキテクチャを用いたエージェントが適切なルール生成ツールを選択・実行する Proof of Concept。

3. 主要な貢献 (Key Contributions)

1. LLM-as-a-Judge による信頼性検証システム:
   • 単なるパス/フェイル判定ではなく、感度と特異度という 2 次元でルールの品質を評価し、その理由（推論）を生成プロセスにフィードバックする仕組みを確立しました。
   • これにより、LLM の過信（Overconfidence）を抑制し、人間のような専門的な評価に近い推論を可能にしました。
2. フィードバック駆動型の反復的改善:
   • 5 つの並列候補生成と、検証結果に基づく最大 5 回のリファインメントを組み合わせた戦略により、単一生成アプローチよりも遥かに高い成功率を達成しました。
3. 非構造化データとエージェントワークフローの探求:
   • 構造化データへの依存を脱却し、より広範な脆弱性情報源からのルール生成や、多様なイベントタイプへの対応可能性を実証しました。

4. 結果 (Results)

2025 年 8 月以降の本番環境での運用データに基づき、以下の成果が得られました。

• 生産性の向上: 人手によるルール生成と比較して、336% の生産性向上を達成しました。
• 誤検知の削減: LLM-as-a-Judge による検証とフィードバック統合を導入した結果、合成テストのみの検証と比較して誤検知（False Positives）が 67% 減少しました。
• 無効ルールの削減: IP 一致率が 0 のルールが71% 減少しました。
• 評価指標:
  • LLM-as-a-Judge システムの AUROC（受動者動作特性曲線下面積）は 0.75 を達成し、良いルールと悪いルールの識別能力を示しました。
  • 期待較正誤差（ECE）は 0.17 で、スコアの較正性が比較的良好であることを示しています。
• 非構造化データの実証: 10 件の脆弱性データ（NVD、GitHub、ブログ）を用いた PoC では、生成されたルールのうち 50% が人間による評価で「使用可能（修正または低信頼度で可）」と判定されました。

5. 意義と教訓 (Significance & Lessons Learned)

• セキュリティにおける AI 活用の指針:
  • 過信の抑制: LLM はセキュリティタスクにおいて過信しやすい傾向があるため、生成時に「自信」を問うのではなく、「欠陥を見つける（批判者として振る舞う）」ようプロンプトを設計することが重要であることが示されました。
  • ドメイン知識の重要性: 評価プロンプトの設計には人間の専門家の知見が不可欠であり、専門家の思考プロセスを模倣させることで評価精度が向上します。
  • 人間と AI の協調: 完全自動化ではなく、多段階の検証（自動化テスト＋人間による最終レビュー）を組み合わせることで、本番環境での信頼性を担保できることが実証されました。
• 将来展望:
  • RuleForge は、脆弱性開示から対策までのギャップを埋めるための重要な自動化プラットフォームとして進化しています。今後は、非構造化データ処理の精度向上や、マルチモーダル（HTTP 以外のイベント）な脆弱性対策への展開が期待されます。

総じて、RuleForge は生成 AI を活用して大規模なセキュリティ脅威に対処する際の、実用的かつ高品質な自動化ソリューションの成功事例を提供しています。