githubsecuritylab/seclab-taskflows-fuzzingGitHub Security Lab Taskflow Agent を活用した LLM 駆動のファジングパイプライン
LLM駆動の、OSS-FuzzスタイルのネイティブC/C++プロジェクト向けファジングパイプライン。 実行にはAFL++、カバレッジにはclang+lcov、ハーネス作成、カバレッジフィードバックに基づく判断、トリアージ、レポート作成にはLLMエージェントを使用。
このリポジトリには、
GitHub Security Lab Taskflow Agent用のファジングタスクフローが含まれています。
いくつかの共有ビルディングブロック
（fetch_source_codeタスクフロー、local_file_viewer / gh_file_viewer
ツールボックス、デフォルトのmodel_config）については
seclab-taskflows
コンパニオンリポジトリに依存しています — これらは
Python依存関係として自動的にインストールされます。
コントリビューションを歓迎します！ガイドラインについてはCONTRIBUTING.mdをご覧ください。
aptにアクセスできるLinux環境（またはCodespace）gh）pip install git+https://github.com/GitHubSecurityLab/seclab-taskflows-fuzzing
これにより、seclab-taskflow-agent と seclab-taskflows（親）が推移的に取り込まれるため、
seclab_taskflows.taskflows.audit.*、
seclab_taskflows.toolboxes.local_file_viewer、
seclab_taskflows.toolboxes.gh_file_viewer、および
seclab_taskflows.configs.model_config という形式のすべてのドット参照が、
実行時に親ディストリビューションから解決されます。
このタスクフローは、完全に自律的なファジングパイプラインです。ネイティブC/C++プロジェクトのGitHubリポジトリを指定すると、次のことを行います：
.aflバイナリ、AFL++ CMPLOG計装された.cmplogバイナリ、clangカバレッジ計装された.covバイナリとしてビルドし、このパイプラインは精神においてOSS-Fuzzスタイルです：同じ技術の多く（フォーマット別ミューテーターと辞書、構造認識トークンスプライシング、カバレッジ駆動のハーネス改善、機械可読レポート、重複排除されたスタックハッシュクラッシュ）を使用していますが、はるかに小さく自己完結しています。
# Inside the codespace (or a host with python + git available):
./scripts/fuzzing/run_fuzzing.sh tukaani-project/xz
これがインターフェース全体です。スクリプトは自律的に動作し、初回実行時に AFL++ をインストールし、その後タスクフローの残りを実行します。出力ファイルは ~/.local/share/seclab-taskflow-agent/seclab-taskflows/ に書き込まれます。
ダッシュボードはバックグラウンドで自動起動します。Codespace ではポート 8765 が自動転送されるため、任意のブラウザで開けば進行状況をリアルタイムで確認できます。
簡単なスモークテストには、小さなターゲットを使用してください:
./scripts/fuzzing/run_fuzzing.sh DaveGamble/cJSON
上から下へ3つのレイヤー:
┌────────────────────────────────────────────────────────────────────┐
│ scripts/fuzzing/run_fuzzing.sh │
│ shell driver; chains the taskflow stages with `set +e` │
└────────────────────┬───────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────────────────┐
│ src/seclab_taskflows/taskflows/fuzzing/*.yaml │
│ LLM agent prompts; one YAML per pipeline stage │
└────────────────────┬───────────────────────────────────────────────┘
│ (calls MCP tools)
▼
┌────────────────────────────────────────────────────────────────────┐
│ src/seclab_taskflows/mcp_servers/ │
│ ├ fuzz_context.py persistence (SQLite via SQLAlchemy) │
│ └ fuzz_runner.py subprocess wrappers (AFL, clang, lcov, ...) │
│ │
│ scripts/fuzzing/dashboard.py │
│ read-only HTML view of fuzz_context.db │
└────────────────────────────────────────────────────────────────────┘
主要な設計ルール：
fuzz_context.db に存在する。run_afl_for、compile_harness、store_crash などを
公開するだけである。afl-clang-lto++ -fsanitize=address,undefined（.afl バイナリ）と
clang++ -fprofile-instr-generate -fcoverage-mapping（.cov
バイナリ）でビルドされる。.afl バイナリがファズを行い、.cov
バイナリがAFLキューを再生して実際のソース行/関数/ブランチカバレッジを
生成する。3つ目のサニタイザーなしの .cmplog バイナリ（afl-clang-lto++ に
AFL_LLVM_CMPLOG=1 を付けたもの）は afl-fuzz -c に渡され、AFL++の
CMPLOG/RedQueenステージがマジック値とチェックサムを解決できるようにする。
3つのビルドはすべて必須である。CMPLOGビルドが失敗するとハーネスビルドが
失敗し、run_afl_for は .cmplog バイナリなしでは実行を拒否する。
afl-clang-lto++ がインストールされていない場合、AFL++ビルドは代わりに
afl-clang-fast++ を使用し、compile_harness は警告を返す。C++
ドライバーはC++標準ライブラリをリンクするため、CとC++の両方のハーネスと
ライブラリが動作する。.c ファイルは依然としてCとしてコンパイルされる（-x c）。| # | ステージ | Taskflow YAML |
|---|---|---|
| 1 | AFL++ + ツール群のインストール | scripts/fuzzing/install_afl.sh |
| 2 | ソースの取得 | seclab_taskflows.taskflows.audit.fetch_source_code |
| 3 | ファズターゲットの特定 | seclab_taskflows_fuzzing.taskflows.fuzzing.identify_fuzz_targets |
| 4 | ビルドシステムの分析 | seclab_taskflows_fuzzing.taskflows.fuzzing.analyze_build_system |
| 5a | 初期ハーネスの作成（要求された場合は×N候補） | seclab_taskflows_fuzzing.taskflows.fuzzing.write_initial_harnesses |
| 5b | ハーネスのビルド（AFL++エッジ + AFL++ CMPLOG + clangカバレッジ） | seclab_taskflows_fuzzing.taskflows.fuzzing.build_harnesses |
| 5c | 候補の適格性評価（HARNESS_CANDIDATES > 1 の場合） | seclab_taskflows_fuzzing.taskflows.fuzzing.qualify_harnesses |
| 6 | ファズ/カバレッジ/改善ループ（×Nイテレーション） | seclab_taskflows_fuzzing.taskflows.fuzzing.fuzz_iteration |
| 7 | クラッシュのトリアージ | seclab_taskflows_fuzzing.taskflows.fuzzing.triage_crashes |
| 8 | 既知のクラッシュが依然として再現することを確認 | seclab_taskflows_fuzzing.taskflows.fuzzing.confirm_fixed_crashes |
| 9 | コールグラフ + 未到達APIレポートの構築 | seclab_taskflows_fuzzing.taskflows.fuzzing.analyze_call_graph |
| 10 | クラッシュごとの脆弱性レポートの作成 | seclab_taskflows_fuzzing.taskflows.fuzzing.write_vuln_reports |
| 11 | キャンペーンレポートの作成 | seclab_taskflows_fuzzing.taskflows.fuzzing.write_report |
各ステージはエージェントがエンドツーエンドで実行する自己完結型の
taskflow YAMLである。ステージ間の通信は fuzz_context.db 内のSQLite
データベースを介してのみ行われ、インメモリでの受け渡しは存在しない。
これがパイプラインの核心である。時間予算はイテレーションごとに倍増する：
30s → 60s → 120s → 240s → 480s → 960s (≈ 32 min/target)
イテレーションごと、ハーネスごとに、エージェントは以下を実行する: