CVE-Factoryは、完全自動化されたエンドツーエンドのCVE再現のためのマルチエージェントシステムです。CVEレコードを入力すると、システムは自動的に詳細を調査し、テストケースを生成し、Docker環境を構築し、各脆弱性が悪用可能かつパッチ可能であることを検証します。このパイプラインは、人手を介さずにCVEメタデータを再現可能でテスト可能な脆弱性環境に変換します。

⚠️ セキュリティ警告: このシステムは、脆弱性のあるソフトウェアを含むDockerコンテナをビルドして実行します。CVEコンテナをホストシステムから隔離するために、必ず Docker-in-Docker (DinD) 環境 を使用してください。CVE-FactoryをホストのDockerデーモン上で直接実行しないでください。

📢 ニュース

• [2026-03-27] 3,181件の新しいCVEタスク環境 (Hugging Face)、18.8kのトレーニングトレースを持つ Abacus-cve-v1.1、および LiveCVEBench-verified & PatchEval-verified ベンチマークを追加。4つの新しいエージェント (Judger, Changer, Comparer, Expert)、3つのスキル (cve-test-generator, cheat-detect, cheat-detect-evaluate) を追加し、ツールアクセス制御を許可リストから拒否リストに切り替えました。詳細は 更新ノート をご覧ください。

✨ ハイライト

🤖 エンドツーエンドの自動化

CVEレコードを入力すると、完全なCVE再現環境が得られます。Terminal Bench 標準 に従い、生成された各タスクパッケージには以下が含まれます：

• 環境セットアップ: 脆弱性アプリケーションをホストする Dockerfile と docker-compose.yaml
• タスク設定: 構造化された指示説明を含む task.yaml (CVE-IDなし)
• リファレンス修正: 脆弱性をパッチする solution.sh
• 評価エントリ: 評価を開始する run-tests.sh

セキュリティタスク向けに特別に設計されており、テストロジックは次の2つに分割されています：

• test_func.py: 修正前後で基本機能が動作することを確認する機能テスト
• test_vuln.py: パッチ前は脆弱性が存在し、パッチ後に解決されることを検証するエクスプロイトテスト

手動調査も手動コーディングも不要 – 生のCVEメタデータから検証済み再現まで完全自動化。

生成されるアーティファクト構造:

CVE-2025-XXXX/
├── task.yaml              # 構造化タスクメタデータ
├── Dockerfile          # 脆弱性環境セットアップ
├── docker-compose.yaml # サービスオーケストレーション
├── task-deps/  
├── solution.sh            # 検証済みパッチ
└── test/
    ├── test_func.py       # 機能チェック
    ├── test_vuln.py       # 脆弱性エクスプロイトチェック
    └── run-tests.sh           # ワンクリック評価スクリプト

📊 実証済みの高い成功率

2025年の554件のCVEを対象とした大規模評価において、CVE-Factoryは499件のケースを再現することに成功し、90.1%の成功率を達成しました。さらに、成功した471ケースの厳格な専門家レビューにより、**312タスク（66.2%）**が完全かつ正確に再現されていることが確認されました！

同一の初期情報を使用したセキュリティ専門家との比較では、環境とソリューションの構築において約95%の検証合格率を達成し、自動化された脆弱性再現におけるエキスパートレベルの能力を示しました。

📂 オープンデータセット: cve_tasks/ ディレクトリに 1,000以上のCVEタスク環境 を公開しています：

• trainset/ (887タスク): Abacus-cve のトレーニングに使用。4,000以上の蒸留エージェントトレース は Hugging Face 🤗 にあり、これらのタスクから Claude Opus 4.5 と Mini SWE-Agent ハーネスを使用して生成されました。
• trainset-2/: 比較的簡単な難易度の追加タスク。トレーニングデータには含まれていません。
• 新規: さらに 3,181タスク が Hugging Face の cve_tasks_3k_compressed で利用可能（サイズ制限のため圧縮アーカイブ）、Abacus-cve-v1.1 のトレーニング用に 18.8kのエージェントトレース を含む。

🚀 トレーニング結果

CVE-Factoryトレースでのファインチューニングにより、セキュリティベンチマークで劇的な改善が得られます。Qwen3-32B は LiveCVEBench で 約6.8倍の改善（5.29% → 35.79%）、PatchEval で約4.2倍（5.66% → 23.58%）、さらには Terminal-Bench でも有意な向上（12.50% → 28.75%）を示し、強力なクロスタスク汎化能力を実証しています。

モデル	LiveCVEBench	PatchEval	Terminal-Bench	平均
Qwen3-32B (ベース)	5.29	5.66	12.50	7.82
Abacus-cve (本手法)	35.79	23.58	28.75	29.37
Qwen3-Coder-30B	10.58	9.91	13.75	11.41
Qwen3-Coder-480B	19.58	19.34	36.25	25.06
MiniMax-M2	24.87	19.34	37.50	27.24
Claude Sonnet 4	20.11	22.64	33.75	25.50
Claude Sonnet 4.5	34.39	28.77	45.00	36.05
Claude Opus 4.5	41.27	32.08	48.75	40.70

わずか4kトレースで、Abacus-cve (32B) は Qwen3-Coder-480B、MiniMax-M2、Claude Sonnet 4 を上回り、セキュリティタスクで Claude Sonnet 4.5 レベルに迫ります。

新規: 18.8kトレースでトレーニングされた Abacus-cve-v1.1 はさらなる向上を達成（LiveCVEBenchで+3.83、PatchEvalで+2.38）。拡張されたトレーニングデータについては cve_train_v1.1 をご覧ください。

🧠 自律型 Claude Code エージェント

固定の検索ワークフローや単純なツール使用ループとは異なり、各エージェントは完全な Claude Code セッションとして動作します。手順をハードコードするのではなく、各エージェントをその 役割（例：Analyzer）、目標（例：「脆弱性環境を構築する」）、リソース（例：特定のドキュメントへのアクセス）、および 検証方法（例：「check_env_ready を通過する必要がある」）によって定義します。エージェントは人間の開発者のように動作します：自律的にファイルを探索し、エラーをデバッグし、ログを読み、指定されたワークスペース内でソリューションを反復的に改善します。

⚡ 非同期同時処理

CVE-Factoryは複数のCVEを同時に処理できるように設計されています。各CVEパイプラインは非同期に実行されるため、高速なタスクは低速なタスクを待つことなく後続のステージに進みます。システムは非同期アーキテクチャを使用しており、特定のエージェントタイプごとに同時実行制限を分離できます。例えば、軽量な調査タスク（Analyzer）には高い制限を、リソース集約型のDockerタスク（Builder）には低い制限を設定できます。この柔軟性により、システムの過負荷を防ぎながら処理速度を最大化します。ステージレベルのタイムアウトにより、ハングしたプロセスが処理キューをブロックするのを防ぎます。

🧩 モジュラー型マルチステージパイプライン

パイプラインは6つの独立したステージで構成されており、個別に実行することも組み合わせて実行することもできます。

• フェーズ1 (Analyzer → Generator) は、CVE調査を実行し、Dockerを必要とせずにアーティファクトを生成します。

  ツール要件: Analyzerエージェントは web_search および web_fetch ツールに依存します。サードパーティのAPIプロバイダーを使用する場合は、これらの特定のツール機能をサポートしていることを確認する必要があります。

• フェーズ2 (Builder → Validator → Solver → Checker) は、Docker環境の構築と検証を処理します。環境構築から全体検証まで、エージェントはローカルファイルシステムとDockerデーモンのみと対話するため、ウェブ関連のツールは必要ありません。

各ステージは個別に呼び出すこともでき、再現プロセスを細かく制御し、特定のステージのデバッグを容易にします。

🏗️ アーキテクチャ

システムは6つのステージで構成されています：

ステージ	目的
情報収集	Analyzerが詳細を public.md と役割固有のドキュメント（for_generator.md など）に収集します。情報が不十分な場合は終了します。
ファイル生成	Generatorが論理コンポーネントを作成：task.yaml、テスト（test_func.py、test_vuln.py）、solution.sh、run-tests.sh、および docker-reqs.md ガイダンス。
環境構築	Builderが Dockerfile と docker-compose.yaml を生成し、厳密性を確保するために「ブラインドビルディング」（テスト/ソリューションにアクセス不可）で動作します。
脆弱性検証	Orchestratorが check_env_ready を介して test_vuln の FAIL + test_func の PASS を検証します。失敗した場合、Validatorエージェントが環境を修正します（最大3回のリトライ）。
解決策検証	Orchestratorが check_fix_ready を介して修正を検証します。両方のテストがPASSする必要があります。失敗した場合、Solverエージェントがソリューションまたは環境を調整します。
全体検証	Checkerエージェントが、check_cve_ready の結果に関係なく、エラーを処理するかQA（モックコード/データのクリーンアップ）を実行します。最終的なE2Eチェックで成功を確認します。

🚀 クイックスタート

🐳 1. Docker-in-Docker 環境のセットアップ

# 隔離されたDinD環境を起動（セキュリティに必須）
cd dev-env
docker compose up -d

# 開発コンテナに入る
docker compose exec cve-factory bash

詳細なDinD設定とトラブルシューティングについては dev-env/README.md を参照してください。

📂 2. CVE入力の準備

再現したいCVEを original_cves_md/ ディレクトリに配置します。ファイル名は CVE-YYYY-NNNNN.md の形式で、関連情報を含んでいる必要があります。これらの入力を準備するには、LiveCVEBench-Preview の cve-sampler を使用することをお勧めします。

# DinD開発コンテナ内
cd /workspace
pip install -r requirements.txt

# CVE入力ファイルの準備を確認
ls original_cves_md/