GitHub Security Labは、ファジングと大規模言語モデルのエージェントを利用して、C/C++プロジェクトのテストの大部分を自動化するよう設計された、Fuzzing Taskflowというオープンソースのワークフローについて説明した。このワークフローは、GitHubリポジトリを指定すると、ビルドシステムを分析し、適切なエントリーポイントを特定し、fuzz harnessesを作成し、AFL++を実行し、カバレッジレポートを読み取り、ハーネスを改善し、クラッシュを分類して、潜在的な各問題について個別の報告書を作成できる。
このプロジェクトは、GitHub Security Lab Taskflow Agentフレームワーク上に構築されている。このフレームワークは、ワークフローを、エージェントが最初から最後まで実行する一連のタスクフローとして表現する。記事の執筆者であるAntonio Moralesは、目的は研究者の役割をなくすことではなく、時間を大量に消費する反復作業をエージェントに移し、意思決定と実行を2つの層に分離したままにすることだと指摘している。
ワークフローの仕組み
利用はプロジェクトのリポジトリから始まり、例えばCodespace内で./scripts/fuzzing/run_fuzzing.sh PROJECTコマンドを実行する。ワークフローはツールのインストール、リポジトリのクローン、重要な関数の分析を行い、その後、ファジング対象を作成してキャンペーンを実行する。その構成は、shellランナー、作業段階とモデルへの指示を記述するYAMLファイル、AFLの実行、ハーネスのコンパイル、カバレッジの読み取り、クラッシュの保存といった処理を実行するMCPツールから成る。
エージェントはAFLやclangを直接呼び出さない。何をテストすべきか、どのカバレッジの不足を追跡すべきかを判断し、MCPツールが低レベルの処理を実行する。状態はfuzz_context.dbというSQLiteデータベースに保存されるため、共有メモリに依存せず段階間で結果を受け渡せる。
カバレッジ改善ループ
各ハーネスは2回ビルドされる。1つは適切なインストルメンテーションツールを使ってAFLを誘導する.afl版で、もう1つは入力リストを再実行して行と分岐のカバレッジを測定する.cov版である。各ラウンドの後、エージェントはカバーされていない分岐を確認し、新しいseedの追加、別のインターフェースを呼び出すためのハーネスソースの変更、コードが検証する値によるAFL辞書の拡充、コストに見合わない低頻度パスの無視といった対応を選択する。
時間予算は30秒、60秒、120秒、240秒、480秒、960秒と倍増し、記載されている最大値では対象ごとに約32分となる。設定可能なデフォルト値に基づき、連続する2ラウンドで行カバレッジの増加が1パーセントポイント未満になると、投資効果の低下を検出してワークフローは別の対象へ移行する。
入力とクラッシュへの対応
このワークフローは、JSON、XML、正規表現、PNG、埋め込み長を持つバイナリTLV形式向けの専用機構をサポートし、CおよびHファイルに含まれる文字列および数値定数から辞書を生成することもできる。また、カバレッジの各ステップ後に、カバーされていない行の近くにある条件分岐に基づいて、この辞書を拡充する。さらに、各ハーネスは固定されたcorpusディレクトリを保持し、afl-cminを使ってサイズを削減しながら、ラウンドおよびキャンペーン間で有用な入力を維持する。
キャンペーン終了後、クラッシュはafl-tminで最小化され、AddressSanitizerの下で再実行され、その後、スタック最上部のフィンガープリントに基づいて重複が除去される。また、既知のクラッシュを再テストして修正の影響を検証し、結果を脆弱性、ライブラリの強化、ハーネスのバグ、メモリ不足、タイムアウト、assertion失敗、重複を含む分類に振り分ける。
なぜこのニュースが重要なのか
ここでの実用的な価値は、継続的なファジングの有効性をしばしば制限するループ、すなわちハーネスの作成、カバレッジの読み取り、次の不足箇所の選択、クラッシュの分類を自動化しようとしている点にある。これにより、これまでファジングを受けていなかったプロジェクトのテスト開始コストを下げたり、既存プロジェクトのカバレッジ拡大を支援したりできる可能性がある。
しかし、GitHub Security Labは重要な制約を設けている。このワークフローは、afl-fuzz、clang、およびモデルが選択するビルドコマンドを、隔離コンテナなしでホストシステム上で直接実行する。そのため、プロンプトインジェクションの影響を受けたエージェントが、ユーザーに実行可能な操作を実行する可能性がある。プロジェクトは、Codespaceや一時的な仮想マシンなど、破棄可能な環境内で、特権を付与せずに実行することを推奨している。
また、脆弱性報告と提案された修正は最終的な結果ではない。記事は、モデルの分析には誤りがあり得ること、提案されたパッチにはレビューが必要であることを明記している。したがって、Fuzzing Taskflowは研究者のために十分に準備された出発点であり、到達可能性、悪用可能性、根本原因について人間が検証する代替手段ではない。