Fuzz Driver Generation: A Survey and Outlook from the Perspective of Data Sources

Abstract

Fuzzing is an essential element of software supply chain security governance. Despite its importance, the widespread adoption of library fuzzing is limited by the significant costs associated with constructing fuzz drivers. Without a clear entry point, the reachable path space of the target library is determined by the interplay of API call sequences, parameter dependencies, and state constraints. As a result, fuzz drivers must achieve not only successful builds but also provide sufficient semantic context to enable exploration of deeper state machine interactions, thereby avoiding premature stagnation at superficial validation logic. To systematically assess advancements in automated fuzz driver generation, this paper develops a taxonomy organized around the primary data sources used to derive driver-generation constraints, categorizing existing approaches into four technological trajectories: Usage Artifact Mining, Source Code Constraint Inference, Binary Semantics Recovery, and Heterogeneous Data Fusion. Large language models are increasingly integrated into these workflows as generators and as components for constraint alignment and repair. To address inconsistencies in experimental methodologies, this paper introduces a bounded comparability-oriented evaluation perspective focused on three dimensions: validity, reachability-related evidence, and reproducibility and cost. Together with a disclosure and reporting protocol for metric comparability, this perspective clarifies the information needed for cross-study comparison and examines the unique features and inherent limitations of each technical trajectory. Based on these findings, three key directions for future research are identified: facilitating structural evolution in response to coverage plateaus to address deep logic unreachability; coordinating dynamic closed-loop orchestration that utilizes on-demand heterogeneous data retrieval to resolve context challenges; and developing language-agnostic driver representations with pluggable adaptation mechanisms to improve cross-ecosystem portability and scalability.

1. Introduction

As modern software ecosystems grow increasingly complex, libraries are reused at scale across the software supply chain, giving rise to intricate dependency graphs [1]. As a result, flaws in low-level core libraries can cascade through dependency chains, amplifying their impact and ultimately becoming systemic security risks. This issue is particularly acute in the C/C++ ecosystem, where memory safety vulnerabilities tend to be severe and far-reaching; once they appear on critical dependency paths, they may affect a large number of downstream applications and services [2]. Therefore, performing intensive security testing of critical libraries in a scalable and sustainable manner has become a central challenge in software supply chain security governance [3].

As a countermeasure, coverage-guided fuzzing [4,5,6,7,8] has been widely integrated into the development lifecycle [9,10,11] and engineered into continuous fuzzing infrastructures within the industry. Google launched the OSS-Fuzz project in 2016, subsequently providing continuous fuzzing services for over 1000 open-source projects. As of May 2025, OSS-Fuzz has reported over 13,000 security vulnerabilities and more than 50,000 other types of defects [12]. However, in library fuzzing, testers primarily encounter the entry adaptation challenge: libraries typically expose multiple APIs, where the reachable path space is jointly determined by call sequences, parameter dependencies, and state constraints. Consequently, a fuzz driver is required to explicitly construct the execution context and map unstructured inputs to API calls. The high cost of writing and maintaining fuzz drivers directly constrains the scalability of library fuzzing; even in large-scale initiatives like OSS-Fuzz, thousands of manually contributed drivers cover only approximately 30% of the target codebases [12].

The critical bottleneck in library fuzzing lies not merely in the existence of drivers, but also in whether the driver quality suffices to support sustained coverage gains [13]. High-quality drivers must simultaneously satisfy two key requirements. The first is validity: a driver must compile, link against the target library, and execute without immediately crashing. Different studies measure validity at different levels of strictness, ranging from build success alone to a short execution run free of startup failures, but they share the common requirement that the driver passes the build-and-launch barrier. The second is reachability. Reachability implies minimizing futile executions trapped in parameter validation, error handling, or fast-fail paths, thereby triggering deeper state machine interactions [14]. If a driver remains indefinitely in a runnable but unreachable state, substantial computational resources will be dissipated on runtime barriers such as fast-fail paths or contract violations, causing coverage gains to reach a plateau significantly earlier [15,16].

To address these objectives, researchers have recently proposed diverse methods for automated fuzz driver generation. Existing approaches can be unified under the following perspective: under given constraints of data availability, they transform limited observational information into executable API call constraints and iteratively rectify defects violating implicit contracts through build and execution feedback. This paper defines data as all information carriers accessible during the driver generation process, including source code, consumer code/unit tests, unstructured documentation, and compilation and runtime feedback [17,18]. Different data modalities dictate the types of deducible constraints and correction mechanisms: when usage artifacts are available, methods often reuse real calling patterns to extract interaction skeletons; when only source code or binaries are accessible, they rely on source analysis or binary analysis, respectively, to recover interface semantics and dependencies. Furthermore, as large language models (LLMs) exhibit capabilities in program synthesis [19,20,21,22,23,24], relevant research has begun leveraging LLMs as components for constraint alignment and repair. By integrating compilation feedback and runtime feedback, these approaches establish a closed-loop generation–validation–repair process, thereby improving driver validity and reachability while reducing manual effort.

Despite rapid advancements in related research, existing surveys do not fully cover the scope of this review. The earlier survey on fuzz driver generation [25] predates the recent wave of LLM-assisted generation and repair. Surveys on LLM-based fuzzing [26] cover a broader range of topics but do not focus specifically on driver generation from heterogeneous data sources. In addition, experimental inconsistencies across studies hinder effective cross-study comparisons. These inconsistencies are particularly evident in benchmark selection, measurement criteria, validation workflows, and cost disclosure. As a result, cross-study comparisons are limited to enumerating results rather than building cumulative mechanistic understanding. This deficiency poses a significant challenge, especially regarding reproducibility and cost.

To address the aforementioned issues, this paper surveys 30 studies published between 2019 and 2025 (see Figure 1 for the distribution of the surveyed studies), including 29 tool proposals and 1 empirical comparative study. Based on this corpus, a data-source-based taxonomic framework is proposed to categorize existing methods into four technical trajectories. These methods are further compared in terms of semantic modeling, code-validity assurance, and the use of feedback loops. This enables the characterization of how different data-source configurations affect the way constraints are inferred and errors are fixed. The primary contributions of this paper include:

Figure 1. Distribution of the surveyed studies. (a) Distribution of publication/preprint outlets. (b) Distribution of technical trajectories from 2019 to 2025, with shortened legend aliases for readability.

1.

Presenting a structured overview of automated fuzz driver generation technologies, delineating key technical trajectories and their intrinsic connections.

2.

Proposing a bounded comparability-oriented evaluation perspective to support more transparent cross-work interpretation. This perspective characterizes core trade-offs across three evaluation dimensions: engineering validity, reachability-related evidence, and reproducibility and cost. Furthermore, it specifies the minimum disclosure elements required to support bounded comparability analysis.

3.

Identifying three structural challenges—coverage plateaus and reachability bottlenecks, context dilemma, and ecosystem heterogeneity—and deriving corresponding future research directions.

The remainder of this paper is organized as follows: Section 2 introduces the fundamental concepts of library fuzzing and fuzz drivers; Section 3 presents the data-source-based taxonomy and systematically reviews the four technical trajectories and their core mechanisms; Section 4 examines metrics, reproducibility, and engineering constraints; and Section 5 discusses challenges and future directions.

2. Background

This section presents the necessary background on fuzzing and fuzz drivers to facilitate the subsequent discussion on “how drivers are generated, how failures are rectified, and how effectiveness is evaluated.” Earlier overviews of automated fuzz driver generation [25,27] have already charted parts of this landscape; the concepts introduced below are the ones directly needed to understand the generation, validation, and evaluation perspectives adopted in the remainder of this paper.

2.1. Fuzzing

Fuzzing is an automated or semi-automated software testing technique. Its core principle lies in generating a massive number of test cases, which often consist of malformed or unexpected inputs. These inputs are fed into the target program while its execution is monitored to detect anomalies such as crashes, assertion failures, and memory leaks. Once an anomaly is detected, the corresponding input that triggers it is recorded for subsequent vulnerability analysis and reproduction [5,28,29]. The general workflow of fuzzing is illustrated in Figure 2.

Figure 2. General workflow of fuzzing.

Based on the type of the target under test, fuzzing is commonly categorized into two classes:

• Application Fuzzing. This targets standalone executables or system components, injecting inputs via files, standard input, or network interfaces while monitoring for abnormal terminations, crashes, or timeouts. Coverage-guided tools such as AFL [30], AFL++ [31], and libFuzzer [32] leverage execution feedback to select and mutate inputs, thereby enhancing path exploration efficiency.
• Library Fuzzing. Since libraries are not standalone executables, they lack a standard entry point (i.e., main) and cannot be directly executed via standard input. Instead, they require a specific harness to explicitly bridge the fuzzing engine with the library APIs, mapping generated inputs to valid calling sequences.

2.2. Fuzz Driver

The internal execution flow of a fuzz driver consists of four functional stages. These stages manage the data flow from the fuzzing engine to the target library. As illustrated in Figure 3, the driver performs the following operations in sequence during each iteration:

Figure 3. Anatomy of a typical fuzz driver.

1.

Input Parsing: Converts the raw byte stream from the fuzz engine into specific types required by the target APIs, such as scalars, pointers, and structures.

2.

Context Initialization: Constructs the execution state for the library, including memory allocation, global variable setup, and object instantiation, to satisfy API preconditions.

3.

API Invocation: Executes a series of interfaces in a specific logical order to explore code paths.

4.

Resource Cleanup: Releases allocated resources (e.g., memory and file descriptors) and resets the internal state to ensure iteration independence and avoid resource accumulation.

3. Fuzz Driver Generation Techniques

In library fuzzing, the primary challenge is data availability. Testers must generate high-quality fuzz drivers based on available data. In practice, high-value data sources, such as consumer code, unit tests, or source code, are difficult to obtain. This limitation is particularly severe in closed-source or complex systems, where typically only binary files and limited runtime feedback are available.

Prior reviews have organized this design space along different axes: Dissanayake et al. [25] primarily classify studies by degree of automation, whereas Yan et al. [27] place stronger emphasis on evaluation practice and benchmarking. These perspectives remain valuable, but they do not directly foreground how available evidence shapes constraint recovery and repair during driver generation. For this reason, this review adopts the primary data source used to recover generation-critical constraints as the organizing axis.

Under this lens, existing research falls into four technical trajectories: Usage Artifact Mining, Source Code Constraint Inference, Binary Semantics Recovery, and Heterogeneous Data Fusion. This taxonomy is an organizational lens rather than a rigid formal partition. Some recent systems combine multiple sources. Classification follows a unified data-source rule: if one data-source family provides the dominant constraints driving driver generation, the system is assigned to the corresponding single-source trajectory (Trajectories 1–3); if constraints are jointly recovered from multiple heterogeneous data-source families, with no single source remaining dominant, the system is assigned to Trajectory 4 (Heterogeneous Data Fusion), which is a multi-source regime on the same axis. In mixed-source cases where a single dominant source can still be identified, we classify by that dominant source. The subsequent sections will systematically review representative works following the four trajectories outlined in Table 1.

Table 1. Data-Source-Based Taxonomy of Generation Mechanisms and Typical Limitations.

Trajectory	Dominant Inference Pattern	Driver Profile	Typical Limitation
Usage Artifact Mining	Artifact-Guided Reuse Recovers driver skeletons from observed usages and extends them with inferred glue logic.	Artifact-Anchored Drivers Sequences and setup remain anchored to observed usage patterns, even when expanded.	Overfitting Confined to the state space of artifacts; fails to reach deep, new logic.
Source Code Constraint Inference	Program-Internal Constraint Recovery Infers call sequences and parameter constraints from source-level structure, semantics, and local feedback.	Constraint-Assembled Drivers Diverse API interactions whose coherence depends on recovered implicit contracts.	Semantic Violation High abort rate due to missing implicit contracts (e.g., initialization).
Binary Semantics Recovery	Compiled-Artifact Analysis Reconstructs interface semantics from compiled artifacts, including instruction traces and cross-language bytecode static analysis.	Low-level Snapshots Operates on raw memory/addresses rather than symbolic variables.	Observation Cost Performance bottleneck due to heavy dynamic instrumentation overhead.
Heterogeneous Data Fusion	Multi-Source Constraint Fusion Integrates constraints from heterogeneous carriers—code, documentation, build feedback, and learned priors—to synthesize drivers.	Human-like Code Includes error handling and logic, but prone to hallucinations.	Context Overflow Critical constraints lost due to noise or token window limits.

3.1. Usage Artifact Mining

Usage Artifact Mining treats existing usage as a starting point. It extracts API interaction fragments from external consumer code or unit tests, supplements missing initialization and parameter passing, and organizes them into runnable fuzz drivers. Its direct benefit is reducing manual driver-writing effort and alleviating the cold-start problem when no seeds are available. The overall pipeline and technical evolution of this trajectory are illustrated in Figure 4.

Figure 4. Processing pipelines and technical evolution of Usage Artifact Mining trajectory. The figure covers Fudge [33], FuzzGen [34], Fries [35], Daisy [36], Rubick [37], FuzzBuilder [38], Utopia [39], and Nexzzer [40].

Fudge [33] proposes a workflow based on program slicing and synthesis: it locates API call sites in consumer code, extracts minimal execution slices, and generates drivers in batches. Its limitations are also clear. The analysis is predominantly intraprocedural, which restricts it to reproducing local usage and makes it difficult to cover cross-function state changes.

To extend coverage beyond local slices, FuzzGen [34] abstracts control flows and data flows from different consumer code into an Abstract API Dependence Graph ($A^{2}DG$), then synthesizes longer call sequences through graph merging, attempting to advance state exploration depth. The cost stems from merging: when dependency graphs from different sources are forcibly fused, the $A^{2}DG$ is prone to generating state inconsistencies, resulting in sequences that deviate from original call logic, with a consequent rise in false positives.

Addressing conflicts introduced by merging, FRIES [35] adds constraints to the synthesis process using ecosystem statistics: it calculates call frequencies from a large volume of consumer code to construct a weighted API Dependence Graph (ADG), directing the generator to prioritize more common interaction patterns. It can suppress some noisy paths, but strictly assumes that ecosystem statistics represent the true usage distribution of the target library in the current version.

Using consumer code as a data source entails inherent shortcomings in reliability and maintainability. Reusing unverified fragments inherits defects such as incorrect initialization and erroneous resource release orders, making spurious crashes common. Furthermore, interface evolution introduces version drift. Jeong et al. [39] analyze the top 200 C/C++ libraries on GitHub and find that approximately 73% of projects maintain unit tests, making them a potentially cleaner source of usage for driver generation: when actively maintained, call sequences are more likely to be verified, and test inputs can serve directly as initial seeds, making drift risks relatively more controllable.

FuzzBuilder [38] is an early system reusing unit tests to generate drivers, but it relies on manual configuration (identifying Fuzzable APIs, annotating input buffer locations and sizes, etc.). To reduce this manual configuration burden, Utopia [39] utilizes techniques such as root definition analysis, further automating the path from tests to fuzzable entry points.

Static usage analysis has another common source of error: type-level information is too coarse and can easily conflate different instances of the same type. Daisy [36] points out that this leads to erroneous splicing of object lifecycles (e.g., create→free→reuse), potentially inducing spurious use-after-free alerts. Consequently, Daisy shifts to dynamic analysis, capturing object usage sequences (OUS) by executing consumer code, and then fusing multiple OUSs into a driver skeleton, striving to maintain object state consistency.

Daisy leans more towards object data flow, with insufficient coverage of control flow branches and return value constraints. Addressing this limitation, Rubick [37] represents call and return constraints as event sequences using deterministic finite automata (DFA) and refines the model through queries and counterexamples using active automata learning, synthesizing drivers with scheduling logic to reduce redundant sequences and noise.

This trajectory relies on faithful reproduction to ensure call rationality, but this also locks the exploration boundary within the state space covered by artifacts. To break this confinement, Nexzzer [40] adopts a modular driver architecture and a general-purpose interpreter to decouple execution logic, leveraging runtime feedback to infer implicit dependencies between APIs and expand the variation space of sequences; simultaneously, it employs misuse filtering to suppress noise. Its costs lie in cold-start and rule boundaries: dynamic inference incurs higher overhead, and rule-based filtering may still miss valid paths or permit noise under atypical API behaviors.

Overall, the advantages of Usage Artifact Mining are concrete: sequences and initializations are often ready to run, resulting in more stable validity. The bottlenecks are equally concrete: the upper limit of reachability is constrained by the coverage of usage artifacts. Once merging or inference is employed to expand diversity, false-positive noise and trial-and-error costs inevitably rise.

3.2. Source Code Constraint Inference

In contrast to usage mining, this trajectory primarily relies on the source code of the target library to derive dominant generation constraints. By analyzing function bodies and header files, it extracts semantic rules and dependencies internally. Some systems in this trajectory further use runtime feedback to refine candidate drivers, but source-level information remains the primary constraint source. This approach enables autonomous driver construction even in scenarios devoid of external usage artifacts and is therefore less susceptible to consumer-side code quality and version lag. The overall pipeline and technical evolution of this trajectory are illustrated in Figure 5.

Figure 5. Processing pipelines and technical evolution of Source Code Constraint Inference trajectory. The figure covers FTG [41], Wildfire [42], IntelliGen [43], GraphFuzz [44], Hopper [45], LibErator [46], AFGen [47], SyRust [48], Rulf [49], Rulf+ [50], and RPG [51].

In early explorations, FTG [41] parses function signatures to deserialize byte streams into concrete parameters for generating wrapper drivers. However, it remains reliant on manual structural annotations for complex data dependencies. To reduce this reliance on expert priors, Wildfire [42] adopts a delimiter-driven simplified deserialization approach: it directly bypasses complex interfaces that are difficult for static analysis to handle. The cost, however, is intuitive—coverage depth is limited when encountering multi-level pointers and complex memory layouts.

Pointer type ambiguity represents an unavoidable obstacle in this trajectory. Addressing this challenge, IntelliGen [43] prioritizes runtime parameter synthesis, employing a Lazy-Store mechanism to defer pointer assignment until the moment of dereference, combined with dynamic context to recursively construct nested structures, thereby enhancing the validity of complex parameters. However, such methods provide weaker solutions for sequence variation: call sequences are typically treated merely as a means to satisfy type dependencies, making it difficult to support sustained exploration oriented towards deep state transitions.

To enhance sequence variation, GraphFuzz [44] represents API interaction sequences as mutable data flow graphs, allowing for the adjustment of call logic through graph node mutation and recombination, thus shifting from single function drivers to multi-interface interactions. Its bottleneck is equally distinct: effectiveness is highly dependent on the completeness of the API Schema. Even if approximately 90% of explicit usages can be automatically inferred, implicit logical constraints such as array length bindings and pointer roles remain difficult to recover stably; once constraints are supplemented manually, deviations directly manifest as misuse and spurious crash noise.

Bypassing reliance on static schemas, Hopper [45] encodes API interactions into a runtime-interpreted domain-specific language (DSL). This avoids repeated compilation overheads while utilizing runtime exceptions and coverage feedback to learn parameter constraints and cross-API dependencies. A critical issue arises when coverage signal granularity is limited: complex initialization prefixes are prone to premature elimination. Meanwhile, the strong coupling of generation and execution amplifies the search space. Consequently, LibErator [46] decouples generation from testing. It employs a static API Flow Graph (AFG) and structural bias to preserve necessary initialization prefixes. Combined with dynamic probing and clustering, LibErator selects a diverse subset of drivers to trade budget for deeper state coverage.

Most existing library fuzzing methods focus their efforts on public or top-level APIs. Top-level interfaces often entail strict validation and complex control flows, making it difficult for random inputs to pass pre-checks. Consequently, internal functions deep within the call chain remain nominally testable but actually unreachable for extended periods. Addressing this unreachability, AFGen [47] proposes whole-function fuzzing: it reconstructs the minimal executable context of target functions using bidirectional slicing and variable assignment, and supplements missing constraints via iterative repair, thereby lowering the test entry point to the internal function level.

While the approaches above are mature for C/C++, Rust presents a very different constraint system. Ownership, lifetimes, and borrowing rules shift the challenges of driver compilability to the compilation stage. SyRust [48], based on type signatures, formalizes ownership and borrowing constraints into SAT constraints and employs solvers to guarantee sequence compilability. The cost, however, is clear. Solving overhead and state explosion pressure bias the generator towards small-scale straight-line code, which limits the input mutation space.

To improve efficiency over heavy solvers, Rulf [49] utilizes a lighter-weight API dependence graph traversal to generate drivers, defaulting to a sequence length limit of 3 to maintain efficiency. However, this limitation confines exploration to shallow interaction intervals and exposes insufficient support for generic semantics. Addressing the combinatorial explosion of generics, Rulf+ [50] mitigates the issue through monomorphization and similarity pruning. To bypass fixed-length thresholds, RPG [51] shifts to pooled generation and dynamic resetting of API pool states, conducting targeted exploration of unsafe code and longer interactions.

From the evaluation perspective of Section 4, the crux of Source Code Constraint Inference lies not in “how many drivers can be generated,” but in the extent to which implicit contracts (initialization, lifecycles, cross-API dependencies) are recovered. Insufficient recovery directly diminishes reachability, while the constraint inference and search mechanisms introduced to compensate for these deficiencies often bring time costs and build stability issues to the forefront.

3.3. Binary Semantics Recovery

In closed-source scenarios, source code is unavailable, and compilation artifacts no longer retain source-level type information or high-level control flow structures. This makes many strategies from Source Code Constraint Inference difficult to apply directly. Consumer code is similarly unreliable in such environments: due to the absence of debug symbols and complex runtime coupling, static dependency analysis often fails to capture stable call boundaries and parameter semantics. Consequently, related work shifts towards binary-centric approaches that utilize disassembly, instrumentation, and execution traces to recover interface semantics and dependency relationships, subsequently synthesizing runnable drivers. The overall pipeline and technical evolution of this trajectory are illustrated in Figure 6.

Figure 6. Processing pipelines and technical evolution of Binary Semantics Recovery trajectory. The figure covers Winnie [52], ApiCraft [53], Minerva [54], and Atlas [55].

Winnie [52] leverages execution trace recovery to bypass the opacity of GUI interaction paths, rendering core logic more easily accessible. In more common closed-source SDK scenarios, the challenge shifts to assembling dependencies among multiple APIs. To synthesize these dependencies, ApiCraft [53] adopts a collect-combine strategy and a multi-objective genetic algorithm, primarily addressing the synthesis of explicit parameter dependencies and error handling. Its boundaries, however, are clear: it provides insufficient coverage for implicit dependencies induced by global variables and shared memory.

Addressing the gap in implicit dependency recovery, Minerva [54] introduces dynamic Mod-Ref analysis. It tracks memory reads and writes via instruction-level instrumentation to construct API interference graphs, which characterize such implicit coupling. The cost of this approach is a substantial performance overhead caused by the granular analysis. Consequently, this overhead typically limits Minerva to offline analysis.

Sustaining dynamic tracing is even more challenging on closed-source Android native libraries. Cross-language invocations and strong dependencies on the Java/Android Runtime (ART) make tracing in emulated environments prone to interruption by JNI calls. To maintain stable execution, common practices typically involve manual reverse engineering followed by binary patching. However, this approach incurs prohibitively high costs. To overcome these tracing hurdles, Atlas [55] shifts to cross-language static analysis. It combines native code and Java bytecode analysis to jointly infer dependency relationships and parameter constraints between the Native and Java layers, thereby generating usable API call sequences without relying on runtime tracing.

From an evaluation perspective, this trajectory faces a long-standing trade-off between the semantic gap and observation overhead (or stability). The finer the tracing employed to bridge the semantic gap, the higher the overhead and the lower the runtime stability. Ultimately, this narrows the effective budget window capable of entering the continuous fuzzing loop.

3.4. Heterogeneous Data Fusion

Each of the preceding three trajectories relies on a single dominant data source: usage artifacts, source code, or binaries. In practice, however, the constraints needed for high-quality drivers are scattered across multiple sources, including code comments, API documentation, and build or runtime feedback. This trajectory groups methods that jointly exploit several such sources, with no single one playing a dominant role. The fusion may take place during initial generation, during iterative repair, or both. In recent work, LLMs frequently serve as the integration mechanism, although LLM use alone does not define this category.

LLMs contribute to constraint recovery in two ways. On the one hand, they process and align heterogeneous inputs, such as code snippets and documentation, into consistent generation constraints through in-context reasoning. On the other hand, they supply additional priors acquired during pre-training on large-scale corpora [56]. By combining LLMs with retrieval, static analysis, and dynamic feedback, recent systems can translate unstructured clues into executable code more effectively. The overall pipeline and technical evolution of this trajectory are illustrated in Figure 7.

Figure 7. Processing pipelines and technical evolution of Heterogeneous Data Fusion trajectory. The figure covers TitanFuzz [57], PromptFuzz [58], AutoGen [59], CKGFuzzer [60], PromeFuzz [61], and Scheduzz [62].

TitanFuzz [57], targeting operator combinations heavily constrained by tensor semantics in deep learning libraries, proposes a zero-shot fuzzing framework based on LLMs. It constructs drivers that satisfy tensor computational semantics through generative synthesis. TitanFuzz represents an early open-loop instantiation within this broader trajectory. Its main contribution is the LLM-mediated alignment of heterogeneous semantic clues, and it predates the introduction of explicit multi-source feedback loops. However, API interactions in general-purpose C/C++ libraries often rely on more implicit preconditions, such as resource lifecycle management and error branch control, making end-to-end generation difficult to migrate directly.

Empirical studies by Jiang et al. [63] and Zhang et al. [64] indicate that, in their evaluated settings, LLM-generated drivers frequently exhibit two main types of failures. The first is build chain failure. Drivers often fail to compile or link due to unsatisfied types, missing symbol resolutions, or build constraints. Even when compiled, they may terminate abnormally at the onset of execution due to violations of implicit contracts. Consequently, a substantial number of samples fail to meet the minimum threshold of build success, with one cited study reporting build-failure rates of around 60% in its benchmark setting. The second failure type is insufficient coverage generalization. Models exhibit a bias towards high-frequency, short call patterns, demonstrating limited capability in generating drivers for long-tail APIs and deep cross-function state transitions. These results suggest that LLM-based driver generation for general-purpose libraries benefits from integrating validity and reachability into a closed-loop system, rather than relying solely on one-shot generation.

Addressing the shortcomings of open-loop generation, PromptFuzz [58] advances coverage guidance to the generation phase. It iterates over prompt mutation and utilizes coverage feedback to drive the model to produce drivers capable of entering new branches. While it successfully addresses the question of “where to probe,” it offers limited assistance regarding “how to compile, link, and run sustainably.” Toolchain constraints, macro switches, and dependency versions still obstruct a vast number of samples at the build and startup stages. Consequently, subsequent work integrates LLMs into an engineering closed loop comprising compilers, build systems, and static analyzers. Figure 8 illustrates this iterative workflow of generation, validation, and repair. This closed-loop design allows error reports and runtime feedback to participate in the repair process, rather than treating the model as an isolated code generator.

Figure 8. General workflow of Heterogeneous Data Fusion.

In the engineering dimension, AutoGen [59] incorporates function declarations, build configurations, and error messages into an iterative repair process, primarily targeting validity deficits. It compiles and debugs immediately after generation, using error signals to drive the next round of rectification. In the semantic dimension, CKGFuzzer [60] introduces a code knowledge graph (CKG) to capture call relationships and structured dependencies. This supplements cross-function constraints that are ambiguous in raw text, stabilizing execution by iteratively correcting compilation errors and API misuses.

Building upon this, PromeFuzz [61] further enhances the semantic density of the context. In addition to graph structures, it introduces finer-grained metadata dependencies and multi-dimensional API association information. It parses object dependencies, such as structures and enumerations, to ensure the validity of initialization chains. Furthermore, it measures inter-function connectivity across dimensions like type compatibility, scope interaction, and semantic relevance to guide more coherent API sequences. Simultaneously, PromeFuzz attempts to transform certain implicit usages into explicit constraints, dynamically correcting them via runtime feedback. The cost is equally apparent: its effectiveness relies on the accuracy of documentation and metadata. Outdated or misleading information introduces errors into constraint inference, thereby increasing repair cycles.

Relying solely on richer static context also encounters an upper bound: lacking dynamic modeling of implicit usage conventions, generators often produce numerous drivers that fail quickly at runtime. This consumes computational budgets on predictable exceptions and short paths. Scheduzz [62] explicitly formulates this issue as online scheduling. It employs LLMs to infer implication and conflict constraints between APIs and places driver generation and execution within a unified two-level scheduling framework. This suppresses irrational combinations while allocating computational resources to reduce the proportion of short-lived samples.

In summary, while Heterogeneous Data Fusion expands the scope of exploitable constraints, it remains bound by the same fundamental tension observed in the preceding trajectories. As detailed in Table 1, a cross-cutting analysis reveals a persistent trade-off: Usage Artifact Mining prioritizes validity at the expense of reachability boundaries; Source Code Constraint Inference seeks systematic coverage but falters on implicit contracts; and Binary Semantics Recovery struggles with the semantic gap. Heterogeneous Data Fusion aims to bridge these gaps by combining heterogeneous constraints, often via closed-loop generation–validation–repair in later systems, yet it introduces stochasticity in validity and nontrivial cost overheads. Consequently, the lack of a unified benchmark across these diverse data sources motivates the bounded comparability-oriented evaluation perspective introduced in Section 4, which shifts focus from mere generation capability to reproducibility and cost-effectiveness.

4. Evaluation Perspective and Engineering Practice

From the perspective of systematic evaluation in software security engineering, this section develops a bounded comparability-oriented evaluation perspective for automated fuzz driver generation approaches. To avoid result-oriented comparisons relying solely on metrics like coverage or vulnerability discovery, this review organizes the reported evidence around three core evaluation dimensions: validity, reachability-related evidence, and reproducibility and experimental cost disclosure.

Among them, validity measures whether a system can stably generate drivers that cross the build-and-launch threshold, which is a prerequisite for subsequent coverage growth and defect discovery. Reachability-related evidence reflects whether reported results indicate support for deeper state exploration beyond superficial execution, although in current literature this is usually approximated through self-reported coverage gains after plateaus or the triggering of new APIs. Reproducibility and experimental cost disclosure concern the verifiability and interpretability of reported results, including benchmark versions, runtime settings, and resource consumption under each study’s own evaluation setup, especially for systems relying on external models and complex build environments. This dimension should be distinguished from the broader deployment-side Total Cost of Ownership (TCO) discussion in Section 4.3. The reporting protocol introduced in Section 4.1 is a four-stage disclosure checklist rather than a fourth conceptual dimension. Stage I (Engineering Validity Reporting) aligns with validity; Stage II (Coverage Reporting) aligns with reachability-related evidence; Stage III (Defect Yield Reporting) records downstream outcome evidence; and Stage IV (Yield and Budget Disclosure) records optional within-study yield descriptors and budget disclosures. Broader reproducibility barriers beyond this disclosure checklist are discussed separately in Section 4.2.

Based on this evaluation perspective, this section sequentially explores reported metrics and their limited cross-literature interpretability, reproducibility barriers and minimum disclosure requirements, as well as deployment-side engineering constraints and TCO considerations for the transition from academic prototypes to industrial applications.

4.1. Metrics and Limited Comparability

Despite rapid advancements in the field of automated fuzz driver generation, existing public evaluation results lack unified standards regarding benchmarks, coverage metrics (e.g., line/branch/block/function granularity), and experimental budgets and settings. Furthermore, existing literature exhibits a significant gap in the disclosure of critical experimental data. For instance, some works [33,42] only report the final number of discovered vulnerabilities, completely omitting data on the scale of generation. Conversely, other works [34,53] provide the total number of generated candidates but fail to disclose the number of valid drivers that passed compilation and checks. This impedes the evaluation of conversion efficiency from generation to execution. This absence of data dimensions means that direct cross-literature comparisons of the absolute values of coverage or crashes often lack a baseline.

4.1.1. Fuzz Driver Validity

Regarding driver validity evaluation, this paper identifies 15 tool proposals that report both the total number of generated candidates ($Total$) and the number of valid drivers ($Valid$) (as shown in Table 2). In this survey, “valid” driver counts are adopted as reported by each study. Based on these data, this work computes driver validity rate (DVR) and trial-and-error cost ratio (TEC) under each study’s original reporting conventions, defined as $DVR={\displaystyle \frac{Valid}{Total}}\times 100\%$ and $TEC={\displaystyle \frac{Total}{Valid}}$. DVR and TEC values are computed solely from the 15 tool proposals that disclosed both Total and Valid counts; the remaining 14 tool proposals in Table 2 did not systematically report these figures.

Table 2. Reported Evaluation Metrics in Surveyed Tool Proposals.

Category	Tool Proposal	Year	Total Gen.	Valid	DVR (%)	TEC	Crash Rep.	TP Rep.	CVEs	Cov.Met
Usage Artifact Mining	Fudge	2019	-	-	-	-	-	>600	-	-
	FuzzGen	2020	52	-	-	-	-	17	6	E
	FRIES	2024	1000	990	99.00	1.01	31,390	130	-	L
	FuzzBuilder	2019	9	9	100.00	1.00	-	4	-	L
	Utopia	2023	5126	5126	100.00	1.00	1167	123	-	L
	Daisy	2023	22	22	100.00	1.00	-	9	3	Bl
	Rubick	2023	11	-	-	-	53,975	199	4	E
	Nexzzer	2025	-	-	-	-	7291	27	-	L
Source Code Constraint Inference	FTG	2019	73	-	-	-	91.2 (avg)	14	-	-
	Wildfire	2019	-	-	-	-	-	38	-	L, F
	IntelliGen	2021	-	-	-	-	-	32	-	Bl, P
	GraphFuzz	2022	10	-	-	-	-	17	-	L
	Hopper	2023	-	-	-	-	-	25	-	L, Br
	LibErator	2025	17,061	927	5.43	18.40	81	24	1	Br, L
	AFGen	2024	-	5292	-	-	655	505	24	-
	SyRust	2021	27.2 M	27.0 M	99.26	1.01	-	4	-	L, Br
	Rulf	2021	562	557	99.11	1.01	8992	30	-	A
	Rulf+	2023	2566	2463	95.98	1.04	10,319	23	-	-
	RPG	2024	2121	2008	94.67	1.06	4784	25	-	-
Binary Semantics Recovery	Winnie	2021	59	59	100.00	1.00	-	61	-	Bl
	ApiCraft	2021	90,000	-	-	-	-	142	54	Br
	Minerva	2022	-	-	-	-	-	35	5	E
	Atlas	2024	820	621	75.73	1.32	-	74	16	Bl
Heterogeneous Data Fusion	TitanFuzz	2023	35,110	12,142	34.58	2.89	-	20	-	L
	PromptFuzz	2024	40,850	963	2.36	42.42	44	33	-	Br
	AutoGen	2024	-	-	-	-	-	-	-	E
	CKGFuzzer	2025	798	750	93.98	1.06	199	11	-	Br
	PromeFuzz	2025	2577	2031	78.81	1.27	29	26	3	Br, A
	Scheduzz	2025	-	4480	-	-	-	33	3	R, Br

Note: $DVR={\displaystyle \frac{Valid}{Total}}\times 100\%$, $TEC={\displaystyle \frac{Total}{Valid}}$. ”-” indicates data not reported. Cov.Met: (E)dge, (L)ine, (Bl)ock, (Br)anch, (A)PI, (P)ath, (F)unction, (R)egion. TP represents true positive, referring to manually verified bugs or vulnerabilities, with definitions following the original paper’s terminology. Reported crash and TP evidence may appear as totals, averages, or lower bounds, following the original studies. Valid and TP values are taken directly from each study’s reported results. DVR and TEC are derived from disclosed counts. A survey-wide $TP/Valid$ column is omitted because $TP$ and $Valid$ are frequently missing across studies.

Among studies that disclosed both Total and Valid counts, DVR values range widely. Utopia, FRIES, Rulf, SyRust, and RPG each report DVR values above 94%, while their TEC values remain close to 1.00. Taking Utopia as an example, it reports $DVR=100\%$ and $TEC=1.00$. Within the original reporting conventions of these studies, this indicates low disclosed filtering overhead from candidate generation to valid drivers.

In contrast, PromptFuzz ($DVR\approx 2.36\%$, $TEC\approx 42.42$) and LibErator ($DVR\approx 5.43\%$, $TEC\approx 18.40$) report much lower validity rates, while the $DVR$ of TitanFuzz remains around 35%. These differences reflect a combination of tool design choices, target library characteristics, and differing validity criteria.

These data suggest two observations. First, disclosed filtering efficiency varies substantially across studies. Second, significant disparities in validity appear within the same technical category. For instance, within Source Code Constraint Inference, there are both high-validity methods like Rulf and RPG, and lower-validity ones like LibErator. This indicates that taxonomy labels alone cannot fully explain the reported differences in validity. The surveyed tools also span 2019–2025, a period during which toolchain support, LLM-assisted synthesis, and evaluation practices improved substantially.

4.1.2. Defect Yield

Within this reporting protocol, defect yield is treated as downstream outcome reporting rather than as a fourth evaluation dimension. The number of CVEs and true positives (TPs) serves as useful evidence for measuring the practical value of tools. However, vulnerability confirmation cycles, generation scale, target selection, fuzzing budgets, deduplication rules, and disclosure practices differ substantially across studies. To supplement these absolute counts, this paper treats the defect yield rate per valid driver ($TP/Valid$), when both $TP$ and $Valid$ are explicitly disclosed, as a descriptive indicator of reported utility. Atlas reports $TP/Valid=74/621$ within its experimental evaluation. LibErator and PromeFuzz each report non-trivial unit yield figures within their respective settings. TitanFuzz, which relies on large-scale generation, reports a lower $TP/Valid$ value under its own metrics.

Comparing the absolute number of triggered crashes across existing literature has limited validity. As shown in Table 2, the papers differ in targets, budgets, deduplication rules, and TP definitions. In a few individual studies, usage-based or source-based systems report many raw crashes before manual triage, whereas some heterogeneous-data systems report fewer raw crashes and a higher share of manually confirmed findings under their own settings.

Differences in adherence to the internal logic of the library contribute to such outcomes. Approaches within the Source Code Constraint Inference trajectory rely on aggressive API orchestration. Although such drivers successfully build and execute, they also employ APIs in logically incorrect ways, such as passing NULL to non-nullable buffers. These actions increase the number of spurious crashes unrelated to actual library defects. Similarly, as discussed in Section 3.1, usage-based approaches inherit incorrect patterns from flawed consumer code or introduce misaligned sequences during the slicing process.

Heterogeneous Data Fusion often attempts to integrate diverse constraints from documentation and multifaceted code contexts. Some recent studies report fewer futile executions and a higher share of manually confirmed findings under their own experimental settings. Therefore, the sheer number of crashes remains a weak indicator of a generator’s efficacy. To better reflect practical security impact, TP count and clearly explained triage criteria should be prioritized, with CVE count used as supplementary evidence when available.

4.1.3. Coverage Efficacy

Coverage efficacy is interpreted here as reachability-related evidence reported within each study’s own experimental setting. Because benchmark suites, coverage granularity (see the Cov.Met column in Table 2), seed corpora, time budgets, and target libraries differ substantially across works, this subsection examines two recent works published in 2025, PromeFuzz and LibErator, whose results show improvement over prior-system or expert-written baselines within each study’s own experimental setting. For example, PromeFuzz [61] reports branch coverage gains of 1.50× over PromptFuzz [58], 3.88× over CKGFuzzer [60], and 1.40× over OSS-Fuzz manual drivers, each measured within PromeFuzz’s own experimental setting. Similarly, LibErator [46] reports better coverage than expert-written drivers in half (6/12) of the tested libraries within its own evaluation. However, this coverage advantage exhibits significant library dependency. For stateless or shallow parsing libraries such as cJSON and zlib, tools can reach branch coverage ranging from 75% to 85% in the reported settings. In contrast, for libraries containing complex state machine logic, such as libavc and libtiff, reported coverage drops to below 25% or even less than 10%. These case-specific results are consistent with the view that deep-state reachability remains a major unresolved challenge.

Therefore, when evaluating driver generation systems, one should not rely solely on an isolated metric. Instead, coverage should be systematically integrated with dimensions such as generation scale and the capability to reveal real-world defects. This provides a more interpretable multi-dimensional view of actual tool efficacy. To improve the transparency of cross-literature interpretation, this paper introduces a “Minimal Disclosure Checklist for Limited Metric Comparability,” as shown in Table 3. The heterogeneity in reporting practices documented above motivates this checklist, which serves as a disclosure layer.

Table 3. Minimal Disclosure Checklist for Limited Metric Comparability.

Reporting Stage	Metric Item	Required Disclosure
Stage I: Engineering Validity Reporting	Engineering Validity	Disclose Total & Valid counts State the minimum validity criterion used and report DVR & TEC under that criterion
Stage II: Coverage Reporting	Coverage Efficacy	Unify granularity (e.g., Edge/Branch) Provide recalculable raw data
Stage III: Defect Yield Reporting	Defect Yield	Prioritize TP & CVE over raw crashes Clarify deduplication criteria
Stage IV: Yield and Budget Disclosure	Yield/Budget Disclosure	If both TP and Valid are explicitly defined and jointly reported, report Unit Yield (TP/Valid) Disclose generation scale and the units of the reported budget/cost

4.2. Reproducibility Barriers and Standardization

The issue of metric heterogeneity discussed previously primarily weakens the horizontal comparability among different studies. Meanwhile, the deficiency in reproducibility evaluation further limits the validity of conclusions from a single study over the temporal dimension. In the domain of automated fuzz driver generation, reproducibility implies not merely open-sourcing code but represents an engineering challenge. This challenge encompasses environment construction, benchmark version pinning, randomness control, and external dependency management. With the evolution of the Heterogeneous Data Fusion trajectory (predominantly driven by LLMs), the difficulty and uncertainty of reproducing experiments have further escalated due to the involvement of closed-source API calls and probabilistic generation mechanisms.

This paper categorizes and summarizes representative studies from five dimensions (as detailed in Table 4): (1) Artifact Completeness: Whether, in addition to source code, automated build scripts and directly executable containerized environments (e.g., Docker images) are provided to reduce reproducibility barriers caused by environmental dependencies. (2) Benchmark Version Pinning: Whether specific versions of target programs (e.g., commit ID or release version) are explicitly specified, and whether publicly accessible benchmark sets are utilized. This dimension differs from heterogeneity at the benchmark set level. Even if studies employ benchmarks with identical names, the reproduction process may still be distorted by target drift if version information and acquisition methods are not clarified. (3) Initial State Consistency: Whether the seed corpus used in experiments is provided to ensure the alignment of the initial state of fuzzing. (4) Experimental Parameters: Whether key runtime parameters (e.g., time budget, number of experimental repetitions, etc.) are disclosed; monetary or token-level costs, when reported, are discussed separately in Section 4.3. (5) LLM-Specific Dependencies: If relying on commercial closed-source models, model updates may cause identical code and prompts to yield inconsistent outputs at different times. This directly affects experimental reproducibility.

Table 4. Reproducibility Checklist of Surveyed Fuzz Driver Generation Studies.

Category	Study	Artifact Completeness			Benchmark		Exp. Config & Params			LLM
		Code	Script	Docker	Public	Pinned	Rep.	Seed	Time Budget
Usage Artifact Mining	Fudge	✗	✗	✗	✗	✗	10	◯	5 m	◯
	FuzzGen	✓	✗	✗	✓	✗	5	◐	24 h	◯
	FRIES	✗	✗	✗	✓	✗	-	◐	4 h	◯
	FuzzBuilder	✓	✓	✓	✓	✓	1	⬤	6 h	◯
	Utopia	✓	✓	✓	✓	✓	10	⬤	100 h/n	◯
	Daisy	✗	✗	✗	✓	✗	5	◯	24 h	◯
	Rubick	✓	✓	✗	✓	✓	10	⬤	24 h	◯
	Nexzzer	✓	✗	✓	✓	✗	5	⬤	24 h	◯
Source Code Constraint Inference	FTG	✗	✗	✗	✗	✓	5	◐	10 h	◯
	Wildfire	✓	✗	✗	✓	✓	5	⬤	60 s	◯
	IntelliGen	✗	✗	✗	✓	✗	10	◐	6 h	◯
	GraphFuzz	✓	✓	✓	✓	✗	5	⬤	48 h	◯
	Hopper	✓	✓	✓	✓	✗	5	⬤	24 h	◯
	LibErator	✓	✓	✓	✓	✓	5	⬤	24 h	◯
	AFGen	✗	✗	✗	✓	✗	10	◐	24 h	◯
	SyRust	✗	✗	✗	✓	✓	-	◯	10 h	◯
	Rulf	✓	✓	✓	✗	✓	-	⬤	6 h	◯
	Rulf+	✓	✓	✓	✗	✓	-	⬤	24 h	◯
	RPG	✓	✗	✓	✓	✗	3	⬤	2–6 h	◯
Binary Semantics Recovery	Winnie	✓	✗	✗	✓	✗	5	◐	24 h	◯
	ApiCraft	✓	✗	✗	✗	✗	10	⬤	-	◯
	Minerva	✓	✗	✗	✓	✗	5	◯	24 h	◯
	Atlas	✗	✗	✗	✓	✓	10	⬤	24 h	◯
Heterogeneous Data Fusion	TitanFuzz	✓	✓	✓	✓	✓	5	⬤	9.9–21 h	⬤
	Zhang et al. [64]	✓	✓	✓	✓	✓	40	◯	24 h	⬤
	CKGFuzzer	✓	✗	✗	✓	✓	5	⬤	24 h	⬤
	Scheduzz	✗	✗	✗	✓	✗	-	◐	-	⬤
	AutoGen	✗	✗	✗	✓	✗	5	◯	1 h	◐
	PromptFuzz	✓	✓	✓	✓	✓	5	⬤	24 h	⬤
	PromeFuzz	✓	✓	✓	✓	✓	10	⬤	24 h	⬤

Symbols: ✓ Available/Specified; ✗ Unavailable/Unspecified; Seed: ⬤ Provided & Reproducible; ◐ Used but Unavailable; ◯ Not Used; Rep.: Number of repeated experiments. Time Budget: Evaluation time budget (e.g., $100 h/n$ indicates 100 h per n drivers); LLM: ⬤ LLM used (Model & Version specified); ◐ LLM used (Version unspecified); ◯ Non-LLM.

With respect to Artifact Completeness (1) and Benchmark Version Pinning (2), code availability has improved in a majority of recent studies (Table 4 indicates that approximately 70% of approaches provide source code), but among the 20 studies providing source code, 9 are missing at least one of standardized build scripts and containerized environments, including 6 that provide neither, as shown in the Script and Docker columns of Table 4. C/C++ projects typically rely on specific compilers, instrumentation toolchains (e.g., Clang/LLVM versions) [65], and complex build processes. Consequently, the prevailing “code-heavy, environment-light” release practice compels independent researchers to invest significant effort in reconstructing execution environments. Furthermore, this instability is compounded when studies fail to explicitly pin benchmark versions (e.g., specific commit IDs). Even with identical benchmark names, the unaccounted-for target drift renders the reproduction process non-deterministic, ultimately undermining the reliability of reported metrics like code coverage and vulnerability discovery.

Turning to Initial State Consistency (3), undisclosed key information within experimental configurations poses another major barrier. Fuzzing is extremely sensitive to initial states, and the coverage quality of the seed corpus can strongly influence the attainable extent of subsequent coverage growth. If a paper fails to disclose the initial corpus or explain its generation methodology, it becomes impossible for independent researchers to replicate a consistent coverage evolution process, even when utilizing the identical tool and code. As quantified in the Seed column of Table 4, although 24 studies employed an initial seed corpus, only 17 made these corpora publicly available, undermining the falsifiability of their research conclusions.

Finally, LLM-Specific Dependencies (5) and cost-related reproducibility constraints have introduced a new class of complex reproducibility barriers. The first is the “moving target” effect. When an approach relies on commercial closed-source APIs (e.g., the GPT series), updates to the backend model may induce drift in generation behavior even if the prompt and code remain unchanged [66,67]. If verifiable model fingerprints are not strictly locked, experimental results become one-off temporal cross-sections that are difficult to verify longitudinally. The second barrier concerns the economic constraints of reproducing these results. Large-scale LLM evaluations are accompanied by substantial API costs and resource quota limitations. (A detailed analysis of these cost constraints in industrial deployment is provided in Section 4.3.) If token/invocation costs are left opaque, academic teams face obstacles in verifying the efficacy at the same scale, potentially introducing bias when comparing coverage and defect yield under inequitable budget conditions.

The aforementioned phenomena reflect a practical trade-off within the field. Some approaches provide complete artifacts and controllable dependencies, and can serve as reliable and reproducible baselines. In contrast, some advanced systems face weaker reproducibility due to their reliance on closed-source components and high operational costs. This often creates a gap between strong reported results and the ability of others to independently verify them.

This paper proposes establishing a minimum reproducibility standard. In addition to open-sourcing code, researchers should provide directly reproducible environment encapsulation (Docker/scripts), explicit benchmark version pinning, and full disclosure of the initial corpus and runtime parameters. Furthermore, for LLM-related approaches, it is also necessary to lock verifiable model versions/fingerprints, disclose inference costs and quota assumptions, and publicly release prompts. Incorporating reproducibility levels into the dimension of tool maturity evaluation facilitates the convergence of fuzz driver generation evaluation towards verifiable and cumulative empirical research.

4.3. Industrial Deployment and Cost Considerations

Although current automated fuzz driver generation methods have made significant progress in technical metrics such as code coverage and execution efficiency, algorithmic advantages do not necessarily translate into actual productivity in industrial settings. Whereas Section 4.2 focused on disclosure needed for reproducibility, this subsection turns to deployment considerations, especially the operational Total Cost of Ownership (TCO) of deploying these systems in practice. Existing studies [68] indicate that migrating academic prototypes to large-scale industrial codebases introduces severe barriers. These engineering barriers, such as toolchain incompatibility, complex build systems, and the scarcity of reusable test assets, often significantly raise deployment costs and undermine actual benefits. Therefore, the industrialization of automated fuzz driver generation depends not only on single-point algorithmic capabilities. It is also constrained by three key lifecycle engineering attributes: developer adoption, total cost of ownership (TCO), and pipeline integration.

First, the key to developer adoption lies in the maintainability and comprehensibility of the generated artifacts, rather than solely in coverage improvement. Many academic approaches treat drivers as disposable artifacts. These approaches lack systematic evaluation of code readability, dependency resolution, invocation context construction, and long-term maintenance burdens. Consequently, it becomes difficult for the generated results to integrate into a continuously evolving test asset system. In industrial settings, teams focus more on whether the driver can be stably built, whether it facilitates debugging and regression, and whether it can be patched at low cost during version iterations. In other words, the ability to achieve stable build success with low filtering overhead often constitutes a practical prerequisite in deployment. If a large number of candidates cannot be compiled, linked, or run stably, developers will be forced to invest substantial manual effort in patching and screening. This overhead significantly reduces the willingness to adopt.

Second, with the introduction of LLMs, the cost–benefit model presents more quantifiable structural changes. Methods based on use case or artifact reuse typically incur high one-time adaptation costs (e.g., toolchain compatibility, patch maintenance, and build script engineering). However, the marginal operational costs during the generation phase are relatively low. In contrast, the primary costs of the LLM route are more directly manifested as continuous overheads that grow with the scale of invocation (e.g., token fees, inference time, and quota constraints). These costs are easily further amplified by the iterative loop of invalid candidate retry and repair. Existing large-scale evaluations indicate [63,64] that the generation process often requires multiple rounds of queries to produce a valid driver, thereby pushing the cost per unit of effective yield to a system-level cost.

Some studies have begun to explicitly constrain this process in the form of monetary or query-budget constraints. For example, PromptFuzz reports a total LLM query cost of $63.14 for a screened subset of 3785 seed programs across 14 libraries, providing a token-based accounting method. This figure refers to a later filtered stage of the workflow and is distinct from the total generated-candidate count of 40,850 reported in Table 2. Scheduzz further sets a monetary call cost cap of $5 per library to inhibit cost overruns during the generation phase. PromeFuzz provides an end-to-end multi-library cost ledger (total monetary cost of $15.89 for 22 libraries, 98.4M tokens) and additionally reports a per-API generation time of approximately 21 s/API and a per-API monetary cost of $0.005/API. Furthermore, PromeFuzz explicitly states that different modules employ different models (e.g., GPT-4o mini [69] and DeepSeek [70] series) to reduce inference overhead. These results also indicate that without disclosing the model name, version, and billing basis, cost conclusions will generate uninterpretable biases due to differences in model unit prices and success rates. In budget-sensitive industrial scenarios, determining whether an LLM solution possesses a TCO advantage hinges not on the price of a single call, but on the efficiency of cost–value matching. This engineering constraint echoes the evolutionary direction proposed in Section 5.2: what the industry requires is not merely lower-cost, less capable models, but intelligent systems capable of dynamic compute allocation. Therefore, future engineering should incorporate cost constraints into scheduling logic to achieve explicit optimization among model capability, driver efficiency, and budget. Strategies such as hierarchical models (low-cost filtering and constraint extraction + high-capability repair and refinement), budget scheduling, and quality gating can be adopted, rather than solely optimizing for bug count or coverage.

Finally, pipeline integration determines whether the technology can form a sustainable engineering closed loop. From the prevailing practices of industrial security engineering and DevSecOps, an ideal driver generation process should be able to run as an orchestratable step in CI/CD and form a synergy with build systems and defect management systems. However, most current academic prototypes remain at the stage of offline, localized execution. They lack general handling capabilities for complex build and CI/orchestration systems (e.g., Bazel, Soong, Blueprint, and Jenkins), non-standard compilation options, dependency resolution, version pinning, and automatic repair of build failures. Beyond generating the driver itself, environment containerization, failure retry, diagnosability construction, and automatic interfacing with defect tracking systems (e.g., Jira) are often the key determinants of deployment costs and long-term maintenance costs.

5. Challenges and Future Directions

Figure 9 summarizes the three open challenges discussed in this section and maps each to candidate future directions.

Figure 9. Technical Roadmap for Automated Fuzz Driver Generation: From Challenges to Future Directions.

5.1. Challenge I: Coverage Plateaus and Reachability Bottlenecks

The phenomenon of coverage plateau is prevalent in current fuzzing practices, where code coverage tends to stagnate after a saturation window of 12 to 24 h [15,71]. The plateau does not necessarily reflect insufficient input exploration; another explanation is that, while testing investment continues to increase, the marginal returns in new coverage and vulnerabilities decline rapidly, leaving deep logic unreachable for extended periods [72]. This forms a latent bottleneck characterized by computational accumulation but stagnant effective exploration.

The key to understanding the formation of the plateau lies in distinguishing two types of unreachability causes. The first is input-dependent blocking, where input data fails to meet format or validation requirements, causing the program to interrupt before touching core logic. The root of this issue lies in input distribution and constraint satisfaction. The second is structural unreachability (or input-independent blocking), stemming from logical defects within the driver itself. These defects include incorrect API call sequences, missing environmental states, or unobserved parameter contracts. This effectively renders the target code unreachable regardless of input quality [73]. This phenomenon essentially reflects the deficiency of drivers in the deep reachability dimension described in Section 4. Although the driver achieves build success, it fails to construct the semantic context required to reach deep state machines, thereby confining the fuzzer to shallow state spaces.

Transitioning from one-off synthesis to reachability-oriented structural evolution represents a concrete research path, where coverage stagnation serves as a feedback signal driving a closed-loop refinement process. This evolution trajectory includes three research foci: (1) developing techniques to contrast static call graphs with dynamic coverage traces; (2) leveraging program analysis or generative models to infer the root causes of blocking within the driver’s context; and (3) establishing mechanisms for minimally invasive patching, where drivers are iteratively refined based on attribution results and rapidly verified through short-cycle fuzzing.

To rigorously assess progress in this direction, the community requires shared reachability evaluation criteria. These should incorporate metrics such as post-plateau coverage gain, localization accuracy (e.g., Top-k hit rate of blocking causes), and evolutionary efficiency (e.g., coverage gain per unit iteration cost).

5.2. Challenge II: Context Dilemma

As discussed in Section 3.4, existing works have mitigated the context scarcity problem in the open-loop generation phase to a certain extent through heterogeneous context injection and closed-loop repair. However, in general library scenarios, driver generation still faces a more fundamental context dilemma: the critical semantic clues relied upon for generating high-quality fuzz drivers often cannot be simultaneously provided in full and kept sufficiently noise-free within the model’s limited context window [74].

Current mainstream static injection strategies typically construct prompts by pre-retrieving heterogeneous context. Under fixed window constraints, this one-off input mechanism tends to lead to two prominent failure modes. First, the generated code is syntactically viable but semantically deviant, triggering spurious crashes and execution spinning. Second, critical information is interfered with by irrelevant context or truncated due to window limits. This results in incomplete type definition acquisition, inconsistent conditional compilation (controlled by preprocessor macros) path selection, and symbol resolution failures during the linking stage. Specifically, when macro switches, build flags, and link dependencies are dynamically determined by the external environment, static injection, even with broader coverage, struggles to guarantee context consistency and reproducibility.

The root causes of the context dilemma are primarily manifested in two aspects. The first is the insufficiency of implicit constraints. In C/C++ libraries, the correct usage of APIs relies not only on function signatures but also involves implicit contracts, such as object initialization order, memory ownership transfer, resource lifecycle management, and behavioral differences under specific macros or feature switches. Since static retrieval struggles to capture these cross-function and cross-file non-local semantic constraints, the generated driver code, while potentially passing compilation, often violates specifications at the semantic level. This triggers foreseeable exceptions (such as null pointer dereferences caused by failure to call init() or unconfigured resources) and masks true vulnerabilities. The second root cause is context overflow induced by dependency explosion. Statically injecting massive header file dependency trees consumes an excessive number of tokens. This often breaches the LLM’s context window limit and leads to input truncation. When information integration is excessive, dependency and configuration details irrelevant to the target API rapidly occupy token space. This causes critical type definitions and macro switches to be masked by noise or truncated. Therefore, this problem is essentially a structural contradiction between the insufficiency of critical semantic clues and dependency noise overload under fixed windows.

Moving from static context injection to dynamic closed-loop generation addresses the root cause of context overflow and implicit constraint loss. This turns one-off generation into a process of iterative retrieval and environmental alignment to improve context precision and build validity. Candidate strategies include: (1) dynamic build alignment, where the system refines drivers based on trial-compilation feedback; (2) on-demand context expansion, where only the minimum necessary data are retrieved; and (3) budget-aware scheduling, where inference depth is adjusted according to target complexity and cost constraints.

The overall effectiveness of these mechanisms should be evaluated as consistently as possible under controlled experimental settings. Metrics should cover build validity (e.g., compilation/link pass rate), generation efficiency (e.g., average iteration rounds), context quality (e.g., compression rate, recall of critical definitions), and cost-effectiveness (e.g., coverage gain per unit cost).

5.3. Challenge III: Ecosystem Heterogeneity

Although existing automated fuzz driver generation techniques often perform well for libraries written in a single language, they generally show limited methodological generalizability. The current literature has not established that the same generation method can reliably generate drivers across multiple programming languages (e.g., Java, Rust, Go). This is because generation algorithms are usually tightly coupled with language-specific toolchains (e.g., Clang AST). Consequently, the core generation logic is difficult to reuse across different ecosystems, which leads to fragmented solutions and higher scalability costs.

This issue is primarily caused by two factors. First, there are significant differences in the implicit environmental preconditions across different languages. These conditions are usually not explicitly declared in function signatures, nor are they necessarily directly reflected in the code. Taking C/C++ as an example, drivers typically require manual management of memory and resources. In managed languages like Java and Go, however, a vast number of preconditions originate from the runtime environment. These include garbage collection mechanisms, virtual machine states, runtime contexts, and exception handling semantics. The situation becomes more complex if the target library runs within a framework: whether it can enter the correct execution state may also depend on assembly processes such as external configurations, reflection mechanisms, or runtime dependency injection [75]. Therefore, a generation strategy that successfully constructs call sequences in one language often fails to synthesize valid drivers for another, simply because it cannot automatically infer these distinct environmental initializations. Second, the divergence in feedback mechanisms hinders unified iterative optimization. In C/C++, common practices involve obtaining feedback through compile-time instrumentation (e.g., Sanitizers). In managed languages, however, reliance is mostly placed on runtime instrumentation of bytecode [76] or JIT compilers [77]. This discrepancy makes it difficult to unify feedback granularity and observable event types across different runtimes. Furthermore, the criteria for failure determination are not equivalent (e.g., memory corruption vs. uncaught exceptions). This disparity makes it extremely difficult to build a unified mechanism for error triage, deduplication, and automatic repair that adapts to different language backends simultaneously.

To address this challenge, we argue that portable driver generation should be treated as an explicit system-level objective rather than a byproduct of per-language tooling. This objective can be pursued along two directions. The first is to introduce a language-agnostic intermediate representation for fuzz drivers, which captures API call sequences, parameter dependencies, and environment setup steps independently of any concrete syntax. The second is to adopt a modular backend architecture in which language- and toolchain-specific components are encapsulated behind well-defined interfaces, so that adding support for a new ecosystem amounts to implementing a thin adaptation layer rather than redesigning the generation pipeline.

Measuring progress here demands metrics that go beyond coverage numbers. A concrete evaluation should quantify adaptation overhead (e.g., the engineering effort required to support a new language backend), cross-runtime reachability consistency, and crash reproducibility across execution environments. These dimensions directly test whether a portable generation architecture genuinely reduces marginal costs and technical debt as the target ecosystem expands.

6. Conclusions

This paper reviews automated fuzz driver generation in library fuzzing through four technical trajectories organized around the primary data sources used to derive driver-generation constraints. It also outlines a bounded comparability-oriented evaluation perspective together with a disclosure checklist, while discussing broader reproducibility and deployment considerations.

Analysis indicates that no single trajectory resolves all constraints simultaneously: improvements in semantic richness, reachability, and repair capability often introduce higher engineering overhead or weaker comparability of reported evidence. Future work should therefore improve reachability-oriented driver evolution, dynamic closed-loop orchestration, and cross-ecosystem portability under more controllable costs.