GitHub Security Labの研究者Antonio Moralesは9月24日、大規模言語モデル（LLM）駆動のファジング（fuzzing）パイプラインを公開する記事を投稿した。対象はC/C++プロジェクトで、コードはGitHubリポジトリseclab-taskflows-fuzzingに置かれており、既定モデルはClaude Sonnet 5となっている。
このパイプラインはGitHub自身のTaskflow Agentフレームワーク上に構築されている。GitHubはこのフレームワークを「LLM駆動のセキュリティ自動化を書くためのフレームワーク」と位置付けている。ユーザーはリポジトリ内でCodespaceを開き、1行のスクリプトを実行して対象プロジェクト名（例えばtukaani-project/xz）を渡すだけで、残りの作業はエージェントに任せられる。
エントリポイント特定からレポート作成まで
記事の説明によると、パイプラインは次の順序で処理を進める。コードのエントリポイントを特定し、テスト用ハーネスを自動生成し、AFL++を呼び出してファジングを実行し、カバレッジレポートを読み込み、カバレッジ状況に応じてハーネスを書き換え、クラッシュを1件ずつ分類し、最後に統一diff形式のパッチ案を添えた脆弱性レポートを生成する。
カバレッジのフィードバックには、時間予算を倍にしていく方式が使われる。各ラウンドの持ち時間は前のラウンドの2倍で、30秒から始まり60、120、240、480、960秒と増えていき、1対象あたり累計で約32分になる。エージェントは各ラウンド終了後にカバレッジを確認してから、どこを直すか判断する。
ランダムな変異が入力フォーマットをより理解できるよう、パイプラインは4層の「構造認識」手法を重ねている。ファイル形式ごとの辞書とカスタムミューテーター、ソースコードから抽出した辞書、実行中に動的生成されるAFL辞書、そしてコーパスの結合だ。
クラッシュの分類ラベルは細かく分けられている。実際の脆弱性（vulnerability）、ライブラリ強化の提案（library_hardening）、ハーネス自体のバグ（harness_bug）、メモリ枯渇、タイムアウト、アサーション失敗、重複。クラッシュはまずafl-tminで最小化され、その後コールスタック単位で重複排除される。実行中は8765番ポートで動くHTMLダッシュボードから進捗をリアルタイムに確認できる。
Moralesはこの設計の役割分担を次のように表現した。
"the LLM agent owns the decisions, and the MCP tools own the execution"
（意思決定はLLMエージェントが担い、実行はMCPツールが担う）
OSS-Fuzzとの比較
LLMをファジングに組み込む動きは、Googleの方が早かった。OSS-Fuzzは2023年からLLMでfuzz targetを自動生成する試みを続けており、Googleは2024年末、この手法によってOpenSSLの脆弱性を含む複数の問題を発見できたと発表している。ただしこの方式が解決するのは主に「ハーネスを書く」工程で、対象プロジェクトはあらかじめOSS-Fuzzの基盤に組み込まれている必要がある。
今回のGitHubのやり方は、持ち運べるツールボックスに近い。プロジェクト側がどこかのプラットフォームに登録する必要はなく、クラウド開発環境を1つ開けば実行でき、トリアージやレポート作成までひとまとめに引き受ける。記事の冒頭では、継続的なファジングは万能薬ではないと念を押しており、長年OSS-Fuzzにかけられてきたプロジェクトでも深刻なバグが潜んでいる可能性があるとし、これがxzをデモ対象に選んだ理由の一つだとしている。xzは2024年、オープンソース界を揺るがしたバックドア事件の舞台になったが、あれは意図的な混入（サプライチェーン汚染）であり、ファジングが見つけられるメモリ関連のバグとは種類が異なる問題だ。
記事が触れていない部分
外部が最も気にするであろう数字はいくつか公開されていない。xz、cJSONそれぞれで見つかったクラッシュの件数、そのうち実際の脆弱性と判定された件数、CVEが割り当てられたかどうか。1プロジェクトを実行し終えるまでのトークン消費量と費用。誤検知率。Morales自身の書き方はかなり控えめで、トリアージの結論は「人に渡すための、十分に準備された出発点」とみなすべきで最終結果ではないとし、パッチ案についてもすべて人によるレビューが必要だと明記している。
セキュリティ面の前提条件もある。このパイプラインはコンテナ分離をせずに動作するため、公式はCodespaceや使い捨ての仮想マシンのような破棄可能な環境でのみ実行するよう推奨しており、権限昇格を与えないことも求めている。社内ネットワークに直接導入したいチームにとっては、モデル選定より先にこの制約に突き当たることになる。
中国本土でオープンソースの基盤ライブラリを保守する開発者にとっては、主なハードルはモデル側にある。既定設定ではAnthropicのモデルを呼び出す仕様で、中国国内からの直接アクセスは不便だ。リポジトリはオープンソースなので、理論上は他の互換モデルに差し替えることもできるが、効果が保たれるかどうかは公開されたテストがまだない。
参考資料：GitHub公式ブログ、seclab-taskflows-fuzzingオープンソースリポジトリの説明、CocoLoop、Google OSS-Fuzzの公開資料。パイプラインの手順、時間予算、クラッシュ分類はGitHubブログの記述に基づく。