google/oss-fuzz-gen: LLMでファズターゲットを生成しOSS-Fuzzで採点する
LLM powered fuzzing via OSS-Fuzz.
ひと目でわかる
- これは何？
- OSS-Fuzzに登録済みのC/C++/Java/Pythonプロジェクトを対象に、LLMへファズターゲットを書かせ、コンパイル可否・クラッシュ・カバレッジの4指標で採点する実験フレームワーク。学習データの生成器ではなく、既存のOSS-Fuzzビルド基盤に乗る評価装置である点が採用判断の分かれ目になる。
- 誰に向いている？
- 導入を検討すべきなのは、すでにOSS-Fuzzへプロジェクトを登録していて、人間が書いた既存ターゲットでは届いていない経路をLLMに探させたいチームである。逆に、OSS-Fuzz未登録の社内コードベース、ビルドが再現しないプロジェクト、LLM APIの費用とレート制限を管理できない体制には向かない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- 活動が鈍っています。最後のコミットは 6 か月前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
誰のためのツールか: OSS-Fuzz参加者に限定される
このフレームワークが解く問題は、人間が書いた既存のファズターゲットが到達していないコード経路に、LLMの助けで別の入口を作れるかという問いである。READMEは対象を「real-world C/C++/Java/Python projects」と書き、評価はOSS-Fuzz platform経由で行うと明記している。つまり単体のファザーではなく、OSS-Fuzzに登録済みのプロジェクトを前提にした生成と採点のパイプラインだ。利用者はセキュリティエンジニアか、OSSプロジェクトのメンテナで、すでにOSS-Fuzzのビルド設定を保守している側に限られる。逆に言えば、OSS-Fuzzへ登録していない社内リポジトリをそのまま放り込んで動く類のツールではない。READMEのUsage節は詳細をUSAGE.mdへ委ねており、この記事で扱える起動情報はREADMEに書かれた範囲に留まる。
生成から採点までの流れ: 4つの指標が何を測るか
生成物はLLMが書いたファズターゲットであり、それが既存のOSS-Fuzzビルド基盤に載せられて実行される。READMEによれば評価指標は4つ。Compilability、Runtime crashes、Runtime coverage、そして既存の人間が書いたターゲットとのRuntime line coverage diffである。最後の指標が設計上もっとも特徴的で、LLMの出力を単体で褒めるのではなく、同じプロジェクトにすでにある人間製ターゲットとの差分として測る。READMEが挙げる2024年1月31日の実験例では1300件超のベンチマークを297プロジェクトから集め、160のC/C++プロジェクトで非ゼロのカバレッジ増加を生むターゲットが得られたとされ、最大の行カバレッジ増加は29%と記載されている。ここで注意したいのは、この数値がこのフレームワーク自体の性能上限ではなく、特定日・特定モデル・特定プロンプトでの観測結果だという点だ。READMEはレポートを非公開にしている理由も書いている。未公開の脆弱性を含みうるからである。
対応モデルとプロンプト構成: 差し替え可能な部品としてのLLM
対応モデルはREADMEの一覧に列挙されている。Vertex AIのcode-bisonとcode-bison-32k、Gemini Pro、Gemini Ultra、Gemini Experimental、Gemini 1.5、OpenAIのGPT-3.5-turbo、GPT-4、GPT-4o、GPT-4o-mini、GPT-4-turbo、そしてAzure経由のGPT-3.5-turbo、GPT-4、GPT-4oである。モデルは固定ではなく交換可能な部品として扱われており、同じプロジェクトに対して複数モデルを試す前提の構成になっている。プロンプト側も可変で、READMEのバグ一覧にはDefault、Test-to-harness、および「Low coverage with fuzz keyword + easy params far reach」といったプロンプトビルダーやターゲットオラクルの識別子が列挙されている。つまり同じ生成器でも、どのプロンプトテンプレートとどのオラクルを選ぶかで結果が変わる。この表の各行が「どのモデルが優れているか」の証拠にならないことは明記しておく。プロジェクトごとに難易度が違い、行数も揃っていない。
動かす前に揃えるもの: リポジトリ構成から読み取れる依存
READMEのUsage節は「Check our detailed usage guide for instructions on how to run this framework」とだけ書き、具体的なコマンドはUSAGE.mdへ委ねている。この記事の材料にはUSAGE.mdの内容が含まれていないため、起動コマンドを推測で書くことはしない。確実に読み取れる依存は次の通り。第一にOSS-Fuzz本体。評価はOSS-Fuzz platform上で行われると明記されている。第二にLLMのAPI資格情報。Vertex AIかOpenAIかAzureのいずれかを使う以上、それらの認証設定が必要になる。第三にプロジェクト側のビルド定義。READMEはOSS-Fuzzの各プロジェクトディレクトリへのリンクを並べており、生成ターゲットはそこへ組み込まれる形で評価される。個別エージェントだけを試したい場合の入口も用意されており、READMEはagent_tests/readme.mdを参照するよう案内している。実験全体を回さずに単体のエージェントを実行・評価できると書かれているので、最初の試行はそちらから入るのが現実的だ。
このフレームワークが向かない場面
最大の制約は、OSS-Fuzzに載っていないコードには事実上使えないことだ。評価がOSS-Fuzz platform経由で行われる以上、対象プロジェクトのビルドがOSS-FuzzのDockerイメージ内で再現しなければ、生成されたターゲットは採点以前にコンパイル段階で落ちる。Compilabilityが独立した指標として立てられていること自体、コンパイルが通らない出力が日常的に出ることを示唆している。次に、レポートが非公開である点。READMEは「these reports are not public as they may contain undisclosed vulnerabilities」と書いており、これは便利さの欠如ではなくセキュリティ上の要請だ。生成結果をCIのログや公開ダッシュボードへ流す運用は、未修正の脆弱性を露出させる経路になりうる。加えて、LLMのAPI呼び出しは外部送信を伴う。ソースコードの断片を外部モデルへ送れない組織は、Vertex AIやOpenAIのエンドポイントを使う構成そのものを選べない。
代替手段との違い: ファザーではなくターゲット生成器である
比較対象として分かりやすいのは、libFuzzerやAFL++のような従来型ファザーだ。これらは入力空間を探索する実行エンジンであり、ファズターゲットは人間が書く。oss-fuzz-genはその上流に位置し、エンジンを置き換えるのではなく、エンジンに食わせる入口をLLMに書かせる。だからこそ評価指標にCompilabilityが入り、既存ターゲットとのline coverage diffが主要な物差しになる。もうひとつの比較軸はOSS-Fuzz本体である。OSS-Fuzzは継続的ファジング基盤としてビルドと実行とトリアージを担うが、ターゲットの新規生成は行わない。oss-fuzz-genはOSS-Fuzzを採点装置として借用し、生成側だけを引き受ける。この分業の帰結として、生成物の品質はOSS-Fuzz側のビルド定義の質に強く依存する。ビルドが壊れているプロジェクトでは、LLMの出力が良くても指標が上がらない。
保守コストとライセンス: 追随し続ける前提の設計
対応モデルの一覧にGemini ExperimentalやGPT-4o-miniが混ざっていることから、モデル側の更新に追随して一覧が書き換えられていく性質のリポジトリだと分かる。実際、最終pushは2026年3月17日であり、継続的に更新されている。モデル名やAPIの仕様変更に合わせて設定を直す作業が発生し続けると考えるのが妥当で、一度動かして終わりのツールではない。ライセンスはApache-2.0。特許条項を含む寛容型ライセンスで、商用利用や改変に大きな制約は置かれていない。ただし、生成したファズターゲットの帰属や、LLMプロバイダの利用規約が生成物に及ぼす条件は、このリポジトリのライセンスとは別問題である。ここは法的判断ではなく確認事項として挙げておく。組織の法務や調達の担当が別途レビューすべき領域だ。
採用判断の分岐点
このフレームワークの価値は、LLMが書いたターゲットを既存の人間製ターゲットと同じ土俵で測れる点にある。line coverage diffという物差しがあるから、生成物が「動いた」だけで終わらず、既存の到達点を超えたかどうかが数値で出る。READMEが挙げる30件のバグにはCVE-2024-9143も含まれており、生成物が実際の脆弱性発見に到達した事例が記録されている。ただし、これはVertex AIと特定のプロンプトビルダーの組み合わせで得られた結果であり、手元のモデルとプロンプトで同じ結果が出る保証はどこにもない。導入するなら、まずOSS-Fuzzに登録済みの1プロジェクトを選び、agent_tests/readme.mdの手順で単体エージェントを回し、Compilabilityが通るかどうかだけを確認する。そこで落ちるなら、モデルを変えても改善しない可能性が高い。ビルド定義側の問題だからだ。
編集部の結論
導入を検討すべきなのは、すでにOSS-Fuzzへプロジェクトを登録していて、人間が書いた既存ターゲットでは届いていない経路をLLMに探させたいチームである。逆に、OSS-Fuzz未登録の社内コードベース、ビルドが再現しないプロジェクト、LLM APIの費用とレート制限を管理できない体制には向かない。最初に確認するのは3点。対象プロジェクトがOSS-Fuzzのproject.yamlとDockerfileを持ちローカルで再現ビルドできること、使うモデル名がREADMEの対応表に載っていること、そして生成レポートが未公開の脆弱性を含みうるため社内に閉じた保存先を用意できること。このうちどれかが欠けるなら、このフレームワークを動かす前にOSS-Fuzz側の受け入れ準備を先に済ませる必要がある。
コミュニティノート