Lab idea / AI-enabled offense
Can a generated harness earn its extra coverage?
Keep harness validity and reproducibility in the denominator of AI-assisted fuzzing.
Falsifiable hypothesis
A reviewed generated harness reaches valid additional code paths within the same compute budget.
Source-led motivation
oss-fuzz-gen uses LLMs to generate fuzz targets and evaluates compilation, runtime crashes, coverage, and line-coverage differences against existing OSS-Fuzz targets.
Authorized lab scope
One owned or explicitly authorized test project; isolated disposable runners and synthetic inputs.
Prerequisites
- An existing harness and a fixed compiler/runtime configuration.
- A pinned generator and model, a compute budget, and manual harness review.
- A process for retaining crashes privately and following disclosure obligations.
Comparison & control
Run baseline and generated harnesses with equal budgets. Review harness validity before interpreting coverage differences.
Observations to collect
- Build and runtime failures, including harness-caused failures.
- Additional valid paths, deduplicated crashes, and reproduction steps.
- Human triage effort; do not label crashes vulnerabilities prematurely.
Disconfirming evidence
- Additional coverage disappears after fixing invalid harness behavior, or the baseline matches it at equal budget.
Stop conditions
- Stop if any action reaches an unapproved target, real user data, or a non-lab service.
- Stop on unexpected egress, exposed credentials, or an exhausted predeclared budget; retain a sanitized failure record.
Source bibliography
- A Framework for Fuzz Target Generation and Evaluation ↗
Google / OSS-Fuzz team
Publication date: Date not supplied · Editorial check 2026-10-26 UTC
Project README / official documentation; source-led editorial check, no execution