Correct Verdicts, Flawed Reasoning: Structured Auditing of LLM-based Vulnerability Reasoning
Analyze & explore related research in Conceptio
Connect this record directly into your research workflow or AI agent. Explore citations across open repositories, query full text, and export structured proof bundles.
Correct Verdicts, Flawed Reasoning: Structured Auditing of LLM-based Vulnerability Reasoning
arXiv:2610.06366v1 [cs.CR] 5 Oct 2026
BOYUE CAROLINE HU, Carnegie Mellon University, USA KAIVALYA AHIR, Carnegie Mellon University, USA RONGHAO NI, Carnegie Mellon University, USA LIMIN JIA, Carnegie Mellon University, USA Large Language Models (LLMs) are increasingly deployed for automated software vulnerability analysis. Binary classification alone is often insufficient; practitioners need explanations to triage reported bugs and engineer patches. Standard practice relies on Chain-of-Thought (CoT) prompting to elicit such explanations. However, because CoT represents reasoning as free-form natural language, models can obscure logical leaps, hallucinated execution steps, and internal inconsistencies behind plausible prose, leading to correct verdict, flawed reasoning, such as reaching the correct verdict via a non-existent execution path. Our manual audit reveals that approximately 60% of correct vulnerability verdicts are accompanied by these fabricated or unverifiable claims. Free-form explanations allow reasoning errors to evade LLM-as-a-judge evaluation. To better audit LLM reasoning, we present Vulnerability Explanation Reasoning Auditor (VERA), an automated framework for auditing whether the explanation adheres to the source code; and whether it contains logical contradiction. Rather than accepting free-form text, VERA first asks models to output a Structured Reasoning Record (SRR), encoding the information necessary for vulnerability reasoning into machine-readable fields, including tracked pointers, memory operations, and state transitions. A multi-stage judge then audits each SRR against eight well-defined reasoning failure modes. Most stages use deterministic syntactic checks, with LLM calls reserved only when semantic interpretation is required. Furthermore, the standardized schema of SRRs enables automated mutation testing to benchmark reasoning judges at scale without human annotation. Our empirical evaluation demonstrates that reasoning flaws occur in correct verdicts just as frequently as in incorrect ones, and VERA exposes 87% of reasoning errors that free-form LLM-as-judge systematically miss. VERA replaces blind trust in CoT prose with structured reasoning audits, filtering hallucinated vulnerability reports and pinpointing stage-specific failures. CCS Concepts: • Software and its engineering → Software testing and debugging; Software maintenance tools; • Computing methodologies → Machine learning; • Security and privacy → Software and application security. Additional Key Words and Phrases: vulnerability detection, LLM reasoning auditing, LLM-as-judge ACM Reference Format: Boyue Caroline Hu, Kaivalya Ahir, Ronghao Ni, and Limin Jia. 2027. Correct Verdicts, Flawed Reasoning: Structured Auditing of LLM-based Vulnerability Reasoning. 1, 1 (October 2027), 23 pages. https://doi.org/ XXXXXXX.XXXXXXX Authors’ Contact Information: Boyue Caroline Hu, boyuecah@andrew.cmu.edu, Carnegie Mellon University, Pittsburgh, Pennsilvanya, USA; Kaivalya Ahir, kahir@andrew.cmu.edu, Carnegie Mellon University, Pittsburgh, Pennsilvanya, USA; Ronghao Ni, ronghaon@andrew.cmu.edu, Carnegie Mellon University, Pittsburgh, Pennsilvanya, USA; Limin Jia, liminjia@ andrew.cmu.edu, Carnegie Mellon University, Pittsburgh, Pennsilvanya, USA.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. © 2027 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM XXXX-XXXX/2027/10-ART https://doi.org/XXXXXXX.XXXXXXX
, Vol. 1, No. 1, Article . Publication date: October 2027.
2
Boyue Caroline Hu, Kaivalya Ahir, Ronghao Ni, and Limin Jia
(a) Chain-of-Thought (CoT) detection and LLM-as-judge baseline. Example on the right shows the LLM fabricates a cause via a stale comment; free-form prose makes the error invisible to the LLM-as-judge.
(b) Overview of VERA. VERA asks the detection LLM to structure its reasoning into an SRR, then audits it with a multi-stage judge, producing per-stage auditing results. evict_entry(cache_t *cache, int key) ⊲ = variable state 1 typedef struct { 2 char * name ; int refs ; 3 } entry_t ; 4 5 void cache_remove ( cache_t * cache , int key ) { /*removes key from index only*/ 6 ... } %Note: not freeing e% 7 8 void evict_entry ( cache_t * cache , int key ) { 9 entry_t *e = cache_lookup ( cache , key ); 10 if (! e) return ; 11 cache_remove ( cache , key ); /* removes entry e %Note: stale comment% */ 12 if (--e -> refs == 0) { 13 free (e -> name ); A ⊲ e->name: Freed B ⊲ e: Freed 14 free (e); 15 } 16 audit_log (" evicted \% d: \% s" , key , e -> name ); C ⊲ UAF: e->name is Freed 17 }
alloc/assign free/delete Allocated Freed e.g., e
assigned L9
deref
freed L13–14 A B
UAF × deref L16 C
(d) State-based specification of CWE-416 Use-After-Free (UAF): accessing pointers in the Freed state.
(c) When e->refs reaches zero, A e->name and (e) Example of reasoning auditing with VERA. Structuring reasoning into an auditable SRR enables judges to detect B e are freed. Then audit_log dereferences missed memory operations and false assumptions. e->name in the Freed state, causing the UAF. Fig. 1. Overview of VERA with a motivating example of correct verdict, flawed reasoning.
1
Introduction
Large Language Models (LLMs) are increasingly being adopted for automated vulnerability detection in software security [14, 21, 44, 50, 64]. Trust in LLM-generated vulnerability assessments depends not only on the final verdict but also on the underlying reasoning, especially in security-critical settings [30, 37]. Explanations of where and why a vulnerability exists help developers and security analysts validate findings and make informed patching and auditing decisions. However, LLMs may provide hallucinated explanations and justifications [29]. A common LLM-based vulnerability analysis approach is to use unconstrained Chain-of-Thought (CoT) reasoning in natural language. While flexible, free-form CoT allows models to produce plausible-sounding but fundamentally hallucinated justifications [24, 32, 38, 47, 57], a phenomenon we refer to as “correct verdicts, flawed reasoning.” For example, the program in Fig. 1c has a Use-After-Free (UAF) vulnerability (CWE-416 [41]). A common way to explain the vulnerability is that when the reference count is zero (L12), the pointers , Vol. 1, No. 1, Article . Publication date: October 2027.
Correct Verdicts, Flawed Reasoning: Structured Auditing of LLM-based Vulnerability Reasoning
3
e->name and e are freed on lines L13, 14, then the dereferencing e->name in audit_log (L16) leads to UAF. When prompted to identify and explain the vulnerability in this program, as illustrated in Fig. 1a, LLM via CoT correctly identified UAF, but its reasoning falsely assumes cache_remove frees e (L11) then dereferencing e->refs (L12) is the UAF. This error violates basic code adherence as the reasoning was based on the stale comment (L11) rather than actual implementation. Though not shown in the example, reasoning could also contain logical contradictions, such as explicitly identifying a vulnerability step-by-step only to conclude with a “Safe” final verdict. Our manual review of free-form CoT reasoning generated by four state-of-the-art LLMs revealed that LLMs frequently provide explanations with hallucinated external knowledge (55-61% factually incorrect) or unverifiable code assumptions (19-34%) (more details in Sec. 2). Relying on flawed explanations in production carries significant risk: engineers acting on hallucinated logic may write broken patches, while high benchmark accuracy conceals critical model failure modes (e.g., missing the actual UAF in Fig. 1c). Addressing this requires a framework that checks whether underlying reasoning by the LLMs is both grounded in facts about the source code and are logically consistent. The primary challenge of auditing LLM vulnerability reasoning is that free-form CoT reasoning lacks explicit structure and intermediate checkable steps, e.g., where pointers are freed and dereferenced. Furthermore, unlike algorithmic or boolean problems where intermediate logical steps unfold sequentially, checkable reasoning steps for vulnerability analysis need to be explicitly formalized and structured. Hence, recent efforts have turned to LLM-as-judge approaches [26, 37, 71] (Step II of Fig. 1a); however, evaluating unstructured natural language with another neural model is still prone to hallucinations and yields no verifiable evidences. For instance, in Fig. 1a, the LLM-as-judge is likewise misled by the stale comment and misses the error. Human experts can detect such issues, but their review does not scale. Our core insight is that for vulnerability analysis, checkable intermediate reasoning steps naturally correspond to program state transitions and that a broad spectrum of vulnerability classes, from memory safety to resource lifecycle errors, can be specified as state sequences. For instance, finding a UAF can be described as a process of finding operations that transition a pointer to Allocated state and then to Freed, and look for a dereference operation of any Freed pointer. In Fig. 1c, this sequence is e->refs==0 (L12), then e->name and e are freed (L13, 14), and the dereferencing e->name in audit_log (L16) leads to UAF (Fig. 1d). By instructing the LLM to explicitly track and output these state changes, we transform natural language reasoning into a machine-readable schema that can be deterministically checked against the input source code. Building on this insight, we present VERA (Vulnerability Explanation Reasoning Auditor), a framework that constrains LLM explanations to structured, auditable reasoning traces and performs automatic audit. Fig. 1b illustrates the architecture of VERA. We focus on vulnerability reasoning by LLMs when given a slice of the project (e.g., key function definitions). This is widely favored in practice because it is computationally efficient, scales across massive codebases, and operates directly on source code without requiring a fully compilable build environment. Rather than relying on high-level CWE categories paired with free-form CoT prompts, we first specify vulnerabilities as sequences of state transitions. VERA then instructs the LLM to output a Structured Reasoning Record (SRR) that explicitly materializes checkable intermediate reasoning steps, including variable states, state-changing operations, and operational assumptions, into an inspectable format for auditing (Step I in Fig. 1b). In the example in Fig. 1e, the SRR explicitly records the intermediate assumption about cache_remove that it frees e, then the conclusion that e->refs is the site of the UAF that can later be detected during auditing. Next, VERA performs reasoning auditing by evaluating the SRR through a multi-stage judge to detect reasoning breakdowns across a comprehensive taxonomy of fundamental failure modes (Step II). We define reasoning auditing as evaluating code adherence and internal consistency. The , Vol. 1, No. 1, Article . Publication date: October 2027.
4
Boyue Caroline Hu, Kaivalya Ahir, Ronghao Ni, and Limin Jia
former refers to checking whether each claim in an LLM’s reasoning chain is syntactically and semantically supported by the provided source code slice [26] (e.g., whether variables named in the trace are actually declared). The later refers to verifying that intermediate trace steps remain logically coherent and strictly support the final verdict (e.g., ensuring the final vulnerable verdict does not contradict the trace). Note that neither check requires ground-truth reasoning annotations which do not exist in real-world applications. Existing vulnerability validation techniques are fundamentally unsuited for this task. Benchmark studies evaluate only final detection metrics, treating internal reasoning as a black box [9, 14, 20]. Traditional static tools [5, 49, 65] focus on rule-based detection rather than explanatory auditability, frequently flooding triage queues with high false-positive rates without explaining root causes. Dynamic validation methods (e.g., fuzzing [23, 48, 63] or sanitizer-based execution [43, 52]) and LLM-based vulnerability validation [26, 37, 71] have a fundamentally different goal from reasoning auditing. They confirm whether the detected bug exists or executes at runtime rather than whether the explanatory reasoning is sound. To remain broadly applicable across diverse programming languages and vulnerability classes (CWEs) without requiring language-specific static analyzers or heavy compilation toolchains, VERA’s judge relies primarily on deterministic AST parsing for syntactic checking, reserving targeted LLM calls strictly for higher-level semantic checks. By evaluating the SRR rather than unstructured text, VERA exposes both reasoning mistakes in the example: the omitted memory operations and the invalid assumption drawn from the stale comment. In summary, this paper makes the following contributions. 1) VERA: A Reasoning Audit Framework for Vulnerability Analysis. VERA takes an initial step toward systematic LLM reasoning validation in software security by providing an automated framework to audit code adherence and internal consistency in vulnerability reasoning. 2) Automated Mutation Testing for Reasoning Judges. Evaluating reasoning evaluators has traditionally required unscalable human inspection. By formalizing reasoning into explicit, machine-readable SRRs, VERA enables automated, ground-truth-free mutation testing of reasoning judges, providing a scalable framework to automatically benchmark judge precision and recall without human spot-checks. 3) Empirical Findings & Practical Impact: Our experiments using VERA reveal three critical insights. First, reasoning flaws occur in correct verdicts just as frequently as incorrect ones, models are right for the wrong reasons as often as they are simply wrong, making reasoning audit necessary. Second, false positives are systematic and structure-driven: models repeat identical reasoning mistakes on safe functions and their patched variants. Third, VERA’s per-stage decomposition reveals code-structural patterns that drive specific reasoning failures. By surfacing failures as explicit stage-level findings, VERA reduces manual effort to audit LLM reasoning chains for security analysts and provides LLM developers with actionable diagnostics for targeted fine-tuning and benchmark design. The rest of this paper is organized as follows. Sec. 2 motives VERA by demonstrating empirically that CoT reasoning is unreliable and unauditable. Sec. 3 introduces our state-based vulnerability specifications, reasoning failure taxonomy, and the Structured Reasoning Record (SRR) schema of VERA. Sec. 4 presents the multi-stage judge and mutation testing for judges. Sec. 5 reports evaluation results. Finally, we review related work in Sec. 6 and conclude in Sec. 7. 2
Motivation: Free-form CoT Obscures Reasoning Mistakes
In this section, we motivate VERA through the poor performance of LLM-generated CoT vulnerability explanations, highlight the challenges of auditing LLM reasoning at scale, and describe how VERA addresses these challenges via SRR. LLM analyses may rely on pattern matching, memorization, or hallucinated reasoning [24, 32, 38, 47, 57]. To evaluate reasoning validity, we manually audited free-form CoT explanations from four state-of-the-art LLMs on all 64 UAF vulnerable/patched function pairs in SVEN [28] (see , Vol. 1, No. 1, Article . Publication date: October 2027.
Correct Verdicts, Flawed Reasoning: Structured Auditing of LLM-based Vulnerability Reasoning
5
Table 1. Detection reliability and reasoning quality of free-form CoT (64 CWE-416 pairs, SVEN). Verdict Correctness Metrics Model GPT-5.5 [53] GPT-5.6-sol [53] Gemma-4-26b [56] Sonnet-5 [3]
Ext. Knowledge
Reasoning
a Both received a vulnerable verdict.
Binary Acc.
CWE recall
FP
Both V%a
Seenb / Wrong%
Vague%c
b Cites external knowledge (e.g., known
60% 59% 46% 59%
16% 13% 3% 13%
49% 38% 74% 46%
44% 33% 58% 42%
2% / — 0% / — 0% / — 44% / 61%
19% 28% 22% 34%
CVE/fix); Wrong% = fraction of incorrect claims (— = 𝑛<3). c Contains unverifiable claims about
callee behavior or project conventions.
supplementary material for details). Two human security experts audited each response across three dimensions: (1) verdict and CWE correctness, (2) factual accuracy of cited external knowledge (e.g., CVEs), and (3) the extent to which the reasoning was grounded in the code slice provided to the LLM as input. Our findings are three-fold, each illustrating a different way free-form CoT obscures reasoning mistakes that VERA is designed to surface. First, despite achieving moderate binary accuracy (46–60%), models rarely identify the correct vulnerability type (true CWE recall is only 3–16%) and label both vulnerable and patched versions as VULNERABLE in up to 80% of pairs. These numbers indicate widespread reasoning mistakes in the model’s explanation, yet free-form CoT poses challenges for auditing. Natural language imposes no structure on claims, allows contradictions to coexist with correct statements, and cannot be reliably parsed or checked. VERA addresses this by replacing free-form prose with an SRR that explicitly records every claimed memory operation, state transition, and property check. This state-transition-based explanation mirrors conceptually how human experts reason about and explain vulnerabilities, by tracing where an object is allocated, freed, and accessed again. With reasoning expressed in this structured form, the multi-stage judge can automatically locate and check each claim against the code slice. Second, examining the content of these errors more closely, we find that models frequently jump to conclusions by citing CVEs, bug reports, or domain conventions as justification rather than the code itself. Our manual review showed these claims are factually wrong 55–61% of the time. For example, when analyzing the SVEN function kvm_ioctl_create_device, Sonnet-5 flagged both the vulnerable and patched versions as VULNERABLE while citing CVE-2019-6974—a referencecounting defect, not a UAF. Free-form CoT permits authoritative assertions (e.g., “This matches CVE-X”) without mapping them to concrete code regions, which may trick both human reviewers and LLM judges. VERA detects this by validating each claim recorded in the SRR against the input code. A verdict citing CVE-2019-6974 must also record the corresponding pointer allocation, deallocation, and dereference in the code slice. A hallucinated citation will produce a trace with mistakes, and VERA flags the reasoning mistakes. Third, across all models, 19–34% of responses relied on ungrounded assertions about callee behaviors or domain conventions, which is not part of the input to LLMs. For instance, when analyzing disk_seqf_stop, Sonnet-5 declared the slice NOT VULNERABLE by asserting that “the stop callback is always called with a valid seqf—this is an accepted kernel convention.” In unstructured text, such premises are embedded into text, making it impossible to separate facts from speculative assumptions. VERA makes such assumptions explicit by encoding callee behavior and domain conventions as separate SRR fields, enabling judges to verify or reject them. 3
Structured Vulnerability Reasoning
In this section, we present the key components underlying VERA’s reasoning audit framework. We first model vulnerabilities as sequences of state transitions within program slices (Sec. 3.1). This representation closely mirrors conceptually how human security experts reason about and explain vulnerabilities, and forms the foundation of the Structured Reasoning Record (SRR) schema (Sec. 3.2). The SRR is designed to externalize implicit LLM reasoning into a collection of inspectable , Vol. 1, No. 1, Article . Publication date: October 2027.
6
Boyue Caroline Hu, Kaivalya Ahir, Ronghao Ni, and Limin Jia
facts. Finally, we introduce a failure taxonomy comprising eight fundamental reasoning error types, each corresponding to errors that may arise within SRR blocks (Sec. 3.3). 3.1
State-based Vulnerability Definition
Following prior works that model program behavior as state transition systems and software vulnerabilities as sequences of state transitions that reach a bad state [6, 10, 19, 31, 51, 54], we specify software vulnerabilities using state-based definitions. For example, a use-after-free (UAF) vulnerability is characterized by a sequence of allocation, release, and access operations on a resource, where each operation transitions the resource to a new state. The vulnerability manifests when the resource is dereferenced after it has entered the FREED state [10]. The informal definitions for CWEs of concern are shown below. State-based Specification of C/C++ Memory Vulnerabilities A memory resource 𝑀 exists in a state 𝑆 ∈ {NULL, ALLOC, FREED}. A pointer 𝑝 is a handle to 𝑀 and has a lexical scope. 𝑀 is reachable iff some in-scope pointer holds its address. Operations and State Transitions: • Initial State: the default state for 𝑀 is NULL. • Allocation (malloc, calloc, realloc, or a project-specific allocator): creates 𝑀 and sets State(𝑀) = ALLOC. • Deallocation (free, kfree, or a project-specific release helper): if 𝑝 points to 𝑀, sets State(𝑀) = FREED. free(NULL) is a defined no-op. Aliasing: for any pointer 𝑥 s.t. 𝑥 points to 𝑀, State(𝑥) ≡ State(𝑀). Vulnerability (violation conditions): • CWE-416 (Use-After-Free): Access(𝑥) — a dereference, read, write, or pass — when State(𝑥) = FREED. • CWE-415 (Double Free): free(𝑥) when State(𝑥) = FREED. • CWE-401 (Memory Leak): 𝑀 becomes unreachable while State(𝑀) = ALLOC.
This specification captures heap-memory lifecycle transitions. A heap resource 𝑀 is accessed through one or more pointer handles 𝑝, where reachability depends on the existence of a handle in scope. State changes are induced by operations (e.g., alloc and free). The aliasing rule ensures that any alternate pointer 𝑥 referencing 𝑀 inherits its state [22]. Use-after-free accesses a resource in the FREED state. Double free attempts to release it a resource in the FREED state. A memory leak occurs when the resource becomes unreachable while the resource remains in ALLOC state. This state-transition formulation generalizes naturally to stateful resource abstractions following open–use–close or state-gated patterns, such as network sockets, database connections, or session authentication states. Other natural extensions include, pointer validity, general resource releases, file descriptors, and object initialization (see definitions in supplementary material). Extending the framework to additional CWEs requires specifying their resource states, state-relevant operations, and violation conditions, alongside updating the reasoning schema and auditor rules. 3.2
Structured Reasoning Records
Standard free-text reasoning hides reasoning errors within fluent prose [24, 32, 38, 47, 57], rendering automated verification impossible. Based on state-transition-based vulnerability specifications, VERA requires the target detection model to structure its analysis into four linked blocks (Step I of Fig. 1b): scope and alias sets (Block 1), state traces along execution paths (Block 2), property evaluations (Block 3), and the final verdict (Block 4). Crucially, each block records the model’s claims. We demonstrate with the example in Fig. 1, the SRR is shown in Fig. 2. , Vol. 1, No. 1, Article . Publication date: October 2027.
Correct Verdicts, Flawed Reasoning: Structured Auditing of LLM-based Vulnerability Reasoning Block 1 (Scope)
Block 2 (Trace state changes)
Block 3 (CWE property audit)
pointers: e (ALLOC) memory_ops: type ptr op
paths: P0 (always); P1 (e == NULL); P2 (e != NULL); P3 (e->refs ==0); P4 (e->refs !=0) trace: path operation state ch.
IDENTIFIED CWE-416 remaining assessments omitted
alloc e cache_lookup free e cache_remove deref e e->refs Missing frees on L13-14, deref on L16
P0 alloc (cache_lookup) e: ALLOC free (cache_remove) e: FREED P2 deref (e->refs) e: FREED P3, P4 Not executed, UAF
7
Block 4 (Conclusion) verdict = VULNERABLE violation_condition: CWE-416 justification omitted
Fig. 2. Structured Reasoning Record (SRR) for the code snippet in Fig. 1c. The four blocks organize the detection model’s reasoning, including ungrounded assumptions and incorrect state transitions, into named, typed fields that VERA audits against the failure taxonomy. Red indicates errors detected by VERA.
Block 1 (Scope): Captures declared entities, including relevant variables, assumed initial states, observed operations, and alias equivalence sets. In our running example (Fig. 2), the model identifies pointer e with initial state ALLOC and lists operations cache_lookup, cache_remove, and e->refs, missing key free operations. This block can be viewed as the definitions of variables and operations in the explanation. Block 2 (Trace of State Changes): Records the model’s path-sensitive reasoning as an explicit sequence: which operations occur, along which execution paths, in what order, and with what state transitions. In Fig. 2, the model asserts that 𝑃0 executes unconditionally and branches at if (!e) into 𝑃1 and 𝑃 2 , then logs the resulting state changes. Because the model incorrectly assumes cache_remove releases e, it records an incorrect transition from ALLOC to FREED on 𝑃1 — a reasoning mistake now expressed as an explicit field that can be inspected and checked. Block 3 (CWE Property Audit): Records explicit per-CWE safety claims. In Fig. 2, it asserts that CWE-416 (Use-After-Free) is IDENTIFIED as e was dereferenced in the Freed state, making the basis of its judgment inspectable. Block 4 (Conclusion): Records the final classification (VULNERABLE or SAFE) alongside the cited violation_condition. By separating the conclusion from the reasoning in Blocks 1-3, VERA can check whether the verdict is coherent with the model’s own intermediate claims — a consistency that free-form CoT never exposes. By structuring intermediate reasoning into discrete, typed fields, the schema makes LLM vulnerability analyses auditable and surfaces errors as concrete, verifiable claims. 3.3
Reasoning Failure Taxonomy
To systematically identify LLM reasoning errors as presented in SRR, we derive a taxonomy of eight fundamental reasoning failure modes (𝐹 1 –𝐹 8 ), see Tbl. 2. These failure modes correspond to the state-based definition and the SRR schema: the tracked resources and active handles, the valid state transitions, the paths containing those transitions, and the violation conditions. Hence, our taxonomy is organized across four core reasoning dimensions: 1) Lexical and evidence integrity (𝐹 1, 𝐹 2 ), whether all relevant variables, pointers, and initial states are correctly scoped and that every claimed fact is anchored to concrete source operations rather than external assumptions or identifier naming conventions; 2) State correctness (𝐹 3, 𝐹 4, 𝐹 5 ), whether state transitions accurately match witnessed source operations, that alias relations are tracked and state mutations propagated across all co-referencing handles [22], and that intermediate state changes are completely recorded without omissions; 3) Path validity (𝐹 6, 𝐹 7 ), whether state transitions occur along valid, connected execution paths, requiring these paths to be syntactically connected from entry to the transition point, with branch conditions faithfully drawn from source rather than fabricated branches or statically dead code; and 4) Output coherence (𝐹 8 ), whether the final security verdict strictly follows from step-by-step property evaluations without logical self-contradictions [57]. , Vol. 1, No. 1, Article . Publication date: October 2027.
8
Boyue Caroline Hu, Kaivalya Ahir, Ronghao Ni, and Limin Jia
Table 2. Taxonomy of reasoning errors in state-based vulnerability analysis. Name
Explanation
Example
Lexical and evidence integrity Incorrect list of cwe-relevant variables and/or state-changing Model overlooked e as a pointer. 𝐹 1 Scope Error operations, and incorrect initial state of the variables. 𝐹 2 External Assumption Unsupported claims about caller/callee behavior, or project con- Model infers that cache_remove releases e based on its ventions treated as an established fact. name or comments. State correctness 𝐹 3 State Transition Error Transition applied to the wrong variable or the wrong opera- Model records free(e) but notes the transition to tion; the state change does not follow the operation; correct ALLOC operations but incorrectly sequenced relative to source Missing or hallucinated alias, or states not correctly propagated Model marks p1 as freed but leaves alias p2 as valid, 𝐹 4 Alias Error to its co-referencing aliases. then concludes p2 is safe to dereference. 𝐹 5 Trace Incompleteness Intermediate state changes are omitted between two trace steps, Model skips a free(buf) call between two steps trackor a path dependency is referenced without being established ing buf, presenting an incomplete view of its lifecycle. in the preceding trace. Path Validity 𝐹 6 Path Fabrication 𝐹 7 Dead Code Reliance
Output coherence 𝐹 8 Verdict Inconsistency
An execution path is asserted along a non-existent or unconnected branch, or incorrect activation conditions. A state transition is cited inside a statically unreachable block, e.g., a literal-false conditional, a preprocessor-disabled branch, or a provably unsatisfiable loop, treating dead code as live evidence.
Model claims the error path executes when ptr != NULL, but the branch guard in source is ptr == NULL Model uses a transition inside if (0) { free(p); } as evidence that p is released on the error path.
The step-by-step property evaluation and the final verdict are Model marks CWE-416 as violated in Block 3 but conin direct logical conflict. cludes NOT_VULNERABLE in Block 4, or marks all properties satisfied yet reports VULNERABLE.
Failure modes 𝐹 1, 𝐹 2, 𝐹 3, 𝐹 5, 𝐹 6 , and 𝐹 7 check for code adherence: every symbol, transition, path, and omission is faithfully grounded in the code slice. 𝐹 4 and 𝐹 8 check for internal consistency: alias propagation is coherent and the final verdict strictly aligns with property evaluations. All these failures can be detected by inspecting the SRR. Checking Block 1–2 against the source code identify lexical and evidence integrity failures (𝐹 1 –𝐹 2 ) and alias identification (𝐹 4 ); state correctness (𝐹 3 –𝐹 5 ) and path validity (𝐹 6 –𝐹 7 ) can be detected through Block 2; and verdict coherence (𝐹 8 ) is checked by comparing the verdict against the reasoning trace in Blocks 2–4. 4
Auditing LLM Vulnerability Reasoning
After the detection model outputs an SRR, VERA evaluates it using the multi-stage judge shown in Step II of Fig. 1b. The judge performs a claim validation: it checks whether the model’s explicit reasoning claims are grounded in the input code and internally coherent. The multi-stage judge contains eight stages (S1–S8), each targeting one failure mode (𝐹 1 –𝐹 8 from Tbl. 2). The stages follow a logical dependency chain: S1–S2 establish scope; S3–S4 validate path structure against the declared scope; S5–S6 check state transitions against the established scope and paths; S7 verifies alias propagation across the full trace; and S8 checks verdict coherence against all prior findings. S1 (deterministic): Checking for Scope Error (𝐹 1 ). Stage S1 checks Block 1 against the source code AST to verify the completeness and accuracy of the declared scope. Using Tree-Sitter, VERA extracts two ground-truth sets: cwe-relevant variables (i.e., memory-related variables such as pointers and fields for memory CWEs, and resource-related variables such as file descriptor for resource CWEs) and state-relevant operations (e.g., allocations, deallocations, dereferences for memory CWEs, acquire and release for resource CWEs). First, we check for scope hallucination and completeness, every variable and operation claimed in Block 1 exist in the input code slice, and all variables and operations in the code slices must exist in the declared scope in Block 1. Operations hidden inside missing callee context are flagged with a MISSING_CONTEXT warning. In Block 1 of Fig. 2, S1 would flags the missing deallocation operations on L13–14 and the missing dereference on , Vol. 1, No. 1, Article . Publication date: October 2027.
Correct Verdicts, Flawed Reasoning: Structured Auditing of LLM-based Vulnerability Reasoning
9
L16 as scope incompleteness errors. Additionally, initial state declarations in Block 1 must comply with C memory initialization rules: claiming ALLOCATED or FREED for a local variable before any corresponding operation appears in the slice is flagged as a scope error. Function parameters are an exception: when caller context is absent from the slice, their initial states cannot be checked hence not flagged as a scope error but a MISSING_CONTEXT warning. S2 (LLM): Check for Assumptions (𝐹 2 ). Stage S2 takes Block 1 and Block 2 together with the input code slice and uses targeted LLM calls to check whether any claims rely on hidden or external assumptions ungrounded in the code. For each claim, a targeted LLM call evaluates whether the provided justification is backed strictly by evidence explicitly present in the reasoning record and source code slice. In Fig. 2, S2 will flag the claim that cache_remove releases e as an ungrounded external assumption since no deallocation operation on e exist in the code slice. This step deploys LLM because detecting implicit natural-language assumptions in justifications is an irreducibly semantic task that cannot be resolved via deterministic parsing. S3 (deterministic): Check for Path Identification (𝐹 6 ). Stage S3 checks Block 2’s trace against Block 2’s declared paths to verify that every referenced Path ID is explicitly declared. State transitions are only valid along realizable execution paths. Referencing an undeclared Path ID indicates a structural inconsistency and is flagged as an 𝐹 6 path fabrication. S4 (deterministic): Check for Dead Code Reliance (𝐹 7 ). Stage S4 checks Block 2’s trace against the source AST to detect whether any claimed state transitions are grounded in syntactically unexecutable code. S4 targets syntactically detectable dead code (e.g., if (0), while (false)) — the subset reliably identifiable with static analysis on a code slice alone. More accurate dead-code detection would require CFG construction and is left for future work. S5 (deterministic): Check for Trace Coverage (𝐹 5 ). Stage S5 cross-checks Block 2’s execution trace against the declared operations in Block 1 to enforce internal consistency. While S1 grounds Block 1 against the source code, S5 ensures the model does not cherry-pick supporting operations in its trace while silently omitting contradicting ones. To avoid false positives, VERA restricts this check to variables actively tracked in the trace: S5 flags a gap only when a model traces a variable but omits a confirmed operation on that same variable. For instance, if the model traces pointer p through allocation and dereference but skips an intermediate free(p) call, S5 flags the omission—as that missing operation determines whether the pattern constitutes a Use-After-Free. As illustrated in Fig. 2, S5 does not re-flag ungrounded operations already caught by S1, focusing strictly on trace-completeness gaps. S6 (deterministic): Check for State Transition (𝐹 3 ). Stage S6 checks every state transition in Block 2 against the source code and CWE state-based definition to verify correctness and ordering. For every state transition in Block 2, Stage S6 deterministically checks whether the state update complies with the transitions defined in the state-based definitions, e.g., transitioning to FREED on a free operation; and whether the ordering of transitions is consistent with the input code slice. Additionally, for resource leaks (CWE-401 and CWE-772), an end-of-trace check verifies whether allocated variables remain in an unreleased state at the end of the function. In Fig. 2, S6 flags the ALLOC to FREED transition attributed to cache_remove, since no deallocation semantics are established for that call. S7 (LLM): Check for Alias (𝐹 4 ). Stage S7 takes Block 1 and Block 2 together with the source slice and uses a targeted LLM call to evaluate whether alias relationships are correctly identified and state mutations propagated to all coreferencing aliases. For example, if p is freed and q = p, then both p and q should be in the FREED state. Because aliasing can arise through patterns that require whole-program points-to analysis to resolve precisely, including pointer arithmetic, struct field , Vol. 1, No. 1, Article . Publication date: October 2027.
10
Boyue Caroline Hu, Kaivalya Ahir, Ronghao Ni, and Limin Jia
access, type punning, or values returned from opaque callees, S7 deploys a targeted LLM call rather than deterministic AST matching. S8 (deterministic+LLM): Check for Verdict Consistency (𝐹 8 ). Stage S8 checks Blocks 2–4 to validate coherence between the reasoning trace, the CWE claims, and the final verdict. First, we check whether each claim is backed by the correct state transitions (e.g., CWE-416 requiring a dereference step following a FREED state). Safe functions contain no violation claims; for these, trace correctness is checked in prior stages S3 to S6. Second, we confirm the natural-language rationale in Block 3 for final verdict aligns with the state transition trace in Block 2, via a targeted LLM call. Third, we check deterministically that Block 4’s binary verdict is logically consistent with Block 3’s CWE violation claims, i.e., vulnerable if any CWE identified, safe otherwise. Final Judge Outcome. Upon executing all eight stages, VERA classifies the reasoning record into one of four final outcomes. (1) NO_ERROR: All stages pass without hard failures, indicating the reasoning chain is complete, internally consistent, and grounded in the input code slice. (2) MINOR_ERRORS: At least one stage triggers a warning without hard failures (e.g., unverifiable callee context or unconfirmed aliases). The core reasoning chain remains valid, but requires targeted review of the claims that triggered the warning. (3) MAJOR_ERRORS: At least one stage triggers a hard failure (𝐹 1 –𝐹 8 ), such as a claimed dereference absent from the code slice (𝐹 3 ), an inverted allocation–free sequence (𝐹 4 ), or a verdict inconsistent with property checks (𝐹 7 ). VERA reports the specific stage and offending claim involved. Human security analysts can use these localized diagnostics to quickly audit suspicious code regions without reading full traces, while downstream LLMs can ingest these targeted error reports to drive self-correction loops or filter unreliable verdicts. Crucially, a correct binary verdict and MAJOR_ERRORS can co-occur, exposing instances where a model reached the right answer through fabricated reasoning. (4) INCOMPLETE_RECORD: The model failed to generate a parseable reasoning record, excluded from reasoning-quality evaluation and flagged for re-query. Evaluating the Judge via Mutation Testing. Assessing the reliability of reasoning judges requires ground-truth reasoning errors [71], which is hard to obtain. Human review of individual reasoning chains is expensive and does not scale. One approach to acquire ground-truth data at scale in software testing without human annotation is mutation testing, which generates mutants with errors injected [13, 15]. While this approach does not transfer directly to natural language reasoning, VERA’s SRR can be programmatically injected with precise, category-controlled faults. For example, deleting a state transition (𝐹 3 ), severing an alias link (𝐹 4 ), or fabricating an execution path (𝐹 6 ) can produce exact ground-truth errors. VERA thus supports automated mutation-based evaluation of judges across the full failure taxonomy (𝐹 1 –𝐹 8 ), enabling rigorous, scalable stress testing of reasoning judges operating on SRRs. Scope and Limitations. To enable language-agnostic, build-free deployment at scale, VERA’s judge operates directly on uncompiled code slices without requiring whole-program build environments. This design choice imposes two main operational boundaries. First, implicit operations introduced through type casts, struct field accesses, or opaque callees require type-system reasoning beyond AST-level pattern matching. Consequently, the completeness check in S1 is scoped to statically verifiable operations — explicit calls to known C/C++ memory functions (e.g., malloc, free, realloc); implicit operations are conservatively treated as warnings rather than hard failures. This is a deliberate trade-off that preserves zero false positives on structural checks at the cost of moderate recall in Stages S1 and S5. Second, checks that fundamentally require whole-program compilation, such as precise dead-code detection, alias resolution beyond direct pointer assignment, and formal path reachability, are currently outside VERA’s current scope. These are fundamental
, Vol. 1, No. 1, Article . Publication date: October 2027.
Correct Verdicts, Flawed Reasoning: Structured Auditing of LLM-based Vulnerability Reasoning
11
boundaries of intra-procedural auditing; integration with whole-program control-flow and points-to solvers is a natural direction for future work. Together, the eight-stage pipeline and mutation testing form a self-contained auditing framework: the judge measures reasoning quality independently of verdict correctness, and mutation testing evaluates the judge itself without requiring ground truth. 5
Evaluation
We evaluate VERA and answer the following questions. To establish that our error taxonomy is empirically grounded, we check that the failure categories reflect errors that occur in real LLM reasoning and answer: (RQ1) Do the failure categories in our taxonomy reflect real LLM reasoning failures? Next, with the taxonomy established, we evaluate the effectiveness of VERA’s judge in detecting these errors. Since no ground-truth labels exist for reasoning errors, we use mutation testing to inject known errors into valid reasoning records, enabling precise, controlled evaluation of judge effectiveness. We answer (RQ2) How does VERA’s multi-stage hybrid judge compare to a stage-structured LLM-as-a-judge in detecting reasoning errors? Finally, having established that VERA reliably detects reasoning errors, we then apply it at scale to real LLM reasoning traces to identify systematic reasoning failures, including “correct verdict, flawed reasoning”. We compare against free-form CoT baselines and answer: (RQ3) What systematic reasoning failures does VERA expose that binary accuracy metrics and free-form CoT judges fail to detect?" 5.1
Experimental Setup
Datasets. We evaluate VERA across diverse real-world vulnerability benchmarks SVEN [28] and Primevul [14] containing paired vulnerable and fixed function versions across five CWE categories in C/C++: CWE-416 Use-After-Free (184 pairs: 64 SVEN, 100 PrimeVul, 20 newly collected), CWE476 NULL Pointer Dereference (277 pairs: 77 SVEN, 100 PrimeVul, 100 newly collected), CWE-401 Memory Leak (200 pairs: 100 PrimeVul, 100 newly collected), CWE-415 Double Free (110 pairs: 65 PrimeVul, 45 newly collected), and CWE-772 Unreleased Resource (80 pairs: 76 PrimeVul, 4 newly collected). We include paired datasets to evaluate whether stage-level reasoning failures persist across a vulnerable function and its patched counterpart, motivated by our observation in Sec. 2, exposing whether model errors are driven by code structure rather than vulnerability presence. Models. Our experimental pipeline involves two roles for LLMs: detection models that generate vulnerability reasoning and judge models that evaluate reasoning correctness. For vulnerability detection, unlike in Sec. 2, we used SotA models to establish that the problem exists even with the most frontier models, here we evaluates across a broader, varied set of open and closed-source models to assess generalizability. We included results from six state-of-the-art LLMs: sonnet-5 [3], gemma4-26b [56], llama-4-maverick [2], nemotron-3-nano [45], glm-5.3-flash [25], qwen-3.8-27b [66], spanning open-source and proprietary models with different sizes1 . For reasoning evaluation, we employ three frontier and cost-efficient judge models from different providers than detection models: GPT-4.1 (OpenAI) [46], Mistral-Large-2512 (Mistral AI) [40], and DeepSeek-V3 (DeepSeek) [12]. Evaluation Configurations. Because no prior vulnerability reasoning auditing system directly audits intermediate reasoning without relying solely on an LLM-as-judge, we establish four evaluation configurations to systematically isolate the contributions of two core design choices: reasoning format (free-Form CoT [62] vs. structured SRR) and audit architecture (holistic LLM-as-judge [68] vs. stage-structured LLM vs. VERA’s multi-stage hybrid judge). 1) Free-form baseline B1: Free-Form CoT + Holistic LLM Judge. The detection model is prompted for open-ended reasoning. A holistic 1 Due to page limit, we present a subset of the result in the paper, the rest can be found in supplementary
, Vol. 1, No. 1, Article . Publication date: October 2027.
12
Boyue Caroline Hu, Kaivalya Ahir, Ronghao Ni, and Limin Jia
Table 3. Mapping between reasoning failure types and each mutation operator. Reasoning Failure
Mutation Operators
𝐹 1 scope error
𝑀1𝑎 : add a nonexistent variable or remove a random variable; 𝑀1𝑏 : add a nonexistent operation or remove a random operation; 𝑀1𝑐 : introduce incorrect initial state 𝑀2 : inject ungrounded external assumption into reasoning prose 𝑀3 : invert state-transition ordering or, insert spurious free step on leaked variable (included for CWE-401) 𝑀4 : add or erase the trace steps identifying aliases 𝑀5𝑎 : make trace step references undeclared path ID; 𝑀5𝑏 : add or drop one random trace step 𝑀6𝑎 : intentionally make path-activation condition vague; 𝑀6𝑏 : make trace step reference undeclared path ID; 𝑀6𝑐 : make path activation reference undeclared path ID 𝑀7 : wrap trace evidence in syntactically dead block 𝑀8𝑎 : flip verdict; 𝑀8𝑏 : flip CWE status and verdict
𝐹 2 ungrounded assumptions 𝐹 3 incorrect state transitions 𝐹 4 incorrect aliases 𝐹 5 incomplete trace 𝐹 6 fabricated path 𝐹 7 unreachable code 𝐹 8 inconsistent verdict
LLM-as-a-judge inspects the full narrative without stage decomposition. 2) Free-form baseline B2: Free-Form CoT + stage-structured LLM Judge. Same free-form detection output as B1, but the judge is prompted to evaluate reasoning explicitly with stages corresponding to the eight taxonomy categories. 3) LLM-as-judge baseline B3: SRR + stage-structured LLM Judge. The detection model materializes its reasoning into VERA’s SRR, then audited purely via an LLM judge using the same stage-structured prompts as B2. 4) VERA: SRR + Multi-Stage Hybrid Judge. The detection model outputs an SRR schema, which is then audited by VERA’s multi-stage hybrid pipeline. We show the benefit of structured reasoning by comparing B1/B2 vs. VERA (RQ3), and show the effectiveness of our multi-stage judge by comparing B3 vs. VERA (RQ2). Mutation-based Judge Evaluation. We designed 13 mutation operators mapped directly across our taxonomy stages (see Tbl. 3). Each operator targets the precise reasoning breakdown that a given stage is designed to catch. These operators are designed to simulate errors that naturally arise in LLM-generated structured reasoning records, e.g., variables that appear in the analysis but not in source, memory operations that are silently omitted, paths with vague or self-contradictory activation conditions, and alias relationships left untracked. We aim for completeness within each stage by covering both directions of error where applicable — for instance, hallucination (claiming absent elements) and omission (missing real ones) at S1, or missing trace steps and invalid path references at S5. Then, we measure detection performance with two metrics. Note that not all operators are applicable to all SRRs, e.g., no op identified 𝑀2 cannot be applied. Recall is the fraction of mutants targeting a specific stage that are correctly flagged as failures. False-positive rate (FP) is the fraction of mutants targeting a different stage that are incorrectly identified. 5.2
RQ1: Taxonomy Coverage
To answer RQ1, we evaluate whether our taxonomy (𝐹 1 –𝐹 8 ) accurately captures naturally occurring reasoning errors and whether our mutation operators (𝑀1 –𝑀8 ) provide complete coverage over real-world failure modes. We sampled 50 natural, un-injected SRRs per CWE per dataset (10 total with ≥ 50 functions: SVEN-416/476; PrimeVul-416/476/401/415/772; new-415/476/401) produced by each of the six detection models (total 50 × 10 × 6 = 3000 records sampled). To discover reasoning failures without biasing the models toward VERA, we prompted our three judge models with an open-ended error enumeration prompt, instructing them to describe flaws, hallucinations, or logical inconsistencies without any prior. Across all three judges, open-ended annotation yielded 324 distinct error labels with 41,365 total occurrences. As detailed in Tbl. 4, 313 of the raw labels mapped cleanly onto our taxonomy classes , Vol. 1, No. 1, Article . Publication date: October 2027.
Correct Verdicts, Flawed Reasoning: Structured Auditing of LLM-based Vulnerability Reasoning
13
Table 4. RQ1: error labels obtained with open-ended error enumeration mapped to our error taxonomy and mutation operators. Error label occurrence counts obtained with three judge models across 3000 reasoning records produced by six detection models. A record may receive multiple labels. The bottom section lists the 21 instances (< 0.05%) not assignable to any class; the eight categories together cover > 99.95% of all observed error instances. GPT
Mistral
DeepSeek
Failure category / Mutation operator Representative error labels
416
476
415
401
772 416
476
415
401
772 416
401
772
F1 Scope Error 𝑀1𝑎 Add/remove identifier 𝑀1𝑏 Add/remove op 𝑀1𝑐 Wrong initial state
phantom/missing_variable phantom_op,missing_memory_op incorrect_initial_state
565 479 85 1
807 678 125 4
517 454 62 1
558 433 123 2
328 365 254 311 74 54 0 0
508 454 54 0
295 241 54 0
338 272 66 0
182 1056 1465 1007 1074 149 675 949 639 625 33 369 481 353 433 0 12 35 15 16
580 324 250 6
F2 External Assumption 𝑀2 Ungrounded assumption
unsupported_claim
77 77
94 94
84 84
100 100
66 202 66 202
291 291
149 149
166 166
66 627 66 627
878 878
583 583
586 586
298 298
F3 State Hallucination 𝑀3 Break state-transition order
wrong_op_order
363 363
381 381
352 352
289 289
152 276 152 276
323 323
293 293
272 272
114 301 114 301
297 297
283 283
233 233
94 94
F4 Alias Incompleteness 𝑀4 Add/Remove alias traces
alias_confusion
39 39
45 45
29 29
20 20
24 24
21 21
22 22
31 31
10 315 10 315
260 260
207 207
206 206
103 103
F5 Trace Incompleteness 𝑀5 Add/Drop trace step for op
missing_trace_step
636 636
910 910
588 588
596 596
296 633 296 633
888 888
592 592
590 590
301 881 1260 301 881 1260
786 786
763 763
398 398
F6 Path Fabrication 𝑀6𝑎 Vague path-act. condition 𝑀6𝑏 Trace step ref. undeclared path 𝑀6𝑐 Path ref. undeclared path id
vague_path_cond path_id_mismatch phantom_path
430 421 9 0
704 695 9 0
369 364 5 0
351 340 11 0
170 611 168 611 2 0 0 0
866 865 1 0
567 566 1 0
565 565 0 0
288 800 1155 288 641 918 0 158 234 0 1 3
737 604 133 0
767 610 157 0
407 313 94 0
F7 Dead Code Reliance 𝑀7 Wrap trace evidence in dead code dead_code_executed
2 2
9 9
5 5
3 3
2 2
6 6
8 8
8 8
4 4
2 2
70 70
84 84
45 45
65 65
72 72
F8 Verdict Inconsistency 𝑀8𝑎 Flip verdict 𝑀8𝑎 Flip CWE violation and verdict
13 13 0
30 29 1
20 18 2
40 38 2
49 45 4
71 71 0
99 99 0
90 90 0
83 83 0
79 444 79 437 0 7
676 649 27
392 389 3
434 426 8
259 251 8
verdict_contradicts_audit incons. property_audit
Total mapped Unmapped labels (21 instances, < 0.05%) Format, not reasoning One-time instance-specific
8 8
476
415
2125 2980 1964 1957 1071 2188 3004 2016 2049 1042 4494 6075 4040 4128 2211 wrong_step_numbering wrong_op_type_mutex_unlock
0 0
0 0
0 2
0 0
0 0
0 0
0 0
0 0
0 0
0 0
1 0
7 1
1 3
1 3
1 1
(𝐹 1 –𝐹 8 ) and mutation operators (𝑀1 –𝑀8 ). The vast majority mapped via direct synonymy—for instance, labels describing missing entities (e.g., missing_memory_op) or phantom variables (e.g., phantom_variable) mapped to 𝐹 1 (Scope/Operations), while omitted_guard mapped to 𝐹 5 (Trace Incompleteness). While each 𝐹𝑖 defines a failure category, mutation operators instantiate the concrete mechanisms by which that failure arises, for example, 𝐹 1 (scope error) can manifest as a missing variable, a hallucinated variable, or a wrong pointer target, each should be covered by a distinct operator. All labels mapped to 𝐹 1 –𝐹 8 are fully covered by our 13 mutation operators without requiring additional mutation operators. While this does not imply an exhaustive enumeration of all possible code mutations, it demonstrates that 𝑀1 –𝑀8 comprehensively represent all different types of naturally occurring reasoning errors required to evaluate judge effectiveness. The remaining 21 instances (≤ 0.05% covering 11 distinct labels) fall into two categories. Out of these, 11 are output-format mistakes rather than reasoning errors (e.g., misnumbered trace steps). The other 10 are single-occurrence, function-specific labels (e.g., incorrect_mutex for one particular lock pattern) that do not recur across functions or CWEs, and 8/10 are produced by a single model DeepSeek. These are consistent with label noise introduced by open-ended enumeration prompts. Reasoning error classes require recurring, generalizable failure patterns; one-time observations about specific implementation details do not qualify. Across 3,000 records and three judge models, no recurring pattern emerged that our eight-class taxonomy does not cover. Additionally, judge models disagreed on the frequency of individual error types, Mistral flagged substantially more 𝐹 2 , 𝐹 4 , and 𝐹 8 instances than GPT-4.1 or DeepSeek, further motivating VERA’s deterministic stage checks over pure LLM-as-judge evaluation. Hence our results confirm that our failure taxonomy and mutation suite are both empirically grounded and comprehensive, answering RQ1. , Vol. 1, No. 1, Article . Publication date: October 2027.
14
Boyue Caroline Hu, Kaivalya Ahir, Ronghao Ni, and Limin Jia
Table 5. Per-stage mutation detection (recall / FP) across five CWE classes, data from different datasets aggregated. VERA vs. B3 (SRR + structured LLM judge). Judge models: GPT = GPT-4.1, DS = DeepSeek, Mis = Mistral. 𝑁 : number of mutants; -: no mutant generated. Bold: recall = 1.00 or FP = 0.00. Gray cells : LLM-dependent (all B3 cells; VERA S2, S7 which are primarily LLM). Stage
CWE-416 (𝑁 =711)
CWE-476 (𝑁 =1006)
CWE-415 (𝑁 =332)
CWE-401 (𝑁 =541)
CWE-772 (𝑁 =178)
GPT
GPT
GPT
GPT
GPT
DS
Mis
DS
Mis
DS
Mis
DS
Mis
DS
Mis
S1 Scope
VERA .53/.00 .56/.00 .68/.00 .61/.00 .68/.00 B3 .62/.13 .69/.30 .98/.01 .64/.04 .77/.19 1.00/.00 .53/.15 .73/.20 1.00/.00 .75/.11 .74/.24 1.00/.00 .63/.03 .79/.17 1.00/.02 S2 Evidence VERA .33/.06 .41/.11 .97/.07 .44/.09 .49/.14 1.00/.06 .47/.08 .44/.10 .95/.12 .25/.04 .42/.09 .98/.08 .20/.06 .55/.13 .90/.00 B3 .34/.05 .32/.11 .96/.09 .43/.12 .61/.15 1.00/.07 .47/.03 .47/.15 .95/.08 .25/.08 .45/.15 .96/.08 .25/.08 .50/.09 .90/.00 S3 Path ID VERA 1.00/.00 1.00/.00 1.00/.00 1.00/.00 1.00/.00 B3 .68/.00 .44/.14 1.00/.10 .75/.01 .64/.12 .99/.13 .72/.00 .52/.11 1.00/.17 .72/.03 .52/.16 1.00/.26 .75/.00 .42/.06 1.00/.09 S4 Reachability VERA .91/.00 .90/.00 .90/.00 .58/.00 .44/.00 B3 .35/.00 .22/.01 1.00/.22 .20/.00 .23/.05 1.00/.15 .33/.00 .55/.02 1.00/.22 .26/.00 .28/.01 1.00/.15 .28/.00 .39/.01 1.00/.16 S5 Trace Cov. VERA .59/.00 .64/.00 .71/.00 .62/.00 .66/.00 B3 .16/.02 .73/.35 1.00/.00 .26/.07 .79/.19 1.00/.00 .10/.03 .69/.29 1.00/.00 .29/.11 .63/.26 1.00/.00 .44/.08 .69/.30 .94/.01 S6 State Trans. VERA 1.00/.01 1.00/.02 1.00/.02 1.00/.02 1.00/.05 B3 .00/.09 .62/.26 1.00/.00 .20/.08 .90/.21 1.00/.00 .42/.16 .75/.32 1.00/.00 .45/.05 .91/.12 1.00/.00 .50/.07 .75/.38 1.00/.01 S7 Alias VERA .17/.03 .17/.20 .50/.03 .33/.06 .75/.16 1.00/.04 .25/.08 .50/.13 1.00/.06 .33/.06 .83/.25 1.00/.05 —/.06 —/.15 —/.01 B3 .17/.06 .17/.27 .50/.03 .25/.03 .50/.22 1.00/.02 .00/.09 .75/.25 1.00/.06 .33/.07 .67/.10 1.00/.05 —/.02 —/.26 —/.01 S8 Verdict VERA 1.00/.00 1.00/.00 1.00/.00 1.00/.02 1.00/.00 B3 1.00/.00 .75/.09 1.00/.19 .98/.00 .85/.10 .98/.19 1.00/.00 .94/.09 1.00/.19 .86/.00 .80/.09 .89/.18 .89/.00 .78/.04 1.00/.14
5.3
RQ2: Judge Effectiveness
To answer RQ2, we randomly sampled 20 SRRs per dataset per CWE, applied each mutation operator (prioritizing No_ERROR, falling back to MINOR_ERROR), and measured per-stage recall and false-positive (FP) rates across the resulting mutated records. When scoring, pre-existing errors in the unmutated base records were excluded, ensuring measured recall reflects detection of the injected fault. For each mutant, we checked whether the judge flagged the specific stage targeted by the operator. We compared VERA against B3 (SRR + structured LLM judge), its LLM-only counterpart, which audits SRRs across the same eight stages but uses an LLM for every stage. Tbl. 5 reports per-stage recall and off-target FP for both judges across three judge models, aggregating records of the same CWE across datasets; all SRRs are generated by Sonnet-5, which produces the most structurally complete records and all judges are evaluated on the identical set of mutants. Primarily deterministic stages (S1, S3–S6, S8). VERA matches or outperforms B3 (SRR + structured LLM judge) across all these stages while maintaining near-zero off-target FP. S3, S6, and S8 achieve perfect recall (1.00) with 0.00 FP across all CWEs. Across these stages, B3 with GPT-4.1 as judge achieves recall 0.10–0.75 with FP up to 0.16; B3 with DeepSeek achieves 0.22–0.91 in recall but at FP up to 0.38 on clean records. B3 with Mistral reaches near-perfect recall on most of these stages, but only because of overflagging incurring FP up to 0.26. The key pattern underlying VERA’s advantage is absence detection: the errors targeted by S5 (missing intermediate state changes) and S6 (omitted or misordered transitions) require noticing what is not in the trace rather than what is. Fluent surrounding prose masks these gaps for an LLM judge — VERA’s deterministic trace checks find them mechanically. S5 shows the largest gap overall: VERA 91.5% vs. B3 72.8%, with 22.8% of injected errors caught by VERA alone. S6 shows the same pattern (+16.7%). The one exception to VERA’s structural advantage is S1, where recall falls slightly short due to a deliberate precision-first trade-off (Sec. 4); even so, S1 matches B3 recall with lower FP on two of three judge models. Notably, S8 (verdict consistency) is the one stage where the gap nearly closes regardless of judge type — VERA 100%, B3 98.8% — because an explicit contradiction between the property block and the final verdict is detectable in any structured representation without absence reasoning. Beyond quantitative metrics, B3 (SRR + structured LLM) exhibits severe hallucination on clean records. With GPT-4.1, on the SMB2_read control record (Linux kernel, CWE-416 in SVEN), B3 issued a Fail , Vol. 1, No. 1, Article . Publication date: October 2027.
Correct Verdicts, Flawed Reasoning: Structured Auditing of LLM-based Vulnerability Reasoning
15
Table 6. RQ3 comparing VERA structured framework with free-form baselines. (a) SRR construction success rate per detection model. Model
Total Incomp. success%
Sonnet-5 Gemma GLM Llama Nemotron Qwen
1649 1654 1632 1652 1564 1646
46 6 6 37 398 25
(b) Failure rate flagged by VERA, B1 and B2 for the determinisitic stages. Stage
97.2% 99.6% 99.6% 97.8% 74.6% 98.5%
S1 Scope S3 Path ID S4 Reach. S5 Trace Cov. S6 State Trans. S8 Verdict
.48 .22 .00 .31 .39 .59
.49 .22 .00 .31 .38 .61
Mis GPT
4% 3%
4% 3%
B2 DS
Pair
Mis
59% 17%
4% 3%
S4 Reach. S5 Trace Cov. S6 State Trans. S8 Verdict
0% 26% 42% 65%
0% 0% 0% 0% 1% 0% 10% 10% 11% 76% 76% 97% 5% 5% 6% 13% 49% 66% 0% 0% 0% 0% 5% 2%
(i) Verdict Correctness (ii) Ground-truth Corr. Incorr. Vuln Safe Both Same Err .51 .23 .00 .31 .39 .64
B1 DS
S1 Scope S3 Path ID
(d) Stage-level error rates split by final verdict correctness and ground-truth label. Stage
GPT
vera
.51 .23 .00 .31 .39 .62
.44 .13 .00 .15 .23 .50
(c) Pairwise agreement between VERA, B1, and B2. Both N.E Both E. Disagree
GPT DS Mis GPT VERA DS vs. B2 Mis GPT B1 vs. B2 DS Mis
6% 7% 5% 0% 0% 0% 10% 1% 0%
VERA vs. B1
29% 64% 51% 11% 70% 66%
32% 20% 38% 78% 89% 91% 31% 21% 41%
61% 72% 55% 20% 9% 8% 58% 76% 57%
Deterministic stages only. N.E.: no error; E.: error
(e) Stage-level failure rate per detection model. Stage S1 Scope S3 Path ID S4 Reach. S5 Trace Cov. S6 State Trans. S8 Verdict
Sonnet-5 Gemma GLM Llama Nemotron Qwen .59 .18 .00 .22 .43 .66
.48 .34 .00 .33 .23 .50
.51 .19 .00 .27 .42 .69
.48 .26 .00 .26 .44 .54
.47 .21 .00 .11 .32 .51
.48 .13 .00 .16 .47 .67
on S3 with the finding: “Hallucinated State Transition: rsp and *buf step 12, 15.” No such transition exists in either the record or the source — B3 invented a violation on a sound reasoning chain. VERA correctly returned Pass. Primarily LLM-dependent stages (S2, S7). Neither VERA nor B3 (SRR + structured LLM) achieves reliable detection on S2 and S7, and performance differences between them are attributable to LLM stochasticity rather than systematic design advantages. S2 (assumptions) recall reaches 0.20–0.47: drawing a strict line between grounded and ungrounded claims is inherently ambiguous, and the gap between VERA and B3 here falls within stochastic variance. S7 (alias) exhibits the lowest recall overall, as alias detection requires comprehensive points-to analysis over the global pointer graph, which static analysis alone cannot perform on localized code slices. These results reflect the current limitations of LLM semantic reasoning on these two error classes. We retain S2 and S7 because the failure modes they target are prevalent and consequential; closing the recall gap on both remains an active direction for future work. Model variance and the precision–recall trade-off. VERA’s programmatic stages (S1, S3–S6, S8) are fully deterministic and identical across all three judge models. Variance appears only on S2 and S7. Mistral reaches near-perfect recall on several stages but with FP up to 0.26, indicating instability; DeepSeek is more conservative but has higher FP than GPT-4.1. This exposes another fundamental limitation of a purely LLM-based judge: flagging more aggressively catches more injected errors but also raises more false positives, while being conservative reduces false positives at the cost of missing real errors. VERA’s programmatic stages achieve higher recall than the conservative GPT judge, and lower FP than the aggressive Mistral judge, avoiding both extremes. In summary, across five CWE classes and three state-of-the-art judge models, VERA matches or outperforms the structured LLM judge (B3) on every programmatic stage while keeping off-target FP at near zero on three of these stages. Thus, we answer RQ2. , Vol. 1, No. 1, Article . Publication date: October 2027.
16
5.4
Boyue Caroline Hu, Kaivalya Ahir, Ronghao Ni, and Limin Jia
RQ3: LLM Reasoning Quality Information Revealed
To answer RQ3, we compare VERA’s performance on its deterministic stages against free-form baselines B1 (CoT + Holistic LLM) and B2 (CoT + Structured LLM). We focus on stages that reached decent performance in RQ2, excluding S2 and S7. First, we evaluate whether detection models can reliably output SRRs. Tbl. 6a shows that five of the six detection models generate well-formed SRRs in ≥ 97.2% of cases; only Nemotron fails to produce a parseable record on 25.4% of attempts. For Nemotron, the incomplete records are excluded from all downstream stage-level analysis. Free-form baselines vs. VERA. Overall, B1 (CoT + Holistic LLM) yields an 86.8% false-negative rate on records where VERA identifies deterministic-stage errors, underscoring the inadequacy of free-form LLM evaluation. As shown in Tbl. 6b, B1 (CoT + Holistic LLM) flags substantially fewer errors than VERA across every stage presented, whereas B2 (CoT + Structured LLM) over-flags in almost all stages while missing errors in S8. Discrepancies are largest on stages requiring precise cross-section consistency (S3, S5, S6, S8). A representative example is disk_seqf_stop (SVEN CWE-416, Sonnet-5): the SRR explicitly assigns iter as NULL then dereferences it in the next step, yet marks CWE-476 as Satisfied. VERA’s S8 detects this contradiction mechanically; B1 (CoT + Holistic LLM) rates the same SRR error-free, stating “The analysis correctly describes the bug, tracing all relevant pointer/state paths.” A holistic LLM judge infers coherence from parts that sound correct rather than verifying mutual consistency — which is precisely what structured stage checks provide. LLM-as-a-judge is inherently prompt-sensitive and therefore unreliable [72]. As shown in Tbl. 6c, B1 (CoT + Holistic LLM) and B2 (CoT + Structured LLM) disagree significantly on the same CoT inputs, confirming that free-form judging lacks the consistency needed for reliable reasoning auditing. Finding 1: Correct verdicts are no guarantee of correct reasoning. Tbl. 6d partitions audited SRRs by verdict correctness. Intuitively, correct verdicts should show fewer reasoning flaws — but error rates across all six stages remain virtually identical between correct and incorrect verdicts (|𝛿 | ≤ 0.05 at every stage). Models are frequently right for the wrong reasons: even when they output correct binary verdicts, their reasoning contains explicit internal contradictions invisible to surface-level accuracy metrics. A similar decoupling holds across the ground-truth split, with error rates uniform across safe and vulnerable code. Finding 2: LLM over-flag by pattern-matching, not by reasoning. Among 1,468 functions evaluated by all six models, 103 safe functions were wrongly labelled as vulnerable by every model, compared to only 37 real vulnerabilities missed by all models. VERA’s structured audit flagged a reasoning error in 98% of these over-flagged safe functions, with S8 as the dominant failure (82%). This reflects a reliance on surface pattern matching observed in Sec. 2, models flag safe functions for containing vulnerable-like structural cues, then hallucinate ungrounded traces to justify their premature Vulnerable verdict. Examining paired data confirms this. Across 777 paired (vulnerable, patched) functions, both versions trigger the same stage failure in 51.1% of pairs at S1, 27.7% at S6, and 56.9% at S8 — and 32.3% of pairs share the exact errors across all stages. The model makes the same structural reasoning mistakes regardless of whether the vulnerability is present, confirming that over-prediction is driven by code pattern rather than vulnerability-specific reasoning. Finding 3: Incomplete slices cause models to hallucinate lifecycle evidence. While overflagging and miss rates are comparable for most CWEs, CWE-772 (Missing Release) is a major outlier: models correctly flag 75% of actual leaks (highest recall across CWEs), yet falsely flag 73% of safe functions. This stems from a mismatch between CWE-772 violation and slice visibility. Unlike local properties like CWE-476, confirming a CWE-772 leak requires verifying that the resource reaches a release state on every exit path — including paths that continue beyond the slice boundary. When an explicit release is absent from the local slice, models tend to default to predicting a leak.
, Vol. 1, No. 1, Article . Publication date: October 2027.
Correct Verdicts, Flawed Reasoning: Structured Auditing of LLM-based Vulnerability Reasoning
17
VERA’s stage results makes this concrete: S5 (Trace Coverage) fails at 30.8% for CWE-772 (vs. 17.6% for CWE-476). Furthermore, S6 (State Transitions) fails at 58.2% (vs. 38.6% for CWE-476), due to hallucinated release operations (nullify(image) claimed in the trace but absent from source) and misordered transitions. Across both stages, models exhibit the same failure mode: when crucial lifecycle context lies beyond the visible slice, models commit prematurely to a verdict and insert unsupported trace artifacts to bridge the gap. VERA detects these as code adherence failures and flags them for human follow-up. An analyst can then inspect the full codebase to determine whether the claimed operations exist outside the slice boundary. Finding 4: Code patterns per stage. By decomposing reasoning chains into distinct stages, VERA reveals how specific code constructs systematically induce distinct failure modes. Stage 𝑆 5 (Trace Coverage) failures concentrate on structurally complex functions: failed cases exhibit 1.66× more loops, 1.52× more null checks, and 0.49× as many allocation calls compared to functions without reasoning errors (all 𝑝 < 0.01, Mann-Whitney 𝑈 [39]). In contrast, 𝑆 6 (State Transitions) failures show no significant correlation with structural complexity, including loops, branches, and free calls (𝑝 > 0.05 for all). Finally, 𝑆 8 (Verdict Consistency) failures occur significantly more often in functions with frequent null checks (1.61×, 𝑝 < 0.001) and fewer allocation calls (0.63×, 𝑝 < 0.001), whereas explicit null-assignment patterns (= NULL) mitigate verdict inconsistency (0.54×, 𝑝 < 0.001). Finding 5: Different LLMs make different reasoning mistakes. VERA surfaces distinct error profiles across detection models, offering actionable results for model selection. The most universal finding is S8: every model fails this stage at 50 − 69%, revealing that reconciling reasoning with the final verdict is a systematic weakness across all current architectures — and one that B1 misses almost entirely (Tbl. 6b). Beyond S8, models diverge: Sonnet-5 and Qwen achieve the lowest S3 and S5 error rates (13 − 22%) while Gemma struggles (33 − 34%); yet Gemma leads on S6 (23%) while Qwen and Sonnet-5 incur 43 − 47%. This heterogeneity enables targeted refinement — identifying a model’s exact failure stage rather than optimizing blindly for binary accuracy — and principled selection: models stronger on path traversal (Sonnet-5, Qwen) for deep control-flow vulnerabilities; models stronger on local state transitions (Gemma) for use-after-free lifecycles. In summary, VERA reveals that reasoning quality is not related to binary accuracy, uncovers crosssection inconsistencies and systematic over-prediction that free-form judges miss, and provides fine-grained model diagnostic profiles invisible to standard benchmarks. Thus, we answer RQ3. 5.5
Threats to Validity
1) Construct — training data contamination. Public benchmarks like SVEN and PrimeVul may have been exposed to LLMs during pre-training. Contamination could bias models toward memorized binary verdicts rather than genuine code analysis. We mitigated this with extra CVE data collected after the model training date, and observed no significant difference in reasoning error rates, suggesting contamination alone does not explain the failures observed. 2) External — CWE scope. Our evaluation covers five C/C++ memory and resource lifecycle CWEs, which are among the most exploited and hardest to detect vulnerability classes in practice. Extending VERA to other CWEs is left as future work. 3) Internal — structured format bias. VERA can only check what is explicitly recorded in the SRR. A model that produces sparse or underspecified output gives VERA fewer opportunities to detect errors, which may inflate its sound rate independent of actual reasoning quality. We observed this with smaller open-source models; in this study, the five frontier models we evaluate reliably adhere to the schema. 4) Internal- Mutation-judge Alignment. A potential concern is that our mutation operators (𝑀1 –𝑀8 ) target structural properties inherently favored by VERA’s deterministic checks over LLM judges. We mitigate this by grounding the , Vol. 1, No. 1, Article . Publication date: October 2027.
18
Boyue Caroline Hu, Kaivalya Ahir, Ronghao Ni, and Limin Jia
operators in naturally occurring errors. RQ1’s open-ended annotation confirms that 𝑀1 –𝑀8 directly instantiate the error categories (𝐹 1 –𝐹 8 ) that arise in real, un-mutated LLM reasoning. The mutations are therefore representative of real failures, not constructions designed to favor VERA. 6
Related Work
LLM-based vulnerability detection. Learning-based vulnerability detection has moved from neural models over program representations [7, 16, 17, 55, 67, 70] to large language models finetuned on code [69], with recent systems adding knowledge retrieval [18], code-graph guidance [32], or taint inference [35]. These systems optimize for detection accuracy; VERA is not a detector, it audits the reasoning that a detection model records in an SRR. Validating LLM-found vulnerabilities. LLM-based vulnerability detection increasingly include validity check of their vulnerability reports. LLift [33] prompts an LLM to review its responses against a set of rules, LLMSAN [60] discards reports whose recorded data-flow paths fail its checks; LLMDFA [59] checks path feasibility with an SMT solver and RepoAudit [27] asks the LLM to find contradictions among path conditions; BugScope [26] checks feasibility and whether its assumptions are justified by the code solely through an LLM-as-judge; VulInstruct [71] and DAGVul [37] check for correctness by comparing with ground truth information also with LLM-asjudge. These approaches ask whether a reported vulnerability is real; VERA checks the reasoning behind the verdict. These two goals are complementary to each other, a validator can confirm a bug exists; VERA can reveal whether the LLM found it for the right reasons. Checking LLM reasoning. Prior work has examined the reasoning behind vulnerability verdicts, but all rely on free-form CoT and LLM-as-judge. Free-form CoT has been shown to be unreliable, including in general natural language tasks [4, 57] and specifically for code reasoning [34, 58, 67]. LLM judges are widely used to evaluate model outputs [11, 61, 68], including for code generation and SE tasks [1, 8, 11, 36, 61], despite being susceptible to superficial cues [42]. Some vulnerability detection approaches attempt to check reasoning correctness, as mentioned before, VulInstruct [71] and DAGVul [37], but do so only by comparing generated reasoning against ground truth obtained through patches or human annotation using a holistic LLM-as-judge. VERA instead checks claimed scope, state transitions, and assumptions directly against the code slice, requiring no ground-truth annotations and enabling deterministic checks of a few reasoning failures. Evaluating reasoning judges. Most prior work evaluates vulnerability detectors against labeled ground-truth datasets. However, no such labels exist for reasoning quality, making judge evaluation significantly harder. Prior work evaluates judges on non-coding tasks by introducing predefined quality mutations into model outputs: FBI [15] mutates natural language output quality (e.g., coherence and fluency) against checklist criteria, and Delcourt et al. [13] mutate UML diagrams by injecting structural defects. This does not directly transfer to code reasoning: a meaningful mutation must identify a specific claim to modify, ensure it is wrong with respect to the source code, and attach a known failure category, but free-form CoT provides no clear anchors for any of these. VERA enables this by combining the SRR, which provides explicit claim boundaries and source grounding, with the failure taxonomy that defines typed failure categories to mutate. 7
Conclusion and Future Work
This paper presented VERA, a framework for automated auditing of LLM vulnerability reasoning that replaces free-form LLM-as-judges with a deterministic/LLM pipeline over machine-readable Structured Reasoning Records. Our evaluation shows that reasoning quality is decoupled from verdict correctness: LLMs are frequently right for the wrong reasons, and this goes undetected by , Vol. 1, No. 1, Article . Publication date: October 2027.
Correct Verdicts, Flawed Reasoning: Structured Auditing of LLM-based Vulnerability Reasoning
19
standard accuracy metrics and pure LLM-as-judges alike — LLM-as-judges miss 87% of the reasoning flaws VERA detects mechanically. VERA’s per-stage decomposition further reveals structural correlates of reasoning failures invisible to binary accuracy: loop-heavy functions concentrate trace coverage errors, while null-heavy pointer patterns drive verdict inconsistencies. In practice, a security analyst using an LLM-based vulnerability scanner can run VERA to filter hallucinated reports before acting on them, while LLM developers can use its stage-wise failure profiles as targeted fine-tuning signals. Future work will extend VERA beyond C/C++ memory vulnerabilities to semantic flaw classes, integrate interprocedural static analysis to improve pointer alias recall, and leverage VERA’s stage-wise diagnostics as fine-grained training signals for LLM alignment. 8
Data Availability
Our implementation of VERA, additional results and supplementary material can be found at https://anonymous.4open.science/r/VERA-D35F. References [1] Mohammad Abdollahi, Khandaker Rifah Tasnia, Soumit Kanti Saha, Jinqiu Yang, Song Wang, and Hadi Hemmati. 2026. Demystifying Errors in LLM Reasoning Traces: An Empirical Study of Code Execution Simulation. ACM Transactions on Software Engineering and Methodology (2026). doi:10.1145/3819239 [2] Aaron Adcock et al. 2026. The Llama 4 Herd: Architecture, Training, Evaluation, and Deployment Notes. ArXiv abs/2601.11659 (2026). https://api.semanticscholar.org/CorpusID:284910371 [3] Anthropic. 2026. Claude Sonnet 5 System Card. https://www.anthropic.com/claude-sonnet-5-system-card. [4] Iván Arcuschin, Jett Janiak, Robert Krzyzanowski, Senthooran Rajamanoharan, Neel Nanda, and Arthur Conmy. 2026. Chain-of-Thought Reasoning In The Wild Is Not Always Faithful. In Proceedings of the 43rd International Conference on Machine Learning (ICML). https://icml.cc/virtual/2026/poster/64450 [5] Pavel Avgustinov, Oege de Moor, Michael Peyton Jones, and Max Schäfer. 2016. QL: Object-oriented Queries on Relational Data. In 30th European Conference on Object-Oriented Programming (ECOOP 2016) (Leibniz International Proceedings in Informatics (LIPIcs), Vol. 56). Schloss Dagstuhl–Leibniz-Zentrum für Informatik, 2:1–2:25. doi:10.4230/ LIPIcs.ECOOP.2016.2 [6] Thomas Ball and Sriram K. Rajamani. 2002. The SLAM project: debugging system software via static analysis. In Proceedings of the 29th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (Portland, Oregon) (POPL ’02). Association for Computing Machinery, New York, NY, USA, 1–3. doi:10.1145/503272.503274 [7] Saikat Chakraborty, Rahul Krishna, Yangruibo Ding, and Baishakhi Ray. 2022. Deep Learning Based Vulnerability Detection: Are We There Yet? IEEE Trans. Software Eng. 48, 9 (2022), 3280–3296. doi:10.1109/TSE.2021.3087402 [8] Junkai Chen, Zhiyuan Pan, Xing Hu, Zhenhao Li, Ge Li, and Xin Xia. 2025. Reasoning Runtime Behavior of a Program with LLM: How Far are We?. In 47th IEEE/ACM International Conference on Software Engineering, ICSE 2025, Ottawa, ON, Canada, April 26 - May 6, 2025. IEEE, 1869–1881. doi:10.1109/ICSE55347.2025.00012 [9] Yizheng Chen, Zhoujie Ding, Lamya Alowain, Xinyun Chen, and David Wagner. 2023. Diversevul: A new vulnerable source code dataset for deep learning based vulnerability detection. In Proceedings of the 26th international symposium on research in attacks, intrusions and defenses. 654–668. [10] Xiao Cheng, Jiawei Ren, and Yulei Sui. 2024. Fast Graph Simplification for Path-Sensitive Typestate Analysis through Tempo-Spatial Multi-Point Slicing. Proceedings of the ACM on Software Engineering 1, FSE, Article 23 (2024), 23 pages. doi:10.1145/3643749 [11] Giuseppe Crupi, Rosalia Tufano, Alejandro Velasco, Antonio Mastropaolo, Denys Poshyvanyk, and Gabriele Bavota. 2025. On the Effectiveness of LLM-as-a-Judge for Code Generation and Summarization. IEEE Trans. Software Eng. 51, 8 (2025), 2329–2345. doi:10.1109/TSE.2025.3586082 [12] DeepSeek-AI. 2025. DeepSeek-V3 Technical Report. arXiv:2412.19437 [cs.CL] https://arxiv.org/abs/2412.19437 [13] Kevin Delcourt, Meriem Ben Chaaben, Abdelhamid Rouatbi, Luciano Marchezan, and Houari Sahraoui. 2026. Breaking Models to Test the Judge: A Mutation Testing Approach for Semantic Evaluators of Domain Class Diagrams. In Proceedings of the ACM/IEEE 29th International Conference on Model Driven Engineering Languages and Systems, MODELS 2026, Málaga, Spain, October 4-9, 2026, Lola Burgueño, Esther Guerra, and Mehrdad Sabetzadeh (Eds.). ACM, 400–406. doi:10.1145/3822455.3838768 [14] Yangruibo Ding, Yanjun Fu, Omniyyah Ibrahim, Chawin Sitawarin, Xinyun Chen, Basel Alomair, David A. Wagner, Baishakhi Ray, and Yizheng Chen. 2025. Vulnerability Detection with Code Language Models: How Far are We?. In 47th IEEE/ACM International Conference on Software Engineering, ICSE 2025, Ottawa, ON, Canada, April 26 - May 6, , Vol. 1, No. 1, Article . Publication date: October 2027.
20
Boyue Caroline Hu, Kaivalya Ahir, Ronghao Ni, and Limin Jia
2025. IEEE, 1729–1741. doi:10.1109/ICSE55347.2025.00038 [15] Sumanth Doddapaneni, Mohammed Safi Ur Rahman Khan, Sshubam Verma, and Mitesh M. Khapra. 2024. Finding Blind Spots in Evaluator LLMs with Interpretable Checklists. In Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, EMNLP 2024, Miami, FL, USA, November 12-16, 2024, Yaser Al-Onaizan, Mohit Bansal, and Yun-Nung Chen (Eds.). Association for Computational Linguistics, 16279–16309. doi:10.18653/V1/2024.EMNLPMAIN.911 [16] Xiaohu Du, Ming Wen, Jiahao Zhu, Zifan Xie, Bin Ji, Huijun Liu, Xuanhua Shi, and Hai Jin. 2024. Generalizationenhanced code vulnerability detection via multi-task instruction fine-tuning. In Findings of the Association for Computational Linguistics: ACL 2024. 10507–10521. [17] Xueying Du, Geng Zheng, Kaixin Wang, Yi Zou, Yujia Wang, Wentai Deng, Jiayi Feng, Mingwei Liu, Bihuan Chen, Xin Peng, et al. 2026. Vul-rag: Enhancing llm-based vulnerability detection via knowledge-level rag. ACM Transactions on Software Engineering and Methodology 35, 10 (2026), 1–25. [18] Xueying Du, Geng Zheng, Kaixin Wang, Yi Zou, Yujia Wang, Wentai Deng, Jiayi Feng, Mingwei Liu, Bihuan Chen, Xin Peng, Tao Ma, and Yiling Lou. 2026. Vul-RAG: Enhancing LLM-based Vulnerability Detection via Knowledge-level RAG. ACM Transactions on Software Engineering and Methodology 35, 10 (2026), 1–25. doi:10.1145/3797277 [19] Dawson Engler, Benjamin Chelf, Andy Chou, and Seth Hallem. 2000. Checking system rules using system-specific, programmer-written compiler extensions. In Proceedings of the 4th Conference on Symposium on Operating System Design & Implementation - Volume 4 (San Diego, California) (OSDI’00). USENIX Association, USA, Article 1. [20] Jiahao Fan, Yi Li, Shaohua Wang, and Tien N. Nguyen. 2020. A C/C++ Code Vulnerability Dataset with Code Changes and CVE Summaries. In Proceedings of the 17th International Conference on Mining Software Repositories (Seoul, Republic of Korea) (MSR ’20). Association for Computing Machinery, New York, NY, USA, 508–512. doi:10.1145/3379597.3387501 [21] Chongzhou Fang, Ning Miao, Shaurya Srivastav, Jialin Liu, Ruoyu Zhang, Ruijie Fang, Asmita, Ryan Tsang, Najmeh Nazari, Han Wang, and Houman Homayoun. 2024. Large Language Models for Code Analysis: Do LLMs Really Do Their Job?. In 33rd USENIX Security Symposium (USENIX Security 24). USENIX Association, Philadelphia, PA, 829–846. https://www.usenix.org/conference/usenixsecurity24/presentation/fang [22] Stephen J. Fink, Eran Yahav, Nurit Dor, G. Ramalingam, and Emmanuel Geay. 2006. Effective typestate verification in the presence of aliasing. In Proceedings of the ACM/SIGSOFT International Symposium on Software Testing and Analysis, ISSTA 2006, Portland, Maine, USA, July 17-20, 2006, Lori L. Pollock and Mauro Pezzè (Eds.). ACM, 133–144. doi:10.1145/1146238.1146254 [23] Andrea Fioraldi, Dominik Maier, Heiko Eißfeldt, and Marc Heuse. 2020. AFL++ : Combining Incremental Steps of Fuzzing Research. In 14th USENIX Workshop on Offensive Technologies (WOOT 20). USENIX Association. https: //www.usenix.org/conference/woot20/presentation/fioraldi [24] Robert Geirhos, Jörn-Henrik Jacobsen, Claudio Michaelis, Richard S. Zemel, Wieland Brendel, Matthias Bethge, and Felix A. Wichmann. 2020. Shortcut Learning in Deep Neural Networks. CoRR abs/2004.07780 (2020). arXiv:2004.07780 https://arxiv.org/abs/2004.07780 [25] GLM-5-Team. 2026. GLM-5: from Vibe Coding to Agentic Engineering. arXiv:2602.15763 [cs.LG] https://arxiv.org/abs/ 2602.15763 [26] Jinyao Guo, Chengpeng Wang, Dominic DeLuca, Jinjie Liu, Zhuo Zhang, and Xiangyu Zhang. 2026. BugScope: Learn to Detect Bugs Like Human. In Third Conference on Language Modeling. https://openreview.net/forum?id=pzZYA9MsQQ [27] Jinyao Guo, Chengpeng Wang, Xiangzhe Xu, Zian Su, and Xiangyu Zhang. 2025. RepoAudit: An Autonomous LLMAgent for Repository-Level Code Auditing. In Forty-second International Conference on Machine Learning, ICML 2025, Vancouver, BC, Canada, July 13-19, 2025 (Proceedings of Machine Learning Research, Vol. 267), Aarti Singh, Maryam Fazel, Daniel Hsu, Simon Lacoste-Julien, Felix Berkenkamp, Tegan Maharaj, Kiri Wagstaff, and Jerry Zhu (Eds.). PMLR / OpenReview.net. https://proceedings.mlr.press/v267/guo25n.html [28] Jingxuan He and Martin T. Vechev. 2023. Large Language Models for Code: Security Hardening and Adversarial Testing. In CCS. ACM, 1865–1879. [29] Ziwei Ji, Nayeon Lee, Rita Frieske, Tiezheng Yu, Dan Su, Yan Xu, Etsuko Ishii, Ye Jin Bang, Andrea Madotto, and Pascale Fung. 2023. Survey of Hallucination in Natural Language Generation. ACM Comput. Surv. 55, 12, Article 248 (March 2023), 38 pages. doi:10.1145/3571730 [30] Brittany Johnson, Yoonki Song, Emerson Murphy-Hill, and Robert Bowdidge. 2013. Why don’t software developers use static analysis tools to find bugs?. In 2013 35th International Conference on Software Engineering (ICSE). 672–681. doi:10.1109/ICSE.2013.6606613 [31] L. Lamport. 1977. Proving the Correctness of Multiprocess Programs. IEEE Transactions on Software Engineering SE-3, 2 (1977), 125–143. doi:10.1109/TSE.1977.229904 [32] Ahmed Lekssays, Hamza Mouhcine, Khang Tran, Ting Yu, and Issa Khalil. 2025. LLMxCPG: Context-Aware Vulnerability Detection Through Code Property Graph-Guided Large Language Models. In 34th USENIX Security Symposium, USENIX Security 2025, Seattle, WA, USA, August 13-15, 2025, Lujo Bauer and Giancarlo Pellegrino (Eds.). USENIX Association,
, Vol. 1, No. 1, Article . Publication date: October 2027.
Correct Verdicts, Flawed Reasoning: Structured Auditing of LLM-based Vulnerability Reasoning
21
489–507. https://www.usenix.org/conference/usenixsecurity25/presentation/lekssays [33] Haonan Li, Yu Hao, Yizhuo Zhai, and Zhiyun Qian. 2024. Enhancing Static Analysis for Practical Bug Detection: An LLM-Integrated Approach. Proc. ACM Program. Lang. 8, OOPSLA1 (2024), 474–499. doi:10.1145/3649828 [34] Yansong Li, Paula Branco, Alexander M. Hoole, Manish Marwah, Hari Manassery Koduvely, Guy-Vincent Jourdan, and Stephan Jou. 2025. SV-TrustEval-C: Evaluating Structure and Semantic Reasoning in Large Language Models for Source Code Vulnerability Analysis. In IEEE Symposium on Security and Privacy, SP 2025, San Francisco, CA, USA, May 12-15, 2025, Marina Blanton, William Enck, and Cristina Nita-Rotaru (Eds.). IEEE, 3014–3032. doi:10.1109/SP61157.2025.00191 [35] Ziyang Li, Saikat Dutta, and Mayur Naik. 2025. IRIS: LLM-Assisted Static Analysis for Detecting Security Vulnerabilities. In The Thirteenth International Conference on Learning Representations, ICLR 2025, Singapore, April 24-28, 2025. OpenReview.net. https://openreview.net/forum?id=9LdJDU7E91 [36] Changshu Liu, Yang Chen, and Reyhaneh Jabbarvand. 2026. CodeMind: Evaluating Large Language Models for Implicit and Explicit Code Execution Reasoning. IEEE Trans. Software Eng. 52, 7 (2026), 2031–2046. doi:10.1109/TSE.2026.3691250 [37] Li Lu, Yanjie Zhao, Hongzhou Rao, Kechi Zhang, and Haoyu Wang. 2026. Evaluating and Enhancing the Vulnerability Reasoning Capabilities of Large Language Models. arXiv:2602.06687 [cs.CR] https://arxiv.org/abs/2602.06687 [38] Qing Lyu, Shreya Havaldar, Adam Stein, Li Zhang, Delip Rao, Eric Wong, Marianna Apidianaki, and Chris CallisonBurch. 2023. Faithful Chain-of-Thought Reasoning. In Proceedings of the 13th International Joint Conference on Natural Language Processing and the 3rd Conference of the Asia-Pacific Chapter of the Association for Computational Linguistics, IJCNLP 2023 -Volume 1: Long Papers, Nusa Dua, Bali, November 1 - 4, 2023, Jong C. Park, Yuki Arase, Baotian Hu, Wei Lu, Derry Wijaya, Ayu Purwarianti, and Adila Alfa Krisnadhi (Eds.). Association for Computational Linguistics, 305–329. doi:10.18653/V1/2023.IJCNLP-MAIN.20 [39] Henry B Mann and Donald R Whitney. 1947. On a test of whether one of two random variables is stochastically larger than the other. The annals of mathematical statistics (1947), 50–60. [40] Mistral AI. 2025. Mistral Large 3 (mistral-large-2512). https://docs.mistral.ai/models/mistral-large-3-25-12. [41] MITRE. 2024. CWE-416: Use After Free. https://cwe.mitre.org/data/definitions/416.html. Common Weakness Enumeration. [42] Jiwon Moon, Yerin Hwang, Dongryeol Lee, Taegwan Kang, Yongil Kim, and Kyomin Jung. 2026. Don’t Judge Code by Its Cover: Exploring Biases in LLM Judges for Code Evaluation. In Findings of the Association for Computational Linguistics: EACL 2026, Rabat, Morocco, March 24-29, 2026 (Findings of ACL), Vera Demberg, Kentaro Inui, and Lluís Marquez (Eds.). Association for Computational Linguistics, 1364–1389. doi:10.18653/V1/2026.FINDINGS-EACL.70 [43] Nicholas Nethercote and Julian Seward. 2007. Valgrind: a framework for heavyweight dynamic binary instrumentation. In Proceedings of the 28th ACM SIGPLAN Conference on Programming Language Design and Implementation (San Diego, California, USA) (PLDI ’07). Association for Computing Machinery, New York, NY, USA, 89–100. doi:10.1145/1250734. 1250746 [44] Yu Nong, Guangbei Yi, Mohammed Aldeen, Long Cheng, Hongxin Hu, and Haipeng Cai. 2026. Assessing and Improving Prompting Large Language Models for Software Vulnerability Analysis. ACM Trans. Softw. Eng. Methodol. (June 2026). doi:10.1145/3821416 Just Accepted. [45] NVIDIA. 2025. Nemotron 3 Nano: Open, Efficient Mixture-of-Experts Hybrid Mamba-Transformer Model for Agentic Reasoning. arXiv:2512.20848 [cs.CL] https://arxiv.org/abs/2512.20848 [46] OpenAI et al. 2024. GPT-4 Technical Report. arXiv:2303.08774 [cs.CL] https://arxiv.org/abs/2303.08774 [47] Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri. 2022. Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions. In 43rd IEEE Symposium on Security and Privacy, SP 2022, San Francisco, CA, USA, May 22-26, 2022. IEEE, 754–768. doi:10.1109/SP46214.2022.9833571 [48] Van-Thuan Pham, Marcel Böhme, Andrew E Santosa, Alexandru Răzvan Căciulescu, and Abhik Roychoudhury. 2019. Smart greybox fuzzing. IEEE Transactions on Software Engineering 47, 9 (2019), 1980–1997. [49] r2c / Semgrep Inc. 2024. Semgrep: Lightweight static analysis for many languages. https://semgrep.dev. [50] Zoltán Ságodi, Gábor Antal, Bence Bogenfürst, Martin Isztin, Péter Hegedundefineds, and Rudolf Ferenc. 2024. Reality Check: Assessing GPT-4 in Fixing Real-World Software Vulnerabilities. In Proceedings of the 28th International Conference on Evaluation and Assessment in Software Engineering (Salerno, Italy) (EASE ’24). Association for Computing Machinery, New York, NY, USA, 252–261. doi:10.1145/3661167.3661207 [51] Fred B. Schneider. 2000. Enforceable security policies. ACM Trans. Inf. Syst. Secur. 3, 1 (Feb. 2000), 30–50. doi:10.1145/ 353323.353382 [52] Konstantin Serebryany, Derek Bruening, Alexander Potapenko, and Dmitriy Vyukov. 2012. AddressSanitizer: A Fast Address Sanity Checker. In 2012 USENIX Annual Technical Conference (USENIX ATC 12). USENIX Association, Boston, MA, 309–318. https://www.usenix.org/conference/atc12/technical-sessions/presentation/serebryany [53] Aaditya Singh et al. 2026. OpenAI GPT-5 System Card. arXiv:2601.03267 [cs.CL] https://arxiv.org/abs/2601.03267 [54] Robert E. Strom and Shaula Yemini. 1986. Typestate: A Programming Language Concept for Enhancing Software Reliability. IEEE Trans. Software Eng. 12, 1 (1986), 157–171. doi:10.1109/TSE.1986.6312929
, Vol. 1, No. 1, Article . Publication date: October 2027.
22
Boyue Caroline Hu, Kaivalya Ahir, Ronghao Ni, and Limin Jia
[55] Zian Su, Xiangzhe Xu, Ziyang Huang, Zhuo Zhang, Yapeng Ye, Jianjun Huang, and Xiangyu Zhang. 2024. Codeart: Better code models by attention regularization when symbols are lacking. Proceedings of the ACM on Software Engineering 1, FSE (2024), 562–585. [56] Gemma Team. 2026. Gemma 4 Technical Report. arXiv:2607.02770 [cs.CL] https://arxiv.org/abs/2607.02770 [57] Miles Turpin, Julian Michael, Ethan Perez, and Samuel R. Bowman. 2023. Language Models Don’t Always Say What They Think: Unfaithful Explanations in Chain-of-Thought Prompting. In Advances in Neural Information Processing Systems 36: Annual Conference on Neural Information Processing Systems 2023, NeurIPS 2023, New Orleans, LA, USA, December 10 - 16, 2023, Alice Oh, Tristan Naumann, Amir Globerson, Kate Saenko, Moritz Hardt, and Sergey Levine (Eds.). http://papers.nips.cc/paper_files/paper/2023/hash/ed3fea9033a80fea1376299fa7863f4a-Abstract-Conference.html [58] Saad Ullah, Mingji Han, Saurabh Pujar, Hammond Pearce, Ayse K. Coskun, and Gianluca Stringhini. 2024. LLMs Cannot Reliably Identify and Reason About Security Vulnerabilities (Yet?): A Comprehensive Evaluation, Framework, and Benchmarks. In IEEE Symposium on Security and Privacy, SP 2024, San Francisco, CA, USA, May 19-23, 2024. IEEE, 862–880. doi:10.1109/SP54263.2024.00210 [59] Chengpeng Wang, Wuqi Zhang, Zian Su, Xiangzhe Xu, Xiaoheng Xie, and Xiangyu Zhang. 2024. LLMDFA: Analyzing Dataflow in Code with Large Language Models. In Advances in Neural Information Processing Systems 37: Annual Conference on Neural Information Processing Systems 2024, NeurIPS 2024, Vancouver, BC, Canada, December 10 - 15, 2024, Amir Globersons, Lester Mackey, Danielle Belgrave, Angela Fan, Ulrich Paquet, Jakub M. Tomczak, and Cheng Zhang (Eds.). http://papers.nips.cc/paper_files/paper/2024/hash/ed9dcde1eb9c597f68c1d375bbecf3fc-Abstract-Conference. html [60] Chengpeng Wang, Wuqi Zhang, Zian Su, Xiangzhe Xu, and Xiangyu Zhang. 2024. Sanitizing Large Language Models in Bug Detection with Data-Flow. In Findings of the Association for Computational Linguistics: EMNLP 2024, Miami, Florida, USA, November 12-16, 2024 (Findings of ACL, Vol. EMNLP 2024), Yaser Al-Onaizan, Mohit Bansal, and Yun-Nung Chen (Eds.). Association for Computational Linguistics, 3790–3805. doi:10.18653/V1/2024.FINDINGS-EMNLP.217 [61] Ruiqi Wang, Jiyu Guo, Cuiyun Gao, Guodong Fan, Chun Yong Chong, and Xin Xia. 2025. Can LLMs Replace Human Evaluators? An Empirical Study of LLM-as-a-Judge in Software Engineering. Proc. ACM Softw. Eng. 2, ISSTA (2025), 1955–1977. doi:10.1145/3728963 [62] Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed Chi, Quoc Le, and Denny Zhou. 2022. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. In Advances in Neural Information Processing Systems (NeurIPS), Vol. 35. 24824–24837. doi:10.48550/arxiv.2201.11903 [63] Chunqiu Steven Xia, Matteo Paltenghi, Jia Le Tian, Michael Pradel, and Lingming Zhang. 2024. Fuzz4All: Universal Fuzzing with Large Language Models. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering (Lisbon, Portugal) (ICSE ’24). Association for Computing Machinery, New York, NY, USA, Article 126, 13 pages. doi:10.1145/3597503.3639121 [64] Hanxiang Xu, Shenao Wang, Ningke Li, Kailong Wang, Yanjie Zhao, Kai Chen, Ting Yu, Yang Liu, and Haoyu Wang. 2025. Large Language Models for Cyber Security: A Systematic Literature Review. ACM Trans. Softw. Eng. Methodol. (Sept. 2025). doi:10.1145/3769676 Just Accepted. [65] Fabian Yamaguchi, Nico Golde, Daniel Arp, and Konrad Rieck. 2014. Modeling and Discovering Vulnerabilities with Code Property Graphs. In 2014 IEEE Symposium on Security and Privacy (SP). 590–604. doi:10.1109/SP.2014.44 [66] An Yang et al. 2025. Qwen3 Technical Report. arXiv:2505.09388 [cs.CL] https://arxiv.org/abs/2505.09388 [67] Cen Zhang, Younggi Park, Fabian Fleischer, Yu-Fu Fu, Jiho Kim, Dongkwan Kim, Youngjoon Kim, Qingxiao Xu, Andrew Chin, Ze Sheng, Hanqing Zhao, Michael Pelican, David J. Musliner, Jeff Huang, Jon Silliman, Mikel Mcdaniel, Jefferson Casavant, Isaac Goldthwaite, Nicholas Vidovich, Matthew Lehman, and Taesoo Kim. 2026. SoK: DARPA’s AI Cyber Challenge (AIxCC): Competition Design, Architectures, and Lessons Learned. In 35th USENIX Security Symposium (USENIX Security 26). USENIX Association, Baltimore, MD, 2705–2724. https://www.usenix.org/conference/ usenixsecurity26/presentation/zhang-cen [68] Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Yonghao Zhuang, Zi Lin, Zhuohan Li, Dacheng Li, Eric P. Xing, Hao Zhang, Joseph E. Gonzalez, and Ion Stoica. 2023. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. In Advances in Neural Information Processing Systems 36: Annual Conference on Neural Information Processing Systems 2023, NeurIPS 2023, New Orleans, LA, USA, December 10 - 16, 2023, Alice Oh, Tristan Naumann, Amir Globerson, Kate Saenko, Moritz Hardt, and Sergey Levine (Eds.). http://papers.nips.cc/paper_files/ paper/2023/hash/91f18a1287b398d378ef22505bf41832-Abstract-Datasets_and_Benchmarks.html [69] Xin Zhou, Sicong Cao, Xiaobing Sun, and David Lo. 2025. Large Language Model for Vulnerability Detection and Repair: Literature Review and the Road Ahead. ACM Trans. Softw. Eng. Methodol. 34, 5 (2025), 145:1–145:31. doi:10.1145/3708522 [70] Yaqin Zhou, Shangqing Liu, Jing Kai Siow, Xiaoning Du, and Yang Liu. 2019. Devign: Effective Vulnerability Identification by Learning Comprehensive Program Semantics via Graph Neural Networks. In Advances in Neural Information Processing Systems 32: Annual Conference on Neural Information Processing Systems 2019, NeurIPS 2019, December 8-14, 2019, Vancouver, BC, Canada, Hanna M. Wallach, Hugo Larochelle, Alina Beygelzimer, Florence
, Vol. 1, No. 1, Article . Publication date: October 2027.
Correct Verdicts, Flawed Reasoning: Structured Auditing of LLM-based Vulnerability Reasoning
23
d’Alché-Buc, Emily B. Fox, and Roman Garnett (Eds.). 10197–10207. https://proceedings.neurips.cc/paper/2019/hash/ 49265d2447bc3bbfe9e76306ce40a31f-Abstract.html [71] Hao Zhu, Jia Li, Cuiyun Gao, Jiaru Qian, Yihong Dong, Huanyu Liu, Lecheng Wang, Ziliang Wang, Xiaolong Hu, and Ge Li. 2026. VulInstruct: Teaching LLMs Root-Cause Reasoning for Vulnerability Detection via Security Specifications. Proc. ACM Softw. Eng. 3, FSE (2026), 2813–2834. doi:10.1145/3808132 [72] Lianghui Zhu, Xinggang Wang, and Xinlong Wang. 2025. JudgeLM: Fine-tuned Large Language Models are Scalable Judges. In The Thirteenth International Conference on Learning Representations, ICLR 2025, Singapore, April 24-28, 2025. OpenReview.net. https://openreview.net/forum?id=xsELpEPn4A
, Vol. 1, No. 1, Article . Publication date: October 2027.
Related documents
- Correct Verdicts, Flawed Reasoning: Structured Auditing of LLM-based Vulnerability Reasoning#1215469
- Towards Behavior Tree-Guided Vulnerability Detection with Lightweight LLMs#822187
- Can Failed Trajectories Reveal Where Agents Go Wrong? Agentic Failure Attribution Without Step-Level Labels#1297457
- Beyond Predefined Sinks: Security-Aware Dependency Analysis for LLM Agents#1187692
- Beyond Predefined Sinks: Security-Aware Dependency Analysis for LLM Agents#1181566
Retrieved via Conceptio: every document is proof-bundled with source, license, and retrieval metadata.
Read the Docs → · View CLI source on GitHub · Conceptio Open Knowledge Archive