VerilogLAVD: LLM-Aided Vulnerability Detection

• The paper introduces VerilogLAVD, a novel hybrid method combining LLM-aided rule generation with graph traversal to detect hardware vulnerabilities in Verilog code.
• It employs the VeriPG representation, integrating AST, CFG, and DDG components, and achieves an F1-score increase up to 0.57 compared to LLM-only approaches.
• The approach enhances detection accuracy and efficiency through rigorous rule validation and scalability that ties runtime to executed traversal primitives rather than file size.

Searching arXiv for the specified paper and closely related context. VerilogLAVD is an approach for early-stage hardware vulnerability detection in Verilog that combines a graph-based code representation with LLM-aided rule generation from Common Weakness Enumeration (CWE) descriptions. It is presented as the first LLM-aided graph traversal rule generation approach for Verilog vulnerability detection, with the stated objective of reducing reliance on specialized security expertise while improving consistency relative to LLM-only analysis. Its central components are the Verilog Property Graph (VeriPG), an LLM-driven workflow that converts CWE descriptions into traversal rules, a rule validation mechanism, and an executor that traverses VeriPG to identify candidate vulnerabilities (Long et al., 18 Aug 2025).

1. Motivation and problem setting

Timely detection of hardware vulnerabilities during the early design stage is described as critical for reducing remediation costs. The work situates itself at the Register Transfer Level (RTL), where existing early detection techniques are said often to require specialized security expertise, including manual rule writing and assertion-based verification, or to be unsuitable for early-stage analysis (Long et al., 18 Aug 2025).

Within this setting, LLMs are treated as promising but insufficient by themselves. The stated limitation is that LLMs struggle to capture the structure in Verilog code, which results in inconsistent detection results, poor performance, and excessive false positives. The proposed response is not to replace structural analysis with natural-language reasoning, but to couple LLMs to a graph-based intermediate representation and a constrained execution framework. This design suggests a division of labor in which LLMs are used for rule synthesis from textual vulnerability knowledge, while graph traversal over structured program representations performs the actual detection (Long et al., 18 Aug 2025).

The vulnerability scope in the evaluation spans 12 CWE types grouped into 5 vulnerability categories, including improper access control, resource operation, locking, side channels, and state machines. This categorization indicates that the method is intended for semantically diverse RTL security defects rather than a single narrow bug class (Long et al., 18 Aug 2025).

2. VeriPG: unified representation of Verilog code

VeriPG is the code representation introduced by VerilogLAVD. It is described as a unified representation of Verilog code that combines syntactic features extracted from the abstract syntax tree (AST) with semantic information derived from control flow and data dependency graphs. The representation is motivated by the observation that code property graphs have demonstrated effectiveness for vulnerability detection in software, but that Verilog requires a tailored approach because of its syntax and concurrency (Long et al., 18 Aug 2025).

The construction of VeriPG combines three core components. The AST captures structural and syntactic code features, including statements, expressions, and variable declarations. The control flow graph (CFG) models the flow of control between statements within procedural blocks, especially Always blocks and control constructs such as If and For. The data dependency graph (DDG) encodes dependencies among signals, registers, and wires, tracking assignments and usages through data-flow edges (Long et al., 18 Aug 2025).

A key integration step is common node extraction. Nodes that appear in AST, CFG, and DDG are used as unifying points for graph merging. The paper expresses this condition as

$$\exists v_{common} \in V_A,~ \exists v_C \in V_C,~ \exists v_D \in V_D,~ v_{common} \in v_C~\text{or}~v_{common} \in v_D$$

where $V_A$ denotes AST nodes, $V_C$ CFG nodes, and $V_D$ DDG nodes (Long et al., 18 Aug 2025).

The feature combination procedure uses the AST as the base structure. AST edges between common nodes are broken to create subtrees, after which CFG and DDG edges are overlaid among these subtrees according to procedural and dependency relationships. The resulting graph is characterized as multi-partite and property-rich, designed to support traversal-based vulnerability detection (Long et al., 18 Aug 2025).

The formal definition of a Verilog module in this framework is

$G = (V, E, A^V, A^E)$

where $V$ is the node set, $E$ is the edge set with $E_A$, $E_C$, and $E_D$ corresponding to AST, CFG, and DDG edges, $V_A$0 denotes node properties such as name, type, line number, and value, and $V_A$1 denotes edge properties such as type and condition (Long et al., 18 Aug 2025).

Traversal is defined through primitives over node and edge properties. The generic form is

$V_A$2

where $V_A$3 is the current node, $V_A$4 a candidate node, $V_A$5 the desired node type, and $V_A$6 the desired edge type. Two example primitives are given:

$V_A$7

and

$V_A$8

These definitions show that VeriPG is intended not merely as a storage format but as an execution substrate for compositional graph queries (Long et al., 18 Aug 2025).

3. LLM-aided rule generation from CWE descriptions

The rule-generation stage maps natural-language vulnerability descriptions to graph traversal logic. VerilogLAVD leverages LLMs to generate VeriPG-based detection rules from CWE descriptions, with the aim of converting textual security knowledge into executable graph patterns (Long et al., 18 Aug 2025).

The workflow begins with vulnerability condition extraction. CWE descriptions are mapped onto precise vulnerability conditions using a step-by-step Chain-of-Thought approach orchestrated by the LLM. According to the paper summary, this process distills both the symptoms and root causes of each CWE into logic predicates suited for graph traversal (Long et al., 18 Aug 2025). A plausible implication is that the method treats CWE text not as a retrieval artifact but as a specification from which operational criteria can be synthesized.

Prompt design supplies the LLM with three inputs: the CWE description, a list of supported VeriPG traversal primitives, and a schema for rule encoding. The model then generates traversal steps and rules gradually, referencing the available code structures and primitive definitions. The explicit restriction to supported primitives is significant because it constrains generation to a finite operational language rather than unconstrained prose reasoning (Long et al., 18 Aug 2025).

Rule validation is a distinct stage rather than an incidental post-processing step. The validation tool implements a finite state machine over VeriPG. Each primitive is validated for correct application, including correct input node type, parameter types, and allowable transitions in the graph. The interaction is iterative: when the LLM outputs an invalid primitive or parameter, the tool returns feedback and the LLM corrects its output in subsequent steps. The tracing of state transitions is intended to ensure that only legal traversal chains are preserved (Long et al., 18 Aug 2025).

Rule representations are stored as JSON objects. These combine functions, filters, and paths. Functions correspond to traversal primitives with configurable parameters; filters apply Boolean conditions using AND and OR over intermediate results; and paths define ordered sequences in which the output from one function feeds into the next. This rule structure places VerilogLAVD between natural-language vulnerability interpretation and deterministic graph execution (Long et al., 18 Aug 2025).

4. Execution model and detection workflow

The execution side of VerilogLAVD is organized around a rule executor that traverses VeriPG for potential vulnerabilities. The paper identifies three components: a primitive executor, a filter executor, and a path executor (Long et al., 18 Aug 2025).

The primitive executor is the core engine for applying traversal primitives according to the rule instructions. The filter executor applies logical filters and constraints on traversal results. The path executor manages the sequence of function applications so that the paths encoded in the rule are followed precisely. Together, these components interpret the JSON rule objects and produce candidate vulnerability findings through graph traversal (Long et al., 18 Aug 2025).

This architecture separates rule synthesis from rule execution. The LLM is used to generate rules from CWE descriptions, but execution is delegated to a rule interpreter operating on VeriPG. This suggests a hybrid system in which semantic ambiguity is handled during rule generation, while the final detection process is grounded in explicit graph operations. The paper’s emphasis on validation further indicates that robustness is pursued by restricting and checking the intermediate rule language rather than by relying on model confidence alone (Long et al., 18 Aug 2025).

The case study on CWE-1280, described as uninitialized access control condition, illustrates this operational logic. For that case, VerilogLAVD reportedly combines custom traversal primitives involving data dependency and control flow steps to uncover vulnerabilities that LLM-only approaches fail to detect (Long et al., 18 Aug 2025). Within the article’s framing, this example functions as evidence that the method benefits from representing control and data relations explicitly.

5. Dataset and empirical evaluation

The evaluation is conducted on a dataset built from real-world open-source Verilog repositories, notably Hack@21, and extended with synthetic mutations. The mutation strategies include variable renaming, procedural block insertion, and structural complication such as increasing statement separation and adding control constructs. The dataset contains 77 Verilog designs, 12 CWE types, 59 positive samples described as vulnerable, and 18 negative samples described as patched or non-vulnerable (Long et al., 18 Aug 2025).

The baselines are LLM-only, LLM+Knowledge, and VerilogLAVD. In the LLM-only condition, the model is given Verilog code and a brief CWE description. In the LLM+Knowledge condition, it receives code plus extended CWE details. The evaluated LLMs are OpenAI GPT-4o and DeepSeek-V3 (Long et al., 18 Aug 2025).

The reported metrics are precision, recall, and F1-score, with a Pass@5 evaluation protocol. Under Pass@5, each method is run five times and a design is reported as vulnerable if any run detects it; this is intended to account for LLM output randomness (Long et al., 18 Aug 2025).

Method variant	F1-score
DeepSeek-V3 only	0.24
DeepSeek-V3+Knowledge	0.34
DeepSeek-V3+VerilogLAVD	0.50
GPT-4o only	0.21
GPT-4o+Knowledge	0.25
GPT-4o+VerilogLAVD	0.57

Across 77 Verilog designs encompassing 12 CWE types, VerilogLAVD achieves an F1-score of 0.54 in the abstract’s aggregate presentation. Relative to the LLM-only and LLM with external knowledge baselines, it improves F1-score by 0.31 and 0.27, respectively. The detailed table values further show per-model gains: DeepSeek-V3 rises from 0.24 to 0.50, and GPT-4o rises from 0.21 to 0.57 when VerilogLAVD is added (Long et al., 18 Aug 2025).

The paper summary states that the largest gains are seen in precision and F1, with better recall in most categories. This directly addresses a common assumption that providing more textual vulnerability knowledge to an LLM is sufficient for reliable RTL vulnerability detection. In the reported evaluation, the LLM+Knowledge baselines improve over LLM-only, but remain below the graph-guided method (Long et al., 18 Aug 2025).

6. Validation effects, efficiency characteristics, and limitations

Ablation results isolate the effect of rule validation. Without rule validation, traversal primitive misuse rates are reported as high, exceeding 36%. With rule validation, misuse rates drop to 10.10%, and the illegal rule rate decreases to 3.49% (Long et al., 18 Aug 2025). In the context of VerilogLAVD, this indicates that structural correctness of generated traversal programs is a material determinant of downstream detection quality.

Efficiency is described in terms of traversal workload rather than source length alone. The runtime of the rule executor is said to be more closely linked to the number of executed primitives than to code length. Even on longer files, execution can be fast if unrelated code paths do not require extensive traversal, which the paper characterizes as good scalability (Long et al., 18 Aug 2025). This qualifies a possible misconception that graph-based vulnerability detection must scale primarily with file size; the reported behavior instead ties cost to the extent of relevant traversal.

The limitations are stated explicitly. The current approach does not incorporate functional module context, which may improve localization and detection for vulnerabilities concentrated within specific units. The rule language may be insufficient for some highly complex or implicit vulnerabilities, implying a limit on current rule expressiveness. The paper also notes that, although initial results are promising, very large-scale SoC designs may require further optimization or distributed rule execution (Long et al., 18 Aug 2025).

Planned improvements include integrating hierarchical or functional module context into VeriPG and detection, expanding the rule language for more sophisticated vulnerability patterns, and exploring parallel or distributed rule executor designs (Long et al., 18 Aug 2025). These directions suggest that the present system is best understood as a structured framework for RTL vulnerability detection whose core abstraction and execution model are already defined, but whose representational scope and deployment scale remain active areas for extension.