ライフスタイル

GitHub Security Lab、AIファジングワークフロー「Fuzzing Taskflow」を公開:AIエージェントがC/C++の脆弱性を自動で探索

GitHubブログの2026年9月24日の記事によると、GitHub Security LabはTaskflow Agentフレームワークで自律型ファジングワークフローを構築した。AIエージェントがテストハーネスの作成、カバレッジの穴の追跡、クラッシュの分類を担う。本記事では仕組み、セキュリティ上の警告、一般読者にとっての意味を整理する。

読了目安 10 分

GitHub Security Lab、AIファジングワークフロー「Fuzzing Taskflow」を公開:AIエージェントがC/C++の脆弱性を自動で探索
画像:Mokaair (Original editorial artwork)

GitHubが発表した内容

GitHubブログは2026年9月24日、Antonio Morales氏による記事を掲載し、Fuzzing Taskflowという新しいワークフローを紹介した。記事によると、これはGitHub Security Lab Taskflow Agentを基盤としており、同エージェントはGitHubが大規模言語モデル駆動のセキュリティ自動化を記述するためのフレームワークである。筆者はFuzzing Taskflowを、C/C++プロジェクト向けの自律型ファジングワークフローと説明している。

ファジング(fuzzing)とは、自動生成した大量の入力でプログラムをテストし、クラッシュや潜在的な脆弱性を発見する手法である。テストハーネスとは、テスト対象の関数に入力を渡して動かすための小さなプログラムを指し、カバレッジとは、テストで実際に実行されたコードの範囲を指す。筆者は記事の中で、継続的ファジングは万能ではないと指摘する。OSS-Fuzzに長年参加しているプロジェクトでも深刻なバグが潜んでいることがあり、その理由は、カバレッジを監視し、到達していないコードに新たなテストハーネスを書き、出てきたクラッシュを分類する人間が依然として必要だからだ。Fuzzing Taskflowは、まさにこの人手の作業をAIエージェントに任せようとする試みである。

GitHub Security Lab、AIファジングワークフロー「Fuzzing Taskflow」を公開:AIエージェントがC/C++の脆弱性を自動で探索
Mokaair 編集検証フロー · 画像:Mokaair (Original editorial artwork)
詳しい説明を読む

情報源を収集し、独立検証を行ってから Jev が判断します。

GitHubの説明によると、ユーザーはGitHubリポジトリを指定するだけで、ワークフローが適切なエントリーポイントの特定、ビルドシステムの分析、テストハーネスの作成、ファジングツールAFL++の実行、カバレッジレポートの読み取り、テストハーネスの改善、各クラッシュの分類を行い、固有のバグごとに脆弱性レポートを作成する。記事によれば、ツールはGitHubSecurityLab/seclab-taskflows-fuzzingリポジトリで公開されており、チームの内部テストをすべて通過したことからデフォルトでClaude Sonnet 5を使用する。ユーザーは設定ファイルでモデルを変更することもできる。

仕組み:AIが判断し、ツールが実行する

記事によると、全体の構成は3層に分かれる。各ステージをつなぐシェルドライバー、ステージごとに1つずつあるtaskflow YAML(実質的には各ステップで何をすべきかをエージェントに伝えるプロンプト)、そしてエージェントが実際の作業を行うために呼び出すMCPツールである。筆者が最も重視した設計原則は明確な役割分担で、大規模言語モデルのエージェントが判断を担い、MCPツールが実行を担う。エージェントがAFLやclangを直接呼び出すことはない。すべての状態はSQLiteデータベースに保存される。

記事ではまた、各テストハーネスが2回ビルドされることにも触れている。.aflビルドが実際のファジングを担い、.covビルドはその後AFLのテストキューを再生して、実際のソース行とブランチ(条件分岐)のカバレッジレポートを生成する。

カバレッジのフィードバックループと停止条件

筆者によると、カバレッジの確認と改善という2つのステップは、以前は筆者自身が手作業で行っていた。例えばLCOVレポートを読んで未カバーのブランチを探すといった作業だ。Fuzzing Taskflowはその両方をエージェントに任せる。記事によれば、各イテレーションでエージェントは、未カバーのブランチを狙ったシード入力(ファジングの出発点となるサンプル入力)の追加、より多くのAPIを呼び出すためのテストハーネスの編集、AFL辞書の自動拡張、または追う価値のない穴のスキップ、のいずれかを選択できる。

時間予算はイテレーションごとに倍増し、30秒、60秒、120秒、240秒、480秒、960秒と進み、1ターゲットあたり約32分となる。ワークフローはプラトー検出(伸びが頭打ちになったことの検知)を採用しており、2回連続でイテレーションの伸びが設定可能なしきい値(デフォルトは行カバレッジの絶対値で1%)を下回った場合、収穫逓減に達したと判断して次のステップへ進む。

構造を考慮した入力

記事によると、ワークフローは構造を考慮した入力を生成するために、相補的な4つの仕組みを備えている。JSON、XML、正規表現、PNG、長さプレフィックス付きバイナリTLVといった識別可能なフォーマットについては、事前に用意されたAFL辞書とカスタムミューテーター(入力を少しずつ変形させる部品)を同梱する。識別できないフォーマットについては、対象プロジェクト自身の.c/.hファイルをスキャンし、文字列リテラルと32ビットの数値定数を抽出してスプライス用トークンとして使う。

人手によるファジングとFuzzing Taskflowの比較(出典:GitHubブログ)
作業工程筆者が説明する人手のプロセスFuzzing Taskflowのやり方(GitHubによる)
カバレッジの確認LCOVレポートを手作業で読み、未カバーのブランチを探すエージェントが.covビルドでキューを再生した後、未カバーのブランチ一覧を読む
カバレッジの改善新しいテストハーネスを手作業で書く、または新しい入力を作るエージェントがシード追加、テストハーネス編集、辞書拡張、または穴のスキップを行う
停止のタイミング人間の判断が必要2回連続でイテレーションの伸びがしきい値(デフォルト1%)を下回れば停止
クラッシュの処理人間による分類が必要各クラッシュを分類し、固有のバグごとに脆弱性レポートを作成

一般読者への実際の影響

  • オープンソースのメンテナーにとって:GitHubはこの種のツールを、ファジングにおける人手の監視や分類作業を減らす手段と位置付けているが、実際の効果は各プロジェクトが自ら評価する必要がある。
  • 一般ユーザーにとって:ファジングの目的はソフトウェアのリリース前にバグを見つけることであり、より多くのプロジェクトが低コストでテストできれば、長期的には日常的に使うソフトウェアの信頼性向上につながる可能性がある。ただしこれは推測であり、記事は効果に関するデータを示していない。
  • AIセキュリティについて:GitHub自身の警告が示すように、AIエージェントにコマンドを直接実行させること自体にプロンプトインジェクションなどのリスクがあり、隔離環境は依然として基本的な要件である。
  • 情報源:以上の内容はすべてGitHub自社のブログに基づいており、独立した検証はまだ確認されていない。

よくある質問

Fuzzing Taskflowとは何ですか?

GitHubブログによると、GitHub Security LabがTaskflow Agentフレームワークで構築した、C/C++プロジェクト向けの自律型ファジングワークフローで、AIエージェントがテストハーネスの作成、カバレッジの追跡、クラッシュの分類を自動で行います。

人手によるセキュリティ研究を置き換えるものですか?

記事の出発点は、人手の作業のうちどれだけを大規模言語モデルのエージェントに任せられるかを探ることであり、人手を完全に置き換えるとは主張していません。筆者も継続的ファジングは万能ではないと強調しています。

どのAIモデルを使いますか?

記事によると、チームの内部テストをすべて通過したことから、デフォルトでClaude Sonnet 5を使用します。ユーザーは設定ファイルでモデルを変更できます。

自分のパソコンで実行しても安全ですか?

GitHub自身が、このワークフローはAIが選んだビルドコマンドをコンテナ隔離なしにホスト上で直接実行すると警告しており、使い捨て環境で管理者権限を使わずに実行するよう推奨しています。

これらの主張は独立して検証されていますか?

いいえ。本記事の情報はすべてGitHubブログに基づく、同社自身の説明です。

このトピックの最新ニュースを見る

最新の旅の情報・ガイド

出典

ライフスタイル