GitHub Security LabのAIファジング：C/C++脆弱性調査を自動化する新手法

• GitHub Security LabがLLM駆動の自律型ファジングパイプライン「Fuzzing Taskflow」を公開。
• Claude Sonnet 5をエンジンに採用し、ハーネス作成からカバレッジ改善、脆弱性トリアージまでを自動化。
• エンジニアはCodespace上でコマンドを叩くだけで、複雑なC/C++プロジェクトの脆弱性調査を即座に開始可能。

深夜の障害対応や、終わりの見えないデバッグ作業に追われるエンジニアにとって、「ファジング」という言葉は甘美でありながら、同時に重い現実を突きつける存在だ。OSS-Fuzzに長年登録されているプロジェクトであっても、依然として致命的な脆弱性が放置されている事実は珍しくない。なぜか。それは、ファジングが単にツールを回せば終わる魔法ではないからだ。カバレッジを監視し、コードの深部に到達するためのハーネスを書き、山のように出力されるクラッシュログをトリアージする。この「人間による介入」こそが、ファジングにおける最大のボトルネックであり、多くの開発現場で導入が頓挫する主因である。

GitHub Security LabのAntonio Morales氏が開発した「Fuzzing Taskflow」は、この泥臭い作業をLLMエージェントに丸投げするという、極めて実戦的なアプローチをとっている。このシステムは、単なるスクリプトの集合体ではない。GitHubリポジトリを渡せば、エージェントが自律的にビルドシステムを解析し、適切なエントリーポイントを特定し、AFL++を駆使してハーネスを生成・改善し、最終的に脆弱性レポートまで出力する。我々がこれまで数日かけて行っていた「環境構築とハーネスの試行錯誤」が、コマンド一つで完結する世界が到来したのだ。

設計思想において特筆すべきは、LLMエージェントと実行ツール（MCPツール）の明確な分離だ。エージェントは「何をすべきか」という意思決定に集中し、実際のコンパイルや実行はSQLiteデータベースを介したプリミティブなツール群が担う。この疎結合なアーキテクチャにより、LLMが暴走してシステムを破壊するリスクを最小限に抑えつつ、複雑なパイプラインを安定して運用できる。特に、ハーネスを「AFL用（計測用）」と「カバレッジ計測用」の二重構造でビルドする設計は、現場のエンジニアなら膝を打つはずだ。AFLの高速なエッジ計測と、人間が読める正確なカバレッジレポートを両立させるための、極めて現実的な解である。

ファジングの成否を分けるのは、入力データの「構造」をどれだけ理解しているかだ。従来のバイトレベルの変異（bit flipsなど）だけでは、JSONやXMLのような構造化されたデータに対しては無力に等しい。これまではエンジニアが手作業でカスタムミューテーターを書く必要があったが、Fuzzing Taskflowはこの退屈な作業を自動化した。具体的には、ターゲットのソースコードから文字列リテラルや定数を抽出し、それを辞書として動的に活用する。さらに、カバレッジのフィードバックループを回すことで、未到達の分岐点（ガード条件）を特定し、そこを突破するためのトークンを辞書に自動追加していく。これは、まさに「コードの深淵をAIが自ら探索する」プロセスそのものだ。

特筆すべきは、このパイプラインが採用している「時間予算の指数関数的増加」戦略である。30秒から始まり、最大960秒まで、反復ごとに予算を倍増させる。低コストで拾える低次のカバレッジを早期に回収し、難易度の高いガード条件に対しては時間をかけて突破を試みる。この「高原検知（plateau detection）」による停止条件の自動判定は、計算リソースの浪費を防ぐための賢明な実装だ。1%未満の改善しか見込めない段階で打ち切る判断は、クラウドの計算コストを意識せざるをえない現代のエンジニアにとって、非常に心強い機能と言える。

また、トリアージの自動化も特筆に値する。クラッシュが発生した際、スタックトレースを解析し、重複を排除し、さらには「脆弱性か、単なるハーネスのバグか」を判定する。この判断は、これまで熟練のセキュリティエンジニアがコードを追いかけて行っていた作業だ。もちろん、LLMの判断を鵜呑みにするのは危険だが、修正案（unified diff）まで提示してくれる点は、開発スピードを劇的に向上させる。我々が明日から取るべき対策は、このツールを使いこなすことではない。このツールが提示する「脆弱性の根拠」を、いかに迅速にレビューし、自らのコードベースにフィードバックするかの「判断力」を磨くことにある。

Fuzzing Taskflowの登場は、セキュリティエンジニアの役割が「作業者」から「監督者」へとシフトすることを決定づけた。しかし、ここで我々が直面しなければならないのは、AIが生成した脆弱性レポートを、我々は本当に「理解」して修正できているのかという問いだ。AIが提示する修正案を、その場しのぎのパッチとして適用し続けることは、将来的にさらなる技術的負債を蓄積させるリスクを孕んでいる。ツールが自動化してくれるのは「発見」と「分析の補助」までであり、その脆弱性がシステム全体のアーキテクチャにどのような影響を与えるかという「文脈の理解」は、依然として人間にしかできない。

また、このツールはCodespace上での実行を推奨しているが、これは「プロンプトインジェクション」のリスクを内包している。LLMが解析する対象のコードに悪意のある細工が施されていた場合、エージェントがホスト環境で任意のコマンドを実行してしまう可能性がある。この「AIによる自動化」と「セキュリティリスク」のトレードオフを、我々はどのように管理すべきか。Disposableな環境で実行するという原則は守るべきだが、それだけで十分と言い切れるだろうか。

最後に、読者であるエンジニア諸氏に問いたい。あなたのプロジェクトにおいて、ファジングを導入しない言い訳は、もはや「リソースがない」「専門知識がない」という言葉では通用しなくなる。AIが脆弱性を自動で掘り起こす時代において、我々が守るべきは「コードの品質」なのか、それとも「AIの出力を検証するプロセス」なのか。明日から、自社のCI/CDパイプラインにこの種の自律型エージェントを組み込む際、あなたはAIの判断をどこまで信頼し、どこから先を自分の手で検証するのか。その境界線を定義することこそが、これからのシニアエンジニアに求められる真のスキルセットではないだろうか。