カバレッジガイドファジング は何をしますか？
実際のターゲットをフィードバック下で実行させ、意図したオラクルと再現可能なライフサイクルを実現します。実行中のファジングバイナリや成長するコーパスは、有用なターゲットリーチを確立しません。「corpus count の値はカバレッジの良さを確認するための悪い指標です」（AFL++ Fuzzing in Depth §3.g）。
適切なレーンを選択する
ターゲットのエントリポイント、ビルドグラフ、有効な機能、ランタイム/アーキテクチャ、デコーダ、プロパティを読み取ります。どのターゲットモジュールがインストゥルメンテーションを受け、ファジングビルドで何が変わるかを特定します。ドライバのみがインストゥルメントされたパスや、ラッパーでのみ有効化された機能は、意図した実装を見逃す可能性があります。cargo-fuzzの機能オプションは、転送されるまで「fuzz_targets クレートを制御」し、libFuzzerはインストゥルメンテーション（-fsanitize=fuzzer-no-link）と main() へのリンクを分離します（Rust Fuzz Book guide, Cargo features、LLVM libFuzzer, Fuzzer Usage）。
既存の適合するプロデューサとビルドオーナーを使用します。該当する実行リファレンスのみを選択します。
| ターゲット | 参照先 |
|---|---|
| ネイティブソース/バイナリ、AFL++ または libFuzzer | ネイティブランナー |
| Go または Rust | Go と Rust |
| Python/ネイティブ拡張 または JVM | Python と JVM |
| FuzzTest を使用した C++ プロパティドメイン | C++ FuzzTest |
| Node.js (CJS、ESM、Jest経由のTypeScript) | Node.js with Jazzer.js |
ブラウザアプリケーションコードには、インプロセスカバレッジガイドのルートはありません。Jazzer.jsは「他のランタイムやブラウザサポート」を範囲外としています（Jazzer.js architecture, Constraints）。ブラウザUIの探索は、UIイベントシーケンスを担当するスキルにルーティングします。
設定変更前に、選択したリリースの前提条件とインストール済みヘルプを確認します。参照は日付付きのソーススナップショットを記録しており、すべてのバージョン/プラットフォームが同じフラグをサポートすることを保証するものではありません。ユーザーの既存権限内で呼び出します。このスキル自体はインストール、ターゲット編集、外部支出を許可しません。
有限の情報パイロットを実行する
ワーカーを追加する前に、探索モード、関連するターゲットインストゥルメンテーション、状態リセット、動作するオラクルを確立します。Goのシードリプレイ、Jazzerのリグレッションモード、Jazzer.js Jestのリグレッションモード、FuzzTestのユニットモードは、それぞれ探索モードとは異なります。.go test はシードを「ユニットテストのように」実行し、「Jazzerはファジングモードが明示的に有効化されない限りリグレッションモードで動作し」、Jest下のJazzer.jsはデフォルトで "regression" になり、FuzzTestのユニットモードは「サニタイザーとカバレッジインストゥルメンテーションなしで」実行されます（Go fuzzing, Running fuzz tests、Jazzer README, Regression mode、Jazzer.js fuzzing settings, mode、FuzzTest Bazel quickstart, Create and run a fuzz test）。
デコーダの受理、意図した動作、成功したエフェクト、プロパティ評価をエンジンのカバレッジとは別に観察します。圧縮形式のバイト変異は、「uncompress に対して生成された入力のほぼすべてが無効」になる可能性があります（Google structure-aware fuzzing guide, Example: Compression）。拒否された形式、隠れた状態、満たされていない依存関係を、リーチ、リセット、フィードバックを使用して診断します。実証されたブロッカーに対して、辞書/比較フィードバックまたは構造的変異を選択します。それぞれが探索の異なる部分を変更します（AFL++ CmpLog、Google structure-aware fuzzing guide）。
入力ごと、ファジング時間、ウォールタイム、ワーカー/CPU、メモリの制御を区別し、セットアップ/リプレイのコストを承認されたエンベロープに含めます。AFL++の -V は「（ファジング時間のみ！）」であり、-E は「おおよその総実行数」です。どちらもプロセスCPUの合計ではありません（AFL++ selected-ref CLI source, usage text）。Goの -timeout はファジングフェーズを制限しません（Go と Rust）。個別の所有出力と、所有プロセスの境界のあるクリーンアップを使用します。libFuzzerは、正確なアーティファクトパスについて「複数の並列プロセスに同じパスを使用しないでください」と述べています（LLVM libFuzzer, Options）。割り当ての決定については bugfinding-campaign を参照してください。
証拠を解釈して保持する
正確な入力/型付き引数、ビルド/設定/インストゥルメンテーション、初期状態またはシーケンス、コマンド/制限、生のエンジン出力、ターゲット/プロパティカウンタ、出力されたリプレイ素材を保持します。呼び出しをまたぐ状態とライフサイクルの違いは、単一ファイルでの再現を無効にする可能性があります。Goは「ファジングターゲットの状態は各呼び出しの終了後も持続すべきではない」ことを要求しており、Jazzerのデフォルト PER_TEST は「ファジングテスト実行間で意図せず状態を保持する可能性が高い」です（Go fuzzing, Suggestions、Jazzer Lifecycle implementation）。
実際に実行されたもの、観測されたプロパティ、リソース使用量、候補と欠落を返します。探索とリグレッション、カバレッジとセマンティックリーチ、候補障害とプロダクト起因性を区別します。互換性のある保持/交換には corpus-evolution、証拠を保持する縮小には failure-reduction、起因性特定には evidence-based-triage を使用します。過去のシード選択結果は、ターゲット/スケジューラに依存します。Rebertらは、ある仮説が「最適スケジューリングの下で偽」であるにもかかわらず、ラウンドロビンの下で再テストしました。それらを普遍的なスループットや収量の約束に変えないでください（Rebert et al., pp.864,871,873）。
具体的な誤解を招く実行と修正については、よくある間違いを読んでください。このスキルから新しいターゲット固有のフレームワークは導かれません。