論文解説: CyberFactory — 野生のCVEを「実行できる訓練問題」に変える

実世界のCVEを実行・検証できるタスクへ変換し、再利用可能な「脆弱性解析スキル」で教師の軌跡を合成してモデルに内面化させるオープンソース基盤。CyberGymで Pass@1 58.1%。

CyberFactory: Scaling Cyber Security Capabilities with Instances from the Wild

この論文が答えようとしている問い

原題は "CyberFactory: Scaling Cyber Security Capabilities with Instances from the Wild"（arXiv:2608.23181）です。

要旨はこうです。LLMのコーディング能力が伸びるにつれセキュリティ応用への注目も高まり、クローズドなモデルは高い能力を見せている。一方オープンソース側には3つの穴がある——最前線のオープンウェイトモデルは再現可能な学習手順を公開していない、既存のオープンな手法は課題ごとにバラバラでスケールするエージェント的データがない、そして試行をスケールさせるには強いドメイン事前知識が要る。そこで本論文は CyberFactory を提案する。データ構築・軌跡合成・モデル学習を、PoC生成／脆弱性パッチ／サイバーセキュリティQA（CyberQA）にまたがって1本につないだオープンソースの手順である。野生のCVEを含む公開の脆弱性資産を実行可能・検証可能なタスクへ変換し、再利用可能な「脆弱性解析スキル」で教師モデルを ソース調査 → ドメイン知識を使った問題解決 → 証拠に基づく検証 へ導く。教師信号はエージェント的で、モデルはツールと対象環境に触れ、実行フィードバックを見て解を直す。その軌跡で学習したモデル OpenAegis は、推論時にスキルを与えられなくても手順を再現し、CyberGym の1時間予算下で Pass@1 58.1%、ベースの Qwen 3.5 から 28.5 ポイント改善した。

比喩: 「鍵が開いた」ではなく「この鍵で開いた」を示す

セキュリティの自動化と聞くと、AIが総当たりで侵入する絵を想像しがちです。この論文がやっているのはむしろ科学実験の再現に近い作業です。

ある製品の古い版に欠陥があり、あとで修正されたとします。「本当にその欠陥を突けたのか」を証明するには、修正前のビルドでは壊れ、修正後のビルドでは壊れない入力を1つ持ってくればいい。修正後でも壊れるなら、別のバグを踏んだだけです。この二段構えなら、人間の判断を挟まずに機械が正解／不正解を決められます。

論文はこの「壊れる入力」を PoC（proof-of-concept） と呼び、二段構えの判定を差分オラクルと呼びます（§4.1）。「AIがセキュリティをやる」という曖昧な話を、採点可能な作業に落としたのが出発点です。

用語を先に4つ

• CVE: 公開された脆弱性1件ごとの通し番号。影響を受けるバージョン範囲などが付く。
• CWE: 「バッファオーバーフロー」のような欠陥の種類の分類。個別のCVEより抽象度が高い。
• サニタイザ: メモリ違反などを実行時に検出するようビルドへ埋め込む計測装置。論文では AddressSanitizer（ASAN）が登場します。
• OSS-Fuzz / ARVO: 大規模なオープンソースのファジング基盤と、そこから再現可能な脆弱性を復元したデータセット。論文は ARVO を「6,100件超の実脆弱性を復元したもの」として引いています（§2）。

仕組み(1): 正解を機械が決める式

候補入力 $x$、修正前ビルド $b^{-}$、修正後ビルド $b^{+}$ を使い、成功判定はこう定義されます（§4.1）。

記号を1つずつ読みます。$\mathrm{Crash}(b,x)$ は「ビルド $b$ に入力 $x$ を食わせたとき、狙ったサニタイザ違反が起きる」なら真。$\mathbf{1}[\cdot]$ はそれを1／0に変える箱。$\wedge$ は「かつ」、$\neg$ は「〜でない」。つまり式(1)は「修正前では落ちて、かつ修正後では落ちない、なら1点」と言っているだけです。

判定がプログラムで決まるので、エージェントは人手を待たずに自分で採点でき、サニタイザの出力を次の候補作りの手がかりにできる。論文はこれを「オラクルを改良の信号として使う」と表現し、生成しっぱなしではなく 提案 → 検証 → 修正 のループになると述べています（§4.1）。

# 論文が言う propose-verify-refine ループの骨格（擬似コード）
for _ in range(budget):
    x = agent.propose(codebase, description, feedback)
    crashed_pre  = run(build_pre,  x)      # 修正前で落ちるか
    crashed_post = run(build_post, x)      # 修正後で落ちないか
    if crashed_pre and not crashed_post:
        return x                            # V(x) = 1
    feedback = sanitizer_log(crashed_pre)   # 次の試行の材料

仕組み(2): 野生のCVEを「問題」に変える

学習データを作るには $b^{-}$ と $b^{+}$ が実際にビルドできて動く必要があります。論文は難易度の異なる3つの入手経路を挙げます（§3.1）。ARVO が最も易しく、OSS-Fuzz が中間、野生のCVEが最も難しい。ARVO からは修正前後のDockerイメージと正解PoCの組が直接得られます。OSS-Fuzz は脆弱性を作り込んだコミットしか分からないことがあるので、ARVO と同じ二分探索で修正コミットを特定します。

野生のCVEには影響バージョン範囲とCWEなどのメタ情報しかありません。そこで3段階を踏みます。まずCWEが付いたCVEだけ残す。次に影響バージョン範囲から修正コミットを特定し、その前を脆弱版、後を修正版のイメージにする。最後にインスタンス検証として、推論モデルが素で解けてしまうものを落とし、難しいものだけ残す。ここで論文が明示しているのは、CVEの脆弱性種別やOSS-Fuzzのクラッシュ情報といった追加ヒントは検証のときだけ使い、データ合成と学習では捨てるという点です。答えの一部が問題文に混ざるのを防ぐ設計になっています。

問題文（description）も作られます。修正コミットのメッセージをLLMで分類し、品質の低いものだけを脆弱性の証拠と修正コミットから書き起こし、良いメッセージはそのまま使います。QAは答え先行で作ります（§3.2）。信頼できる出典から答えを取ってから質問を作る順序で、出典は①クラッシュ位置やテスト結果といった実行由来の事実、②変更された関数や呼び出し関係といった構造由来の事実、③権威ある報告書からの抜き出しの3種。さらにLLM審査で「答えが出典に遡れるか」「答えが質問文に漏れていないか」「答えが一意に決まるか」を検査し、曖昧なものは1回だけ作り直すか捨てます。