LLMDFA: Analyzing Dataflow in Code with Large Language Models
Authors: Chengpeng Wang
Wuqi Zhang
Zian Su
Xiangzhe Xu
Xiaoheng Xie
Xiangyu Zhang
Venue: NeurIPS 2024 poster (2024)
Keywords: LLM for code
code reasoning
dataflow analysis
Primary area: machine_learning_for_other_sciences_and_fields
TL;DR: Propose an LLM-powered dataflow analysis, showing the potential of LLMs in resolving complex code reasoning problems.

Abstract: Dataflow analysis is a fundamental code analysis technique that identifies dependencies between program values. Traditional approaches typically necessitate successful compilation and expert customization, hindering their applicability and usability for analyzing uncompilable programs with evolving analysis needs in real-world scenarios. This paper presents LLMDFA, an LLM-powered compilation-free and customizable dataflow analysis framework. To address hallucinations for reliable results, we decompose the problem into several subtasks and introduce a series of novel strategies. Specifically, we leverage LLMs to synthesize code that outsources delicate reasoning to external expert tools, such as using a parsing library to extract program values of interest and invoking an automated theorem prover to validate path feasibility. Additionally, we adopt a few-shot chain-of-thought prompting to summarize dataflow facts in individual functions, aligning the LLMs with the program semantics of small code snippets to mitigate hallucinations. We evaluate LLMDFA on synthetic programs to detect three representative types of bugs and on real-world Android applications for customized bug detection. On average, LLMDFA achieves 87.10% precision and 80.77% recall, surpassing existing techniques with F1 score improvements of up to 0.35. We have open-sourced LLMDFA at https://github.com/chengpeng-wang/LLMDFA.

LLMDFA: Analyzing Dataflow in Code with Large Language Models
Chengpeng Wang', Wuqi Zhang", Zian Su', Xiangzhe Xu', Xiaoheng Xie Xiangyu Zhang'
Purdue University, Hong Kong University of Science and Technology, 3 Ant Group (wang6590, su284, xu1415, xyzhang) edu wuqi hrgg..hhan@coonnec.. ust hk, xiexie@antgroup.co
Abstract
Dataflow analysis is fundamental code analysis technique that identifies depen- dencies between program values. Traditional approaches typically necessitate successful compilation and expert customization, hindering their applicability and usability for analyzing uncompilable programs with evolving analysis needs real- world scenarios. This paper presents LLMDFA, an LLM-powered compilation-fiee and customizable dataflow analysis framework. able results, we decompose the problem into several subtasks and introduce series novel strategies. Specifically, we leverage LLMs to synthesize code that out- sources delicate reasoning to external expert tools, such using parsing library to extract program values of interest and invoking an automated theorem prover validate path feasibility. Additionally, prompting to summarize dataflow facts in individual functions, aligning the LLMs with the program semanties of small code snippets mitigate hallucinations. We evaluate LLMDFA on synthetic programs to detect three representative types of bugs and real-world Android applications for customized bug detection. On average, LLMDFA achieves 80%10% precision and 80.77% recall, surpassing exist- ing techniques with F1 score improvements of up to 0.35. We have open-sourced LLMDFA at https: //gtt/////tttt..../. thub. com/ chengpeng wang LLMDFA
address hallucinations for reli-
adopt few-shot chain-of-thouge
1 Introduction
Dataflow analysis is a formal method that iden- tifies the dependence between values pro- gram [ Its primary objective is to determine whether the value of variable defined a par- ticular line, referred to source, affects the value of another variable used at a subsequent line, referred to sink. This crucial informa-
public class Demo public static int foolint int b) if (Math. abs(b) 1)
System.out.printta b);//sink: safe return b;
public static void main(Stringl) args int x;
x Integer.parsen (nneger..prsstntttasslooos////
10
int y = x * x 1;
tion offers valuable insights into various down- stream applications, such program optimiza-
/ y: //sink: y, safe
12
z =x; y = fooly, z);
tion [2] and bug detection [ 4. Figure for example, we regard the variable x: at line 9 as source and the divisors at lines 4, 11, and 14 sinks and eventually detect divide-by-zero
14
Systen.out.printix y)://sink: y, buggy
15
16 }
Figure 1: An example of DBZ bug
(DBZ) bug at line 14. The intuition is that x at line 9 comes from user input and can be zero. it can flow to the divisors, DBZ bugs may occur.
Despite decades effort, current dataflow analysis techniques have drawbacks in terms of applicability and usability. First, many scenarios where dataflow analysis is needed involve incomplete and uncompilable programs, e.g., on-the-fly code flaw analysis in Integrated Development
38th Conference on Neural Information Processing Systems (NcurIPS 2024).

---

incomplete
Compiler Fronlend
prompt
LLM
resuli
compilable
IR
customized DFA
result
(x) Classical dataflow analysis relies on compilation and customization
(b) new paradigm: L..M-powered dataflow analysis
Figure 2: Two different paradigms of dataflow analysis
Environments (IDEs). However, current techniques typically rely on intermediate representations (IRs) generated by compiler frontends, such as LLVM IR [5] produced by the Clang compiler. as shown in Figure a This reliance limits their applicability in analyzing incomplete programs, leading to the failure of analysis. Second, specific downstream tasks require eustomizing the analysis to fit specific needs, such as the detection of specific bug type. In the DBZ detection, for example, the user has to extract variables potentially assigned with zero (sources) and variables used as the divisors (sinks). It is a challenging task for non-experts since they need deep understanding of program representation (e.g., LLVM IR) for customization. This limitation hinders the usability of classical approaches to address evolving software analysis needs in real-world scenarios [6]
In the past year, there has been a vast proliferation of software engincering applications built upon large language models (LLMs), from which we observe the exceptional performance of LLMs in comprehending code snippets 7 8 g I0. Specifically,, by treating LLMs as code interpreters and devising appropriate prompts, we can directly obtain semantic properties from source code. For instance, by constructing a prompt like "Does the value of the variable used line 13 depend on the value of variable defined at line 9?", we can ascertain the dataflow fact between the two program values. Likewise, we can leverage LLMs to automate the extraction of specific sources and sinks by describing their characteristics as prompts. This empowers developers to tailor dataflow analysis to their specific requirements. As shown in Figure 22b)), such LL. --owerrd dataflow analysis gets rid of compilation and avoids complicated customization. In the rest of this paper, our demonstration is consistently within the context of a downstream task, and our references to sources and sinks specifically pertain to that task.
However, instantiating dataflow analysis using LLMs is far from trivial, as their hallucina- threaten the reliability of results. First, the misidentification of sources and sinks leads to dataflow facts that are irrelevant the user's interest, directly resulting in incorrect results of dataflow analysis. Second, sources and sinks can be distributed across multiple functions, entailing an- alyzing a large body of code that likely exceeds the input context limit. In addition, incorrect dataflow facts in single functions can accumulate and magnify, thereby impacting the overall performance. Third, the validity of a dataflow fact depends on the feasibility of the program path inducing the dataflow fact. If the path condition is deemed unsatisfiable, path (4. Regrettably, deciding the satisfiability of logical constraint is a complex reasoning task that LLMs cannot effectively solve [14). In Figure [ for example, gpt- 5-turbo- --turbo-0025 reports DBZ bug at line as a false positive because it cannot discover the unsatisfiable branch condition at line 3.
tions 11 12 13
concrete execution will occur along that
This paper presents LLMDFA, an LLLM-poweree compilation free and customizable dataflow analysis. To mitigate hallucination, we decompose the analysis into three sub- cabb-prollms, namely source/sink extraction, dataflow summarization, and path feasibility validation, which target more manageable tasks or smaller-sized programs. Technically, we introduce two innovative designs to solve the three sub-problems. First, instead of directly prompting LLMs, we leverage I.MSs as code synthesizers to delegate the analysis to external expert tools like parsing librarics and SMT solvers [15], which effectively mitigates the hallucinations in the source/sink extraction and path fcasibility validation. Second, we employ a few-shot of-thughtt (CoT) prompting strategy [16) to make LLMs aligned with program semantics, which enables LLMDFA to overcome the hallucination in summarizing dataflow facts of single functions. Compared to traditional dataflow analysis, LLMDFA offers distinct advantages in terms of applicability and autonomy. It can be applied to incomplete programs, includ- ing those in the development phase. Additionally, it can autonomously create and utilize new tools with minimal human intervention, requiring no particular expertise in customizing dataflow analysis.
We evaluate LLMDFA in the context of bug detection. Specifically, we choose Divide-by-Zero (DBZ), Stoss-Site-Scripting [ and OS Command Injection (OSCI in Juliet Test Suite [17
I In an XSS bug, a dataflow fact across variables denoting different websites allows undesirable exccution. 2 Using external input for OS command construction can lead OSCI bug.

---

for the evaluation. LLMDFA achieves high precision and recall when using different LLMs. For example, equipped with gpt-3. 5- t-rbuuuooo11 00200 it obtains 73. 73.75%/1001 15.%%/1..00%/1..0000.. precision and 92. 12.16%/92..1 %/78.388 .3% recall in the DBZ/XSS/OSCI detection. LLMDFA substantially outperforms a classic dataflow analyzer CodeFuseeuery [8]] and an end-to-end solution based on few-shot CoT prompting, improving the average F1 score by 0.23 and 0.36, respectively. Besides, we evaluate LLMDFA upon real-world Android malware applications in TaintBench [19] and achieve 74.63% precision and 60.24% recall. It surpasses the two baselines with improvements in the Fl score of 0.12 and 0.35, respectively. To the best of our knowledge, LLMDFA is the first trial that leverages LLMs to achieve compilation-free and customizable dataflow analysis. It offers valuable insights into future works in analyzing programs using LLMs, such as program verification (20 10 and repair [9]
Preliminaries and Problem Formulation
Definition 1. (Control Flow Graph) The control flow graph (CFG) of a given program Pis labeled directed graph := (S, Ex). Here, s E S is a statement in the program. For any (s, s') E S x S, Ec(s, s') is the boolean expression under which that s' is executed just after s.
Figure 3 shows a (partial) CFG of the program in Figure [ It depicts several important program facts, such as individual branch conditions and caller-callee relation. To simplify for-
true
Math.
Systen.cur-prinatina b];
mulation, we introduce V par, Vidss Vá and Volae that contain parameters (of the function), return values, arguments (passed to invoked functions), and output values in function f. re- spectively. which can be easily derived from CFG. Two dashed boxes in Figure show the assignments from arguments to parameters and from the return value to the output value. Based on CFG, we can examine how a program value propagates via dataflow facts.
Systien.out-poo www.oottt--rpxxxx / yi:
Figure 3: An example of CFG
Definition 2. (Dataflow Fact) There is a dataflow fact from the variable at line m to the variable b at line n, denoted by a@4,, + b@e,, if the value of can affect the value of b.
In Figure [I, the variable is assigned with the value of the variable at line 12 and used as the second argument at line 13. Hence, we have rā,g + 1. 2 > 20L13, and 2r <>> = =@013- Dataflow facts are crucial for many downstream tasks, such as bug detection [4] and program slicing [- Specifically, sensitive information leakage, which may cause XSS bugs (21) can be detected by identifying dataflow facts from sensitive data to leaked data. For other bug types, additional restrictions may be imposed on dataflow facts. In the DBZ detection, for example, we constrain that dataflow fact connects two equal values.
The execution of statement s can be guarded by a condition. A precise analysis should be path sensirive, i.e., validating the feasibility of a fact-inducing path according to the path condition.
Definition 3. (Path Condition) The path condition of a program path p := st St ... st,, is (p) A Ee (St, S1y42). ), where st is the statement at line is and can be executed just before $1,41'
We have the dataflow fact rülgy + b@E, in Figure 1 However, the statement at line 4 is guarded by Math.abs (b) > 0. It is evaluated to be false as the parameter b is passed with O. Hence, the dataflow fact aātg + b&4, cannot occur in any concrete execution. A math-insensitive analysis would introduce a false positive at line 4 in the DBZ detection.
Our Problem. real-world downstream applications, dataflow analysis focuses on the dataflow facts between specific kinds of variables referred to sources and sinks. In the DBZ detection [2)] for example, we need to identify the variables that could potentially yield zero values as sources and set the divisors as sinks. Lastly, we formulate the dataflow analysis problem follows.
Given the source code of program P and its CFG G, identify the dataflow facts from user- specified sources Usrc E Vsrc and sinks Usink Veink in path-sensitive manner.
As demonstrated in Section existing dataflow analysis techniques 23 24 4 heavily rely on
compilation and pose the difficulty of customization, which hinders their applicability and usability (.. Although several machine learning-based bug detection techniques (25] 26 enable compilation-fres analysis, they cannot answer a general dataflow analysis question formulated above and struggle to support the customization for different bug types without large training dataset. To fill the research
3

---

LibRa
info Syuteone
Solver
systhoi
crabase
Extractor
Source/ Sink
Summarizer
Examples
Summary
Sangt
SAT
LLM
Gi
Script
LLM
Validator
Bug
Phase
Phase II:
Phase
Program
CFG
Souree/iink Extraction
Dutaflow Summarization
Path Feasibility Validation
Figure 4: The workflow of LLMDFA consists of three phases
gap, aim to propose
paradigm of dataflow analysis in this work. Specifically, realize the
exceptional performance of LLMs in program comprehension 27 28 highlighting the potential for identifying dataflow facts. Besides, L.MMs demonstrate a strong capability of understanding natural language (29] 30]. and thus, can effectively comprehend the developers' intents based on natural language descriptions that specify sources and sinks. Moreover, LLMs posses remarkable program synthesis capabilities that facilitate the synthesis of tools invoking external experts to tackle domain-specific problems. Inspired by these observations, attempt instantiate dataflow analysis without laborious compilation steps and intricate customization procedures by harnessing the power of LLMs and comain-sspcifii experts.
3 Method
We propose LLMDFA, a compilation-free and customizable dataflow analysis, which takes program and its CFG as input. To resolve hallucinations, we split the analysis into three phases in Figure 4
Source/Sink Extraction: For dataflow analysis application, such as DBZ detection, LLMDFA first extracts sources and sinks, which are the start and end points of dataflow facts of our interests.
Dataflow Summarization: Based on the extracted sources (e) and sinks (V sink)) of given
function f, LLMDFA identifies the dataflow facts from E V UV! U UVV.
out to v' E sink U
par
V.f. U V as summaries, which form inter-procedural dataflow paths from sources to sinks. Path feasibility Validation: For each dataflow path from sources to sinks, LLMDFA collects its path condition and validates path feasibility, eventually reporting bugs induced by feasible paths.
The rest of this section demonstrates the detailed technical designs in the three phases.
3.1 Phase Source/Sink Extraction
Extracting sources and sinks is non-trivial with LLMs. First, querying LLMs whether each line contains sources or sinks expensive. Second, the hallucinations of LLMs may induce incorrect sources and sinks. To tackle these issues, utilize LLMs synthesize script programs using parsing libraries as sources/sink extractors. By traversing the abstract syntax tree (AST) of a given program, script programs can identify sources/sinks at low cost, yielding deterministic and explainable results.
As shown in the left part of Figure g the synthesis requires a specification depicting sources/sinks, example programs Expec with sources/sinks, and their ASTs T. Given a phase description Dj, an extractor og := az is generated by the conditional probability pe after a specific number of fixes:
E po(. Dis S, Expec: T)
a g ~ pol: Di, S, Expers T, T,((1-1), 15ist
(
(2)
(1) ( g Espec) (1), 0sist
Here X(1) (i) checks whether equal to 1. ( (3) Espec) if and only the script synthesized in the i-th round identifies sources and sinks in Espec with no false positives negatives. As formulated by Equations [~<3). LLMDFA iteratively fixes a script, utilizing the execution result (denoted by (i--1) of the script synthesized in the previous round, until the newly synthesized one correctly identifies sources and sinks in the example programs. Notably, our extractor synthesis is one-time effort. The synthesized extractors can be reused when analyzing different functions. As an example, Figure 12 in Appendix A.2.3 shows an example program with sources/sinks and the synthesized sink extractor for DBZ. detection. The code highlighted in grey generated by LLMs, while the rest the skeleton provided manually. We also list prompt template in Figure 9 of Appendix A.2.2

---

3.2
Phase II: Dataflow Summarization
We realize that an inter-procedural dataflow fact is the concatenation of multiple intra-procedural dataflow facts from E V U V U V. out to v' V sink UV ret in single functions f. By identifying intra- procedural dataflow facts as function summaries, we can significantly reduce the prompt length. Besides, a summary can be induced by one or more operations with specific patterns, such as direct uses and assignments. For example, the summary r - 1 in Figure is introduced by the assignment line 12 and the direct use of the variable 2 at line 13. Offering few-shot examples with detailed explanations would expose typical patterns of dataflow facts that form function summaries, which can align LLMs with program semantics, prompting their ability dataflow summarization.
Question in prompt:
V2
x
2@
Result:
V2
x
x
2 (8tt
Figure 5: A summary discovered via CoT
Based on the insight, we introduce a few-shot CoT prompting to facilitate the dataflow summarization, which corresponds to the middle part of Figure 4 Given phase description D2 and a list of examples with explanations Efoow the response can be generated by the conditional probability:
T ~ p- D22, Eflow, U, v', P)
where v E Vf U UV U.!
are par outs o' E V UV U.!. arg Vitt and P is the program under the analysis. Based on the response r. we can determine the existence of the dataflow fact between v and v. Concretely, construct the prompt according the template shown in Figure of Appendix [A.2.2] Particularly, the examples cover the typical patterns of dataflow facts, and meanwhile, the explanations depict reasoning process in detail. Both designs pretty crucial for the few-shot CoT prompting. Lastly, we ask LLMs to reason step by step and offer an explanation along with the Yes/No answer.
sink
Consider rūly and 20h13 in Figure As shown in Figure 5 LLMDFA discovers intermediate program values, i.c., x x& and 20l12, and eventually obtains the dataflow fact x& + z@@ 13sttp by step. Hence, the strategy of few-shot CoT prompting helps LLMs to better align with program semantics, significantly reducing hallucination in reasoning dataflow facts within single functions.
3.3 Phase II: Path Feasibility Validation
Validating path feasibility is a complicated reasoning task that involves determining the satisfiability of a path condition. Although LLMs cannot achieve adequate performance in complex reasoning tasks [1), several off-the-shelf domain-specific experts, such as SMT solvers, can be utilized by LLMs. For example, the Python binding of Z3 solver [15] enables us to solve constraints in Python code. Hence, propose to synthesize Python script program that encodes and solves path conditions according to path information. Decoupling constraint solving from path condition collection can substantially mitigate the hallucination in path fcasibility validation.
The right part of figure4shone the workflow of the path feasibility validation. Based on the dataflow facts stitched from summaries, LLMDFA first leverages parser to extract the path information, such as the branches exercised by the program path and the branch conditions. Notably, the parser receives the program lines appearing in the summaries as inputs and does not need to be reimplemented for different forms of sources and sinks. Based on the derived path info I and the phase description Dz.
script program av == dy is eventually generated after specific number of fixes as follows:
a po (D3, I)
(5)
av p- ( err (+) =e, (i e,, 0 (
Ds, I, (rr(i-1)), 15ist
(6)
(7)
Particularly, we utilize the error message of executing the script synthesized in a previous round ((i 1) round), denoted by (rr()-1), and feed it to LLMs to conduct the fixing in the i-th round. Concretely, we design the prompt
from import
= Solver()
Int
s.ade(b -- 8]
template shown by Figure ID in Appendix A.2.2] It should be noted that the synthesis process has to be repeated for each source-sink pair, which different from the one-time effort paid in the extractor synthesis. Consider
(Abs(
print(s.chockk)
Figure 6: A script
2u >> b@f, Figure [
We offer the branch condition . (b)
invoking Z3 solver
and other path information in prompt and obtain a script in Figure
0 To ease the synthesis, we offer
5

---

Table 1: The performance of LLMDFA in the overall detection and the three phases when using different LLMs. P. R, and F1 indicate the precision, recall, and Fl score, respectively.
spt-3,5
spt-4
gemini- 1,0
claude-3
Bug
Phase
P ((5)
R (%)
F1
P ((6)
R (%)
F1
P ((6)
R (%)
F1
P ((5)
R (%)
F
Extract
100.00
100.00
1.00
100.00
100.00
1.00
100.00
100.00
1.00
100.00
100.00
1.00
Summarize
90.95
97.57
0.94
95.32
98.43
0.97
83.57
82.47
0.83
89.26
92.38
0.91
DBZ
Validate
81.58
99.20
0.90
89.76
100.00
0.95
79.83
93.73
0.86
85.74
94.52
0.90
Detection
73.75
92.16
0.82
81.38
95.75
0.87
66.57
74.21
0.70
76.91
82.67
0.80
Extract
1O0:00
100.00
1.00
100:00
100.00
100:00
100.00
100.00
100.00
1.00
Summarize
86.52
96.25
0.91
97.84
99.76
0.99
88.79
97.31
0.93
94.17
97.83
0.96
XSS
Validate
100.00
100.00
1,00
100.00
98,91
0,99
100.00
99.07
1,00
100.00
95,29
0,98
Detection
100.00
92.31
0.96
100.0
98.64
0.99
100.00
94.60
0.97
100.0
86,49
0.93
Extract
100.00
100.00
1,00
100.00
100.00
1,00
100.00
100.00
1,00
100.00
100.00
1.00
OSCI
Summarize
89.57
85.76
0,88
94.58
93. 12
0.94
87.21
96.54
0.92
98.26
97.87
0.98
Validate
100.00
97.14
0.99
100.00
100.00
1.00
100.00
98.
0.99
100.00
100.00
1.00
Detection
100.00
78.38
0.88
100.00
89.19
0.94
100.00
94.59
0.97
100.00
97.30
0.99
lines 1, 2, and 6 in skeleton. We refine the script most three times. If the script buggy after three trials, LLMDFA enforces LLMs to determine path feasibility based on the path information.
4 Evaluation
We implement LLMDFA as a prototype analyzing Java programs. Utilizing the parsing library tree-sitter [1] LLMDFA obtains the parameters, return values, callers/callees, and sources/sinks. We configure LLMDFA LLMDFA with four LLMs across various architectures, namely gpt-3. 1--..3.5tuu Si-turbo-011 spt-4-turbo-prreviee
gemini-1 0-pro, and claude-3-ops 3-ouus. We proceeded evaluate the performance of L.LDFA through extensive experiments, with the total cost amounting to 1622.02 USD. In the rest of the paper, without ambiguity. To reduce the randomness, we set the temperature to 0 so that LLMDFA performs greedy decoding without any sampling strategy.
gpt-3.5, gpt-4, gemini-1.0 O, and claude-3 for short
4.1 Dataset
Synthetic Benchmark, Juliet Test Suite 117 is a benchmark widely used to evaluate static analyzers. Considering the high impact and representativeness, we choose divide-by-zero (DBZ), cross-site- scripting (XSS), and OS Command Injection (OSCI) for evaluation. As illustrated in Section 2 the dataflow facts inducing DBZ bugs are more restrictive than the ones inducing XSS bugs, as the values in the former should be equal instead of just being dependent. The OSCI bugs share the same forms of dataflow facts as XSS bugs, while their sources and sinks have different forms. Indicated by comments, there are 1,850 DBZ, 666 XSS, and 444 OSCI bugs in total. To avoid the leakage of ground truth, we remove comments and obfuscate code before the evaluation.
Real-World Programs. We choose TaintBench Suite [19), which consists of 39 real-world Android malware applications. Due the reliance on Gradle in an old version, we cannot compile the applications in our environment. Besides, each application is equipped with specific sources and sinks that are customized to its unique functionality. For instance, if the argument of the function startService depends on the return value of the function meeDDiplayOrrgiiatinnAuuu in the leakage of user address information. The highly customized sources and sinks require us to tailor dataflow analysis for each application. Therefore, TaintBench serves as ideal subjects for evaluating LLMDFA compilation- ffreeeooo-feeeeeeo and customizable scenario.
it may result
4.2 Performance of LLMDFA
Setup and Metrics. We evaluate LLMDFA upon Juliet Test Suite to measure its precision, recall, and Fl score. Apart from the overall detection, we also measure the performance of each phase to quantify its effectiveness. Specifically, we diff the sources/sinks labeled in the benchmark and the identified ones to measure the performance of source/sink extraction. Besides, we measure the precision and recall of dataflow summarization by manually examining the value pairs investigated by LLMDFA. Lastly, we manually examine generated path conditions and compute the precision and recall of identifying feasible paths. Due to the lack of explicit ground truth in the benchmark, would

---

LLMDFA
CodeFosQuary
Pinpoint
End-te-End
1.00
1.00
1.00
Procision
11 seore
Recail
0.25
0.25
0.25
0.00
0.02
0.00
(4) Precision
(b) Recall
(c) score
Figure 7: The comparison of LLMDFA, CodeFuseQuery, Pinpoint, and LLM-based end-to-end analysis. LLMDFA and LLM-based end-to-end analysis are powered with gpt-3.5
have to make laborious efforts to examine thousands of program paths. To simplify examination, we choose 37 programs for each bug type measure the performance of the last two phases, other programs only differ from the selected ones in terms of sources and sinks.
Result. As shown in Table 1 LLMDFA achieves high performance in each phase and the over- all detection when it is powered with different LLMs. Equipped with gpt-3, 5, for example, achieves the precision of 73. 33.75% 11/3%///0000000// the recall of 92.16% /1/78733% and the F1 score of 0.82/0.96/0.88. in the DBZ/XSS/OSCI detection. Besides, LLMDFA synthesizes all the source/sink extractors successfully for the three bug types. In the DBZ/XSS/OSCI detection, the dataflow summarization achieves 90.95% 9355/8 /8.55 precision and 97.57% 25%/85.7665 recall, and meanwhile, the path feasibility validation achieves 105.///1..000/100........... recall. When utilizing other LLMs, LLMDFA achieves the precision
precision and
99.20% 2200%/1000000 1100.00%%99 and recall comparable those obtained using 3 While the precision of the DBZ detection powered by gemini- -1. 1.0 is slightly lower at 66.57% than other LLMs, the performance remains satisfactory, exhibiting superiority sizes the extractors and script programs encoding path conditions with only few iterations, which is demonstrated in Appendix A.3.1 and A.3.2 Lastly, it found that the average financial costs of the DBZ, XSS, and OSCI detection are 0.14 USD, 0,05 USD, and 0.04 USD, respectively. Such a cost is in line with works of a similar nature, such as 32 which takes 0.42 USD repair bug. Notably, the extractor synthesis is one- one-time for given bug type. Hence, the financial cost of the detection in practice is even lower. Overall, the statistics show the generality, effectiveness, and efficiency of LLMDFA in detecting dataflow-related bugs.
the baselines in Section 4.3 LLMDFA successfully synthe-
4.3 Comparison with Baselines
Classical Dataflow Analysis. We choose two industrial static analyzers, namely CodeFuseQuery [8 and Pinpoint 44, for comparison. Specifically, CodeFuseQuery does not depend on any compilation process and derives dataflow facts from the ASTs of programs, while Pinpoint requires the compilation and takes as input the LLVM IR generated by a compiler. As shown by Figure 7 CodeFuseQuery achieves 29.41% 06//922666/877777 46% precision, 81.08% /96//99.6777/ /7..6.%./....5 recall, and score in detecting the DBZ/XSS/OSCI bugs. The low precision the DBZ detection is attributed to its path-insensitive analysis. The low recall of CodeFuseQuery caused by the lack of the support of analyzing complex program constructs. For example, the inability to analyze global variables causes missing dataflow facts, which causes more false negatives.
Fl
Besides, Pinpoint obtains 93. 00%6/100.00%/ 100%%100.000 100.00% precision, 63. 11.119%%779499 4444449///111 .35% recall, and 0. 0.76/0.64/0.48 F1 score in the detection of DBZ/XSS/OSCI bugs. Due to the lack of comprehensive modeling and customized support for source and sink, Pinpoint misses a large number of buggy dataflow paths, which eventually result in low recall. Although it achieves high precision of 93. 78% in DBZ detection, LLMDFA demonstrates superior capabilities in detecting DBZ bugs, delivering not only satisfactory precision but also significantly higher recall and Fl scores.
LLM-based End-to-End Analysis. We adopt few-shot CoT prompting detect the DBZ, XSS. and OSCI bugs. Specifically, we construct few-shot examples cover all the forms of sources and sinks, and meanwhile, explain the origin of bug step by step. Figure ( shows the performance comparison when using gpt-3. 5. LLMDFA exhibits superiority over M---baseed end-to-end analysis in detecting three kinds of bugs. Although the recall of L.LMDFA slightly lower than the baseline in the OSCI detection, the precision of the former is much higher than the latter. We obtain the same findings
7

---

precision
precision
precision .00
1.00
1 1.00
0.75
LLMDFA
0.80
50
0.50
0:25
0:25
0.25
NoSynExt
0.,00
0.
0:00
NoCoT
score
recall
F1 score
recall
F1 score
recall
NoSynVal
(4) DBZ
XSS
(c) OSCI
Figure 8: The comparison of LLMDDFA and ablations using gpt-3.5
from the results of the analysis powered by the other three LLMs, which are shown by Figure [4] in Appendix [A.3.]] In Appendix [A.4.1] we offer typical cases where the LLM-baser end-to-end analysis identifies wrong dataflow lacts due to hallucinations.
4.4 Ablation Studies
Setup and Metries. We introduce three ablations, namely NoSynExt, NoCoT, and NoSyn and measure their performance in detecting the DBZ, XSS, and OSCI bugs. Specifically, NoSynExt directly leverages LLMs to extract sources and sinks. NoCoT provides the descriptions of dataflow facts in prompts and summarizes dataflow facts without few-shot CoT prompting.Non NooSn Val validates path feasibility with LLMs directly without synthesizing programs invoking SMT solvers.
Result. Figure S shows the comparison results of the ablations using gpt-3.5. First, LLMDFA has an overwhelming superiority over NoSynExt and NoCoT. Although NoCoT achieves 86.8% precision while LLMDFA obtains 73.7% precision in the DBZ detection, LLMDFA has much larger recall and Fl score than NoCoT. The key reason is that NoCoT is unable to identify complex dataflow facts, which causes the low recall NoCoT. Second, NoSynExt introduces false positives in many cases because of the low precision of source/sink extraction in both the DBZ, XSS, and OSCI detection. Third, it should be noted that LLMDFA does not show significant superiority over No in the XSS and OSCI detection because the corresponding benchmark programs do not contain any XSS or OSCI bug-inducing infeasible paths. Also, LLMDFA may encode the path condition incorrectly and accept the infeasible path, eventually causing false positives. As shown by Figure 15 in Appendix A.3.4. We can obtain similar findings when using other three LLMs. Although the precisions vary among different L.MSs and bug types, LLMDFA is always superior to the ablations, demonstrating its effectiveness in mitigating the hallucinations in LLM-powered dataflow analysis. We also offer several examples of mitigated hallucinations Appendix A.4.1
4.5 Evaluation upon Real-world Programs
Table Table shows the basic statistics of TantBench Suite 19] Particularly, there are 53 different forms of source-sink pairs in total and an application contain 7.9 different forms of source-sink pairs on average. The diversity of source-sink pairs necessitates the customization of dataflow analysis. Considering the resource cost of invoking LLMs and the manual cost of comparing detection results with the ground truth, we run LLMDFA with gpt-3. for randomly selected source/sink pairs, which constitute 80 out of the 203 dataflow paths in the ground truth. As shown in Table 3 LLMDFA achieves the precision of 75.38% and the recall 61. 61.25%. The false positives and negatives are mainly caused by the hallucinations in the dataflow summarization. Listing [ in Appendix A.4.3 shows a false negative example when LLMDFA fails to detect the dataflow path from the return value of the function query to the argument of the function write. Specifically, LLMDFA fails capture the summary of processResults, which contains complex program structures, such as a try-catch block and while statement, ultimately resulting in the failure to report the intended dataflow path. We also present a false positive example by Listing Appendix A.4.3
We also compare LLMDFA with the end-to-end analysis and CodeFuseQuery. Specifically, we adopt a few-shot CoT prompting strategy to conduct the end-to-end analysis and customize CodeFusseuery by designing specific queries to capture dataflow paths accordingly. As shown by Table 3 the end-to-end analysis only achieves a precision of 43.48% and recall of 25.00%. The precision and recall are primarily affected by the incorrect identification of sources and sinks. When dealing

---

Table 2: The statistics of TaintBench, including the total number of program lines, functions, and source-sink pairs, along with the maximal and average number per application.
Table 3: The performance results upon Taint- Bench. AI~A3 are LLMDFA with gpt-3.5, 5, end-to-end analysis with gpt-3.5, 5, and Code- FuseQuery, respectively.
Metric
Total
Max
Avg
Analysis
Precision
Recall
F1 Score
Program Line
1,376,214
260,797
35,287.03
A1 75.38%
61.25%
0.67
Function
155,364
23,414
3,983.69
A2 43.48%
25.00%
0.32
Source-sink Pair
53
17
7.9
A3
72.92%
43.75%
0.55
Table The performance of LLMDFA upon Juliet Test Suite of
Table 5: The performance of LLMDFA upon the real-world benchmark SecBench.js
C/C++ version
Bug Type
Precision
Recace
Score
Precision
Recace
F1 Score
Command Injection
94.44
67.33%
DBZ
85.71%
83.94%
84.77%
Tainted Path
50.00%
100.00%
0.67
APT
100.00%
86.83%
92.92%
Code Injection
90.91%
83.33%
0.87
OSCI
97.36%
73.68%
83.98%
Overall 92.52%
71.74%
0.81
with large programs, lengthy prompt can amplify the occurrence of false positives/negativss in identifying sources/sinks and discovering dataflow facts between them. While CodeFuseQuery achieves comparable precision to LLMDFA reaching 72.92%, its recall is significantly lower at only 43.75% compared to LLMDFA. Its low recall is mainly attributed to its limited ability to analyze complex program constructs such as global variables and arrays. This observation is consistent with the evaluation results obtained upon Juliet Test Suite. We do not evaluate the campilation-deeendeee analyzer Pinpoint because the subjects in TaintBench cannot be compiled successfully due to an outdated version of Gradle. Overall, the above statistics provide sufficient evidence of the potential of LLLDFF in customizing dataflow analysis for real-world projects without compilation.
4.6 Multi-linguistic Support
Although the multi-linguistic support is not our main contribution, is easy to extend LLMDFA to support other languages due to its compilation-free design. Based on dataflow analysis theory, we only need to construct the control flow graph with corresponding tree-sitter packages and then reuse the current implementation. In our evaluation, we further migrate Java analysis to support C/C++/lavaScriitt and evaluate it with gpt-3.5 upon the Juliet Test Suite for C/C++ and a real-world JavaScript benchmark SecBench.js (33). The Juliet Test Suite for C/C++ does not contain XSS bugs. Hence, we chose another bug type, namely Absolute Path Traversal (APT), which a typical security vulnerability. As shown in Table the performance of LLMDFA on C/C++ is equally good as on Java. SecBench.js includes 138 vulnerabilitics in JavaScript packages, covering command injection, taint path, and code injection vulnerabilities, which have been assigned with CVE IDs due to significant security impact. Table shows that our compilation- -ffeee analysis upon SecBench.js js Showw
achieves 92.54% precision and 71.74% recall, which are comparable with the compilation-dependert approach in [33]. Notably, the migration only requires the modification of no more than 100 lines of code and mostly relates to the changes to AST node types and parser initialization.
4.7 Limitations and Future Works
First, the prompts can be lengthy in the few-shot CoT prompting, which can result in significant token cost. Frequent prompting can also increase time overhead. Hence, LLMDFA better suited for analyzing specific program modules than the entire program. To make whole program analysis practical, we may need accelerate the inference or parallelize LLMDFA. Second, datallow summa- rization can be imprecise in the presence of large functions or sophisticated pointer operations, further leading to incorrect results in identifying dataflow facts across functions. A potential improvement to fine-tune existing LLMs with the dataflow facts produced by classical dataflow analyzers. Third, LLMDFA may not accurately encode path conditions and potentially compromise the soundness. Ap- pendix A.4.2 presents several cases where L.LMFAA encodes path conditions wrongly. It is possible to investigate several patterns of path conditions and synthesize script programs to over-aprroximate them, which could discard infeasible paths while retaining high recall simultancously.

---

Related Work
Dataflow Analysis. Current dataflow analysis predominantly relies on IR code generated by semantic analysis during the compilation, such as LLVM IR [5] and Soot IR [34). Typically, SVF [24] and Klee [35] analyze C/C++ programs based on LLVM IR code. Industrial analyzers like Infer 36 and
Semmle [3 also require successful builds to obtain necessary IR code for analysis. Consequently, the reliance on compilation infrastructures restricts the applicability when target programs cannot be compiled. Besides, existing techniques abstract semanties with formal structures, such as graphs []] and logical formulas [37], to compute dataflow facts of interests. However, semantic abstraction differs greatly depending analysis demands, such the choices of sources/sinks and the precision setting of the analysis. Hence, the customization of dataflow analysis requires laborious manual effort and expert knowledge, which hinders its widespread adoption in real-world scenarios (6].
Machine Learning-based Program Analysis. The first line of studies derives program proper- ties, such as library specifications [8 39 and program invariants (40 41), to augment classical analyzers. For instance. USpec utilizes large codebases to predict aliasing relation 38]
SuSi em-
ploys classification models to infer the sources and sinks of sensitive information 33 While these techniques offer analyzers insightful guidance, they do not have any correctness guarantees due to their inherent limitations. The second line of works targets data-driven bug detection with training models [25] 42 43). Typically, [25] jointly trains an embedding model and classification model upon large training dateset. Unlike LLMDFA, it cannot answer general dataflow queries upon two specific program values. Similarly, Hoppity detects JavaScript bugs with the model trained upon a large volume of buggy code [43] The reliance training data make these techniques difficult to customize for specific analysis demands in the presence a sufficient amount of training data.
LLMs for Program Analysis. The emergence of LLMs has created exciting opportunities for various analysis tasks, including code completion 44 repair (9] 45), and comprehension 446 Considerable research targets the reasoning abilities of LLMs through techniques such as CoT 16]
ToT 47 and accumulative reasoning [4]. However, only few studies foeus on domain-specifer reasoning for programs. Typically, several studies employ the CoT prompting to infer program invariants [0. 48 and rank potential invariants [49]. Also, LLift retrieves function specifications through prompting 50 to assist classical bug detectors. As far
know, no previous studies have solely relied on LLMs for program analysis. Our work formulates chain-like structures in dataflow facts and the demonstrates the possibility of synthesizing new tools avoid hallucinations in program analysis. Our insight into mitigating hallucinations can be generalized to other software engineering problems, such as program repair [45] and program synthesis [51 52
6 Conclusion
This paper presents LLMDFA, a LLM-powered compilation-free and customizable dataflow analysis. To mitigate the hallucinations, decomposes the whole analysis into three manageable sub-problems and solves them with series of strategies, including tool synthesis, few-shot CoT prompting, and formal method-base validation. Our evaluation shows the remarkable performance of LLMDFA in analyzing both synthetic and real-world programs. Our work demonstrates a promising paradigm for reasoning code semantics, with the potential for generalization to other code-related tasks.
Acknowledgement
We grateful to the Center for AI Safety for providing computational resources. This work was funded in part by the National Science Foundation (NSF) Awards 1HF-1901242, 19I000,,300, Proto-OKN 2333736. 116-2416835, DARPA VSPELLS HR001 1 120S0058, IARPA TrojAI W91 19-S0012, ONR N0001417 12045, N000141410466 and N000141712944 Any opinions, findings and conclusions recommendations expressed in this material those of the authors and do not necessarily reflect the views of the sponsors.
10

---

References
[1] Thomas W. Reps, Susan Horwitz, and Shmuel Sagiv. Precise interprocedural dataflow analysis via graph reachability. Ron K. Cytron and Peter Lee, editors. Conference Record of POPL'95: 22nd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, San Francisco, California, USA, January 23-25, 1995, pages 19-61. ACM Press, 1995.
[2] Zhiyuan Li, Pen-Chung Chung Yew, and Chuan- Qi Zhu, An efficient data dependence analysis for parallelizing compilers. IEEE Trans. Parallel Distributed Syst., 1(1):26 34, 1990.
[3] Steven Arzt. Siegfried Rasthofer, Christian Fritz, Eric Bodden, Alexandre Bartel, Jacques Klein, Yves Le Traon. Damien Octeau, and Patrick D. McDaniel. Flowdroid: precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps. In Michael F. P. O' O'Boyle and Keshav Pingali, editors, ACM SIGPLAN Conference on Programming Language Design and Implementation, PLDI '14, Edinburgh, United Kingdom June 09 11, 2014, pages 259 269. ACM, 2014.
[4] Qingkai Shi, Xiao Xiao, Rongxin Wu, Jinguo Zhou, Gang Fan, and Charles Zhang. Pinpoint: fast and precise sparse value flow analysis for million lines of code. In Jeftrey S. Foster and Dan Grossman, editors, Proceedings of the 39th ACM SIGPIAN Conference on Programming Language Design and Implementation, PLDI 2018, Philadelphia, PA, USA, June 18-22, 2018, pages 693-706. ACM, 2018.
[5] Chris Lattner and Vikram S. Adve. LLVM: A compilation framework for lifelong program analysis & transformation. In 2nd IEEE/ ACM International Symposium on Code Generation and Optimization (CGO 2004), 20-24 March 2004, San Jose, CA, USA, pages 75-88. IEEE Computer Society, 2004.
[6] Maria Christakis and Christian Bird. What developers want and need from program analysis: empirical study. In David Lo, Sven Apel, and Sarfraz Khurshid, editors, Proceedings of the 31st IEEF//CM International Conference on Automated Software Engineering, ASE 2016, Singapore, September 3-7, 2016, pages 332-343. ACM, 2016.
[7] Disha Shrivastava, Hugo Larochelle, and Daniel Tarlow. Repository prompt generation for large language models of code. In Andreas Krause, Emma Brunskill, Kyunghyun Cho. Barbara Engelhardt, Sivan Sabato, and Jonathan Scarlett, editors, International Conference on Machine Learning, ICML 2023, 23.29 July 2023, Honoludu, Hawaii, USA, volume 202 of Proceedings of Machine Learning Research, pages 31693 111933317155 31715. PMLR, 2023.
[8] Yinlin Deng. Chunqiu Steven Xia, Haoran Peng, Chenyuan Yang, and Lingming Zhang. Large language models zero-shot fuzzers: Fuzzing deep-learnin librarics via large language models. In René Just and Gordon Fraser, editors, Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis, ISSTA 2023, Seattle WA, USA, July 17-21, 2023, pages 423-435. ACM, 2023.
[9] Yuxiang Wei, Chunqiu Steven Xia, and Lingming Zhang. Copiloting the copilots: Fusing large language models with completion engines for automated program repair. In Satish Chandra, Kelly Blincoe, and Paolo Tonella, editors, Proceedings of the s1 ACM Joint European Software Engineering Conference and Symposium the Foundations of Software Engineering, ESEC/FSE 2023, San Francisco, CA, USA, December 3-9, 2023, pages 172-184. ACM, 2023.
[10] Kexin Pei, David Bieber, Kensen Shi, Charles Sutton, and Pengcheng Yin. Can large language models reason about program invariants? In Andreas Krause, Emma Brunskill, Kyunghyun Cho, Barbara Engelhardt, Sivan Sabato, and Jonathan Scarlett, editors, International Conference on Machine Learning, ICML 2023, 23-29 July 2023, Honolulu, Hawaii, USA, volume 202 of Proceedings of Machine Learning Research, pages 27496 27520. PMLR, 2023.
[11] Yue Zhang, Yafu Li. Leyang Cui. Deng Cai, Lemao Liu, Tingchen Fu, Xinting Huang, Enbo Zhao, Yu Zhang, Yulong Chen, Longyue Wang, Anh Tuan Luu, Wei Bi, Freda Shi, and Shuming Shi. Siren's song in the Al occan: A survey on hallucination in large language models. CoRR, abs/2309.01219, 2023.
[12] Ziwei Ji, Tiezheng Yu. Yan Xu, Nayeon Lee, Etsuko Ishii, and Pascale Fung. Towards mitigating LLM hallucination via self retlection. In Houda Bouamor, Juan Pino. and Kalika Bali, editors, Findings of the Association for Computational Linguistics: EMNLP 2023, Singapore, December 6-10, 2023, pages 1827-1843. Association for Computational Linguisticss 2023.
[13] Niels Mündler, Jingxuan He, Slobodan Jenko, and Martin T. Vechev. Self-contradictrry hallucinations of large language models: Evaluation, detection and mitigation. CoRR, abs/2305. 15852, 2023.
[14] Yifan Zhang, Jinggin Yang. Yang Yuan, and Andrew Chi-Chih Yao. Cumulative reasoning with large language models. CoRR, abs/2308.044 003000 2023.

---

[15] Leonardo Mendonça de Moura and Nikolaj Bjorner. Z3: an efficient SMT solver. In C. R. Ramakrishnan and Jakob Rehof, editors, Tools and Algorithmss for the Construction and Analysis of Systems. 14th International Conference, TACAS 2008, Held as Part of the Joint European Conferences on Theory and Practice of Software, ETAPS 2008, Budapest, Hungary, March 29-April 6, 2008, Proceedings, volume 4963 of Lecture Notes in Computer Science, pages -37-340. Springer, 2008
[16] Jason Wei, Xuezhi Wang. Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed H. Chi, Quoe V. Le, and Denny Zhou. Chain-of-thought prompting elicits reasoning in large language models. In NeurlPS, 2022.
[17] Tim Boland and Paul E. Black. Juliet 1.1 C/C++ and java test suite. Computer, 45(10):88 90, 2012.
[18] Xiaoheng Xie, Gang Fan, Xiaojun Lin, Ang Zhou, Shijie Li, Xunjin Zheng, Yinan Liang. Yu Zhang. Na Yu, Haokun Li, Xinyu Chen, Yingzhuang Chen, Yi Zhen, Dejun Dong, Xianjin Fu, Jinzhou Su, Fuxiong Pan, Pengshuai Luo, Youzheng Feng, Ruoxiang Hu, Jing Fan, Jinguo Zhou, Xiao Xiao, and Peng Di. Codefuse- query; data-centric static code analysis system for large-scale organizations. CoRR, abs/2401.01571, 2024.
[19] Linghui Luo, Felix Pauck, Goran Piskachev, Manuel Benz, Ivan Pashchenko, Martin Mory, Eric Bodden, Ben Hermann, and Fabio Massacci. Tainthench: Automatic real-world malware benchmarking of android taint analyses. Empir Softw. Eng. 27(1); 2022.
[20] Christian Janßen, Cedric Richter, and Heike Wehrheim. Can chatgpt support software verification? CoRR, abs/2311 100433,, 2023.
[21] CWE. CWE-80; Improper Neutralization of Relapt-Related HTML Tags in a Web Page (Basic XSS). https://cwe.. mwtre.iteeeemmmmmmm.mmm http://taaadefffiiiinno html 2023. [Online; accessed 23- 2023).
[22]
CWE. CWE-369; Divide By Zero. https::/ mit.e..ee.itr...... htt.://aww......ata/////atattt/a html 2023. [Online; accessed 23 Dec-2023).
[23] Semmle. GitHub Code Scanning. https:///gtm... com 2023, [Online; accessed
[24] Yulei Sui and Jingling Xue. SVF: interprocedural static value-flow analysis in LLVM. In Ayal Zaks and Manuel V. Hermenegildo, editors, Proceedings of the 25th International Conference on Compiler Construction, CC 2016, Barcelona, Spain, Murch 12-18, 2016, pages 265-266, ACM, 2016.
[25] Benjamin Steenhoek, Hongyang Gao, and Wei Le. Dataflow amalysis-inspired deep learning for efficient vulnerability detection. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering, ICSE 2024, Lisbon, Portugal, April 14-20, 2024, pages 16:1 16:13, ACM, 2024.
[26] David Hin, Andrey Kan, Huaming Chen, and Muhammad Ali Babar. Linevd: Statement-level vulnerability detection using graph neural networks. In 19th IEEE/ACM International Conference on Mining Software Repositories, MSR 2022, Pittsburgh, PA, USA, May 23-24, 2022, pages 596 607. ACM, 2022.
[27] Baptiste Rozière, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi Jingyu Liu, Remez, Jérémy Rapin, Artyom Kozhevnikov, Ivan Evtimov. Joanna Bitton, Manish Bhatt, Cristian Canton-Ferrer, Aaron Grattafiori, Wenhan Xiong, Alexandre Défossez, Jade Copet, Faisal Azhar, Hugo Touvron, Louis Martin, Nicolas Usunier, Thomas Scialom, and Gabriel Synnaeve. Code llama: Open foundation models for codc. CORR, abs/2308. 12950, 2023.
[28] Yue Wang, Weishi Wang. Shafig R. Joty, and Steven C. H. Hoi. Codet5: Identifier-awail aware unified pre- pe-trained encoder-decoder models for code understanding and generation. In Maric-Francin Moens, Xuanjing Huang, Lucia Specia, and Scott Wen-tau Yih, editors, Proceedings of the 2021 Conference Empirical Methods in Natural Language Processing, EMNLP 2021, Virtual Event / Punta Cana, Dominican Republic, 7-11 November, 2021, pages 8696-8708. Association for Computational Linguistics, 2021.
[29] Tom B. Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, Prafulla Dhariwal, Arvind Ncelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, Sandhini Agarwal, Ariel Herbert-Voss Gretchen Krueger, Tom Henighan, Rewon Child, Aditya Ramesh, Daniel M. Ziegler, Jeffrey Wu, Clemens Winter, Christopher Hesse, Mark Chen, Eric Sigler. Mateusz Litwin, Scott Gray. Benjamin Chess, Jack Clark, Christopher Berner, Sam McCandlish, Alec Radford. Ilya Sutskever. and Dario Amodei. Language models are few-shot learners. In Hugo Larochelle, Marc' Aurelio Ranzato, Raia Hadsell, Maria-Florins Balcan, and Hsuan-Tien Lin, editors, Advances in Neural Information Processing Systems 33: Annual Conference on Neural Information Processing Systems 2020, NeurIPS 2020, December 6-12. 2020, virtual, 2020.
[30] OpenAL. GPT-4 technical report. CoRR, 0as/2233.0087744 2023.
12

---

[31] Max Brunsfeld. Tree-siteera new parsing system for programming tools. In Strange Loop Conference. Accessed- URL: https://ww.. thestrangelopp. tools. himl, 2018.
[32] Chunqiu Steven Xia and Lingming Zhang. Keep the conversation going: Fixing 162 out of 337 bugs for $0.42 each using chatgpt. CoRR, abs/2304.00385, 2023.
[33] Yiu Wai Chow, Max Schäfer, and Michael Pradel. Beware of the unexpected: Bimodal taint analysis. In René Just and Gordon Fraser, editors, Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis, ISSTA 2023, Seattle, WA, USA, July 17-21, 2023, pages 211 211-222. ACM, 2023.
[34] Raja Vallée-Rai, Phong Co, Etienne Gagnon, Laurie J. Hendren, Patrick Lam, and Vijay Sundaresan. Soot java bytecode optimization framework. In Stephen A. MacKay and J. Howard Johnson, editors, Proceedings of the 1999 conference of the Centre for Advanced Studies on Collaborative Research, November 1-1 1999, Mississauga, Ontario, Canada, page 13. IBM, 1999.
[35] Cristian Cadar, Daniel Dunhar, and Dawson R. Engler. KLEE; unassisted and automatic generation of high-ooverage tests for complex systems programs. In Richard Draves and Robbert van Renesse, editors, 8th USENIX Symposium Operating Systems Design and Implementation, OSDI 2008, December 8-10, 2008, San Diego, California, USA, Proceedings, pages 209-224. USENIX Association, 2008
[36] Cristiano Calcagno, Dino Distefano, Peter W. O'Hearn and Hongseok Yang. Compositional shape analysis by means of bi-abduction. In Zhong Shao and Benjamin C. Pierce, editors, Proceedings of the 36th ACM SIGPLAN-SIGACE Symposium on Principles of Programming Languages, POPL 2009, Savannah, CA, USA, January 21 21-23, 2009, pages 289-3001000 300. ACM, 2009.
[37] Peisen Yao, Qingkai Shi, Heqing Huang, and Charles Zhang. Program analysis via efficient symbolic abstraction. Proc. ACM Program. Lang,, 5(00PSLA): 2021.
[38] Jan Eberhardt, Samuel Steffen, Veselin Raychev, and Martin T. Vechev. Unsupervised learning of API alias specifications. In Kathryn S. McKinley and Kathleen Fisher, editors, Proceedings of the 40th ACM SIGPLAN Conference on Programming Language Design and Implementation, PLDII 2019, Phoenix, AZ, USA, June 22-26, 2019, pages 745-759. ACM, 2019.
[39] Siegfried Rasthofer, Steven Arzt, and Eric Bodden. A machine bechine-learning approach for classifying and categorizing android sources and sinks. In 2 Amnual Network and Distributed System Security Symposium, ND$S 2014, San Diego, California, USA, February 23-26, 2014. The Internet Society, 2014.
[40] Michael D. Ernst, Jeff H. Perkins, Philip J. Guo, Stephen McCamant, Carlos Pacheco, Matthew S. Tschantz. and Chen Xiao. The Daikon system for dynamic detection of likely invariants. Science of Computer Programming, 69(1-3):55-45, December 2007.
[41] Xujie Si, Hanjun Dai, Mukund Raghothaman, Mayur Naik, and Le Song. Learning loop invariants for program verification. In Samy Bengio, Hanna Wallach, Hugo Larochelle, Kristen Grauman. Nicolò and Roman Garnett, editors, Advances in Neural Information Processing Systems 31: Annual Conference on Neural Information Processing Systems 2018, NewrlPS 2018, December 3-8, 2018, Montréal, Canada, pages 7762-7773, 2018
[42] Hazim Hanif and Sergio Maffeis. Vulberta: Simplified source code pre-training for vulnerability detection. In International Joint Conference on Neural Networks, IJCNN 2022, Pudua, Itlly July 18-23, 2022, pages 1-8. IEEE, 2022.
[43] Elizabeth Dinella, Hanjun Dai, Ziyang Li. Mayur Naik. Le Song, and Ke Wang. Hoppity: Learning graph transformations to detect and fix bugs in programs. In 8th International Conference Learning Representations. ICLR 2020, Addis Ababa, Ethiopia, April 26-30, 2020. OpenReview.net, 2020.
[44] Fengji Zhang, Bei Chen, Yue Zhang, Jacky Keung, Jin Liu, Daoguang Zan, Yi Mao, Mian-Gaang Lou, and Weizhu Chen. Repocoder: Repository-Ieve code completion through iterative retrieval and generation. In Houda Bouamor, Juan Pino, and Kalika Bali, editors. Proceedings of the 2023 Conference Empirical Methods in Natural Language Processing, EMNLP 2023, Singapore, December 6-10, 2023, pages 2471- 1- 2484. Association for Computational Linguistics, 2023.
[45] Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. Swe-bench: Can language models resolve real-world github issues? CoRR, abs/2310.067700 2023.
13

---

[46] Chong Wang. Yiling Lou, Junwei Liu, and Xin Peng. Generating variable explanations via zero-shot prompt learning. In 38th IEEE/ACM International Conference Automated Software Engineering, ASE 2023, Luxembourg, September 11-15, 2023, pages 748-760. IEEE, 2023.
[47] Shunyu Yao, Dian Yu, Jeffney Zhao, Izhak Shafran, Thomas L. Griffiths, Yuan Cao, and Karthik Narasimhan. Tree of thoughts: Deliberate problem solving with large language models. CoRR. abs/2305.1066 2023,
[48]
Adharsh Kamath, Aditya Senthilnathan, Saikat Chakraborty, Pantazis Deligiannis, Shuvendu K. Lahiri, Akash Lal, Aseem Rastogi, Subhajit Roy, and Rahul Sharma. Finding inductive loop invariants using large language models. CoRR, abs/231 0ts//311.079444 1.09948, 2023.
[49] Saikat Chakraborty, Shuvendu Lahiri, Sarah Fakhoury, Akash Lal, Madanial Musuvathi, Aseem Rastogi. Aditya Senthilnathan, Rahul Sharma, and Nikhil Swamy. Ranking llm-generated loop invariants for program verification. In Houda Bouamor, Juan Pino, and Kalika Bali, editors, Findings of the Association for Computational Linguistics: EMNLP 2023, Singapore, December 6-10, 2023, pages 9164 9175. Association for Computational Linguistics, 2023.
[50] Haonan Li, Yu Hao, Yizhuo Zhai, and Zhiyun Qian. The hitchhiker's guide to program analysis: A journyy with large language models. CoRR, abs/2308. 2023.
[51] Tianyi Chen, Qidi Wang, Zhen Dong, Liwei Shen, and Xin Peng. Enhancing robot program synthesis through environmental context. Alice Oh, Tristan Naumann, Amir Globerson, Kate Saenko, Moritz Hardt, and Sergey Levine, editors, Advances Neural Information Processing Systems 36: Annual Conference on Neural Information Processing Systems 2023, NeurIPS 2023, New Orleans, LA, USA, December 10 16, 2023, 2023.
[52] Xi Ye, Qiaochu Chen, Isil Dillig, and Greg Durrett. Optimal neural program synthesis from multimodal specifications. In Marie-Francine Moens, Xuanjing Huang, Lucia Specia, and Scott Wen-tau Yih, editors, Findings of the Association for Computational Linguistics: EMNLP 2021, Virtual Event / Punta Cana, Dominican Republic, 16-20 November, 2021, pages 1691-1704. Association Computational Linguistics. 2021.
[53] Clang. Clang: C language family frontend for LLVM. https://clang 11vm. org/ 2023. [Online; accessed 23-Dec-2023).
[54] Anders Møller and Michael Schwartzbach. Static program analysis. Notes. Feb, 2012.
[55]
Lars Ole Andersen. Program analysis and specialization for the programming language. 1994.
[56] Bjarne Steensgaard. Points-to analysis in almost linear time. In Hans-Juergen Bochm and Guy L.. Steele Jr., editors, Conference Record of POPI. (9: The 23rd ACM SIGPLAN-SIGACT Symposium Principles of Programming Languages, Pupers Presented at the Symposium, St. Petersburg Beach, Florida, USA, January 21-24, 1996, pages 32-41, ACM Press, 1996.
14

---

A Appendix
A.1 Broader Impact
This paper presents work whose goal is to advance the field of machine learning, targeting com- plicated code-reasoning task, namely dataflow analysis. We have demonstrated the limitations of our work above. We do not expect our work to have a negative broader impact, though leveraging LLMs for code-reasoning tasks may come with certain risks, e.g.. the leakage of source code in private organizations and potential high token costs. Meanwhile, it is worth more discussions to highlight that our work has the potential to dramatically change the field of software engineering with the power of LLMs. Specifically, LLM-pooered dataflow analysis not only enables the analysis of incomplete programs with little customization but addresses other challenges in classical dataflow analysis.
First, classical dataflow analyzers mainly depend on specific versions of IRs. As a compilation infrastructure evolves, the version of the IR code can change, requiring the implementation to migrate support the analysis of new IRs. For example, the Clang compiler has undergone ten major version updates in the past decade [53], resulting in differences between IRs generated by different compiler versions. The IR differences necessitate tremendous manual efforts to migrate the dataflow analysis implementation for each version update in the long term. However, an LLM- ----errered dataflow analysis directly operates on the source code and supports different language standards.
Second, classical dataflow analysis lies in the various abstractions and precision settings (54), especially pointer analysis, fundamental pre-analysis in the classical dataflow analysis workflow. Specifically, the developers of dataflow analyzers have to consider different precision settings, such as Anderson-style pointer analysis (55) and Steensgaard's 's pointer analysis (56), and implement the analysis algorithms accordingly. This process demands significant implementation effort. In contrast, LLMs, being aligned with program semantics, serve as interpreters of program semantics and eliminate the need to propose abstractions and implement analysis under specific precision settings. Instead, we can interact with LLMs by prompting them to query the program facts of interest very conveniently.
A.2 Prompt of LLMDFA and Baseline
This section presents more details of prompt design in LLMDFA and the end-to-end analysis, including the basic principle, prompt templates, and the forms of the examples used in few-shot prompting.
A.2.1 Prompt Design Principle of LLLDFA
To facilitate the synthesis of src/sink extractors, we enumerate the various types of sources and sinks derived from the definition of dataflow-related bugs. Specifically, we follow the comments in Juliet Test Suite and manually specify different forms of sources and sinks. To support dataflow summarization, we present illustrative examples showcasing different dataflow patterns, including the dataflow facts resulting from direct uses, assignments, and load/store operations upon pointers. Regarding the script synthesis for path feasibility validation, we do not offer examples and instead provide a basic skeleton of a Python script program. We then prompt LLMs to complete the script based on the provided path information.
A.2.2 Prompt Templates of LLMDFA
The detailed prompt templates used in the DBZ detection are shown in Figure 9 Figure 10 and Figure IT] For other bug types, the prompt templates are similar. Notably, all the examples in the prompts consist of no more than six lines of code. When writing the examples and explanations, we maintain a consistent program structure and sentence format, which can be easily achieved via simple copy-and-pasee operations and minor modifications upon specific statements or expressions. This process requires no specialized expertise and entails minimal manual effort.
A.2.3 Example Program and Sink Extractor for DBZ Detection
Figure 12 shows the example program and the synthesized sink extractor in the DBZ detection.
15

---

Role: You are good programmerr and familiar with AST of programs. Description: Pleuse write the Python script traversing AST and identify sources/sinks for data flow unalysis.
Source/Sink Info: There are several forms of sources/sinke [Spec] Also, we offer several example programs containing sources/sinks and their corresponding ASTs: [Example Programs + ASTs]
Synthesis Task: Please wrile Python script to extract the sounces'sinks on AST. You may refer to the AST
structure of the example programs, and a skelcton AST traverser program. [skelcton]
Fixing Task: Here is the synthesized result of last round: [scripi]. When executing the script, we encounter the following error: [error message]. Here are missed sources/sinks are missed: [missed ones]. Here are the variables misidentified as sources/sinks: fincorrect ones]. Please fix it and return a runnable script.
Figure 9: The prompt template of the source/sink extractor synthesis the DBZ detection
Role:
You are good Java programmer. You are good understanding the semantics of Java programs.
Description: Determine whether two variables two lines have the same value.
Here several rules:
they
same variable and not overwritten between two lines, the answer should yes.
(2) If the variable assigned with the value variable then answer should yes. [Other rules]
Here are several examples:
Example 1: User: [Program] [Question]
System: [Answer: Yes] [Explanation: y is assigned with x at line 2 and not over-written betweon lines and 3. Hence, the value of y at line 3 is the same as defined at line I. The answer is Yes.]
[Other examples]
Question:
Now give
function: [FUNCTION]
Please answer: Does [VAR]] used at line [LI] have the same value [VAR2] defined at line [L2]
Please think it step by step. Return Yes/No with the explanation.
Figure 10: The prompt template of the dataflow summarization in the DBZ detection
Role: You are good programmer and familiar with Z3 python binding.
Description: Please write a Python program using 23 python binding encode the path condition.
Path Info: Here is path: [path]. Note that the value of [variable] is 0. Line [line number] is the
[true/false] branch of the if-statement, of which the condition is bbanch condition].
Synthesis Task: Please write Python script to solve the path condition using Z3 python binding. You can refer the skeleton: [skeleton]
Fixing Task: Here is the syuthesized result of last round: [scripl]. When executing the synthesized script, we encounter the following error: [error message]. Please fix the bug and return runnable script.
Figure 11: The prompt template of the path feasibility validation in the DBZ detection
int 0; // double x2 = 0.0; // sre: x2 float 0.ef; sec:
def is intereestingnndde)
return (hode.type- "ypnr="binary expr"
and (node.og op -- "x" an
hode.op '/"))
var s - '0"; int x4 parseInt(s); //src: x4
def traverse(node, sinks):
is interestinngnodens
append sec_ _ee_andendnd))
int 1; int z x; // sink:
return sinks for child nede.children:
int y; // sink: y
sinks traverse(child, sinks) sinks traverse(ast_root, (])
int
(a)
(b)
Figure 12: An example program with sources/sinks (a) and sink extractor (b) for the DBZ detection
A.2.4 Prompt Design of LLM--bsse End-to-end Analysis
To facilitate the LLM--bsee end-to-end analysis, we include concise code snippets that encompass all forms of sources and sinks in a prompt. Each code snippet represents a single pair of source and sink. Additionally, provide concise explanation of the step-by-step dataflow process from source
16

---

Table 6: Comparison of performance for different models on various bug types and kinds (Source/Sink). (FP(%) indicates the proportion of successful synthesized extractors without any fixes. MNF and ANF are the maximal number and average number of fixes, respectively.
Bug
Kind
spr-3.5
gpt-4
gemini-1.0
claude-3
())
MNF
ANF
NFP(%)
MNF
ANF
NFP(%)
MNF
ANF
NFP(%)
MNF
ANF
Source
95.00
0.35
95.00
0.05
95.00
0.05
100.00
0
0
DBZ
Sink
100.00
100.00
0
0
100,00
XSS
Source
100.00
0.00
15,00
4
1.85
95.00
0.05
100,00
0
0
Sink
15.00
90.00
1
0.05
95.00
0.00
30
7.20
Source
95.00
0.10
40.00
2
0.65
100.00
95.00
11
0.55
Sink
90.00
0.55
95.00
0.05
100.00
100.00
0
0
to sink. In what follows, we present an example from the prompt that supports the few-shot CoT prompting in the end-to-end analysis for the DBZ detection.
Listing 1: An example used in the few-shot CoT prompting seasetting--aedddd end-to-end analysis
User:
Here the progrem:
2. x = x; y x;
4. int 2 10 yi
buge the program stop by step.
System:
There divide-by
(DBZ) Bug 1: The value of x at the line is assigned by the literal o. It ia used to assign zero value to divisor 1ine 4,
the program:
y is divisor is equal to O. Hence, there is a DBZ bug at the line 4.
variable y at
We do not show the template of the prompts used for the LLM-based end and-to-end analysis as is quite similar to the one used in the dataflow summarization shown in Figure The only difference is that we demonstrate different forms sources and sinks along with various dataflow patterns in the prompts to achieve end-to-end solution.
A.3
Additional Experimental Results
This section presents additional experimental results. Specifically, we demonstrate detailed results of the three stages of LLMDFA, such the fixing numbers of source/sink extractor synthesis and the script program synthesis in the path feasibility validation. Then we offer the performance results of LLMDFA. end-to-end analysis, and the ablations equipped with different LLMs. Due to the page limit, we do not provide them in the main body of our paper.
A.3.1 Fix Numbers of Source/Sink Extractor Synthesis
In our evaluation, we set the temperature to 0 enforce the LLMSs perform greedy encoding without any sampling strategy. However, randomness still exists due to GPU's inherent non-determinism. Considering the resource cost of invoking LLMs, we repeatedly synthesize source/sink extractors 20 times. As shown in Table 6 most of the source/sink extractors can be synthesized without any fixes. Even if LLMDFA fails synthesize the extractors for the first time, such LLMDFA with claude-3 has to fix the sink extractors for the XSS detection in most of the cases, the average number of the fixes is only 7.20, indicating that LLMDFA can finish the extractor synthesis without many iterations.
17

---

A.3.2 Fixing Numbers of Path Feasibility Validation
We also quantify the fixing numbers of Python script program synthesis in the path feasibility validation. As shown Figure [3] 75. 75.20%, 96.43%, and 85.25% of scripts are synthesized using gpt-3.5 5 without any fixes in the DBZ, XSS, and OSCI detection, respectively, which is shown in Figure 13 (a), Particularly, only 0.61% % 3.57%, and 4.92% the synthesized Python scripts fail after three rounds of fixing in the DBZ, XSS, and OSCI detection, respectively, eventually falling back to strategy of directly utilizing LLMS for the path feasibility validation. It is also found that 78.57%, 88.68%, 68%, and 76.34% of synthesized scripts in the DBZ, XSS, and OSCI detection correctly encode the path conditions, respectively. Although several path conditions are encoded incorrectly, their satisfiability remains the same the original ones. One typical example is that the LLM interprets Math. abs (b) 1 in Figure should be Or (b 1, b 1.. However, such wrongly encoded constraints still enable to refute infeasible paths. We offer more case studies in Appendix
T as the constraint And (b 1, b -1), while the correct encoding
When validating path feasibility with other models, including gpt-4, gemini-1.. O, and cl aude-3, LLMDFA can also synthesize Python
scripts as solving programs with a small number of fixes, which are shown by Figure 13 (b)~(d).
100%
DB2
100%
DBZ
XSS
OSCI
OSCI
MF1x 0
AFk 11
#
#F #Jsing LLM
#Fix
#Fx
#Fx susing LLM
(a) gpt-3.5
(b) gpt-4
XSS
XSS
75%
OSCI
oscI
60%
25%
0%
MF1x =0
=
#
# #Jsina LLM
WFx 0
#Ftx
#F
=
sUsing LLM
(c) gemini-1.0
(d) claude-3
Figure 13: The numbers of fixes path feasibility validation using different LLMs
18

---

A.3.3 Performance of LLMDEA and LLM-based End-to-End Analysis Using Different LLMs
GPTS.G
GPT-3.5
LUMDRA with GPT-3.5
GPT-3.5
LUMBFA with GPT-3.5
1.00
1.00
230
0:90
6.05
029
210
roail
Performance comparison of LLMDFA and the end-to-end analysis powered by gpt-3.5
GPT-4
LLMDFA GPT-4
LLMOFA GPT-4
GPT4
LUMDFA
prodsice
predtion
1.00
0.76
0.50
0.50
8.5
000
0/0
21 nooA
modi
(b) Performance comparison of LLMDFA and the end-to-end analysis powered by gpt-4.0
gemiri-1.00pm 1.0pr
geriin-1
gentri-1.0-gm
gemini-1.0ppp
1.0mp
gamnini-10ppp
1.
1.0
100
24
3.50
9.90
10
am
F1 sooe
Rcal
F1seoe
rocal
seaie
(c) Performance comparison of LLMDFA and the end-to-end analysis powered by gemini-1.0 1.0
Shupte--oouus
LLMDFA with ClauddeS-oppus
Saude---opus
LLMD with craude-3-opus
daauce-Sropus
LLMDFA
claude- ciaude--S-opu S-opus
1.0
100
0.75
3.50
4.55
08
8.59
0.25
meat
(d) Performance comparison of LLMDFA and the end-to-end analysis powered by claude-3
Figure 14: The precision, recall, and F1 of LLMDFA and LLM-based end-to-end analysis in the DBZ, XSS, and OSCI detection. From left to right in each line from left to right, the sub-figures depict the statisties of performance in the DBZ, XSS, and OSCI detection, respectively.
19

---

A.3,4 Performance of LLMDFA and it Ablations Using Different LLMs
preceson 1,00
presision
precscon
1,80
0.70
0.79
0.75
0.50
0.50
0.25
0.21
F1 sooee
meal
recal
(a) Performance comparison of LLMDFA and ablations powered by gpt-3.5
prectsion
1,00
1.00
precision
1.00
0.50
0,50
0.25
0.25
A.00
A.00
F1 wore
recal
Fl score
recal
acore
(b) Performance comparison of LLMDFA and ablations powered by gpt-4.0
prectsion
predition
1.00
1.00
0.75
0,50
0.0
p0
400
score
rocal
neai
score
recall
(c) Performance comparison of LLMDFA and ablations powered by gemini-1.0
pracision
predicion
1.00
1.00
0.6
2000
0.28
0.0
8.00
A.00
FI seare
rocal
score
recal
acore
recal
1
12
(d) Performance comparison of L.MDFA and ablations powered by claude-3
Figure 15: The performance of (LMDFA((), N2S) NoCoT(@), and NoSynVal( using gpt-3.5, 55 gpt-4, gemini-1.. O. and 3 in the DBZ, XSS, OSCI detection. From left right in each line from left to right, the sub-figures depict the statistics of performance in the DBZ, XSS, and OSCI detection, respectively.
20

---

A.4 Case Study
This section presents several examples hallucinations, including the ones in the LLM-based end- to-end analysis and the incorrect path conditions synthesized by LLMDFA in the path feasibility validation. We also provide examples of false positives and false negatives reported by LLMDFA when analyzing real-world Android malware applications in TaintBench.
A.4.1 Hallucinations of LLM-based End-to-End Analysis and Ablations
As demonstrated in the main body of our paper, LLMDFA mitigates the hallucinations L.L.- powered dataflow analysis according to two key ideas. First, it decomposes the whole analysis into three more manageable sub-problems, which target smaller code snippets and more simple program properties. Second, it leverages the tool synthesis and the few-shot CoT prompting to solve the three sub-problems effectively. In what follows, we present three typical cases hallucinations that the LLM-based end-to-end analysis and the ablations of LLMDFA can suffer.
Case I: The LLM-based end-to-end analysis and the ablation NoSynExt without extractor synthesis would identify Integer.MIN, VALUE as a potential zero value, which does not conform to Java semanties. In contrast, LLMDFA correctly identifies sources and sinks in a deterministic fashion with the extractors, which are synthesized by LLMs according to user-specified examples.
Listing 2: An example of misidentified sources
int data; Integer Minger-MIN_,ALA VALUE;
Bead data from cockies
cookieSourcea =xquust..etbbokiee>>)
if (caoktesources i= mull) {
POTENTIAL FLAV: Reed data from the first cookie value
(o)_errle)))).g)tlllee)))) String stringllumber cookieSources [0] gatValue();
try {
trin();; } catchhhhtubeerrooaaeeeeee except/imberPorrat))
data Integer, www.ereaaeeeereeeeeiiiiiiia
I0.legger. 10.logger. log(Levll. HARKING,
exception", excopt/umbarFormat))
hadSink(data
request,
response);
Case II: The ablation NoCoT would identify a dataflow fact from the zero value to the first assignment www.Comaine..ootaineeeeeeeee
which does not conform the control flow order. The LLM-based end-to-end analysis is instantiated with the few-shot CoT prompting strategy. However, it takes the whole program as the input and, thus, may suffer more severe hallucinations due to the lengthy prompts, making it identify the incorrect dataflow facts in Listing 3
Listing 3: An example of misidentified dataflow facts single functions
int data - 2;
dataContainer new Container(); dataContainer. containerdne data;
Dodd2BBinxx(astaCCnttiia request, response); data
dataContainers containerthe data;
(astsaan,,,,,ttoottaiine,,, request, response);
Case III: The LLM-based end-to-end analysis and the ablation NoSyn Val (i.e., the ablation that directly prompts LLMS for path feasibility validation) would regard the condition in the second if-statement as satisfiable when data has value, causing a false positive in this case.
Listing 4: example of misidentified feasible paths
it SWW.STTTTTIAALLLL TRUE) {
0.or;
} elee data 2.0f;
if (bath. (data) 0.000001) { (100.0 data); (o.erutt)l.ne(reauttt:
21

---

In our evaluation, we have shown that LLMDFA achieves better performance than the LLM-based end-to-end analysis and its three ablations. The above three typical cases of hallucinations can be effectively mitigated by LLMDFA. The statistics and these concrete cases demonstrate the effectiveness of our problem decomposition and the technical designs of LLMDFA, including the tool synthesis and few-shot CoT prompting.
A.4.2 Incorrect Path Conditions in Path Feasibility Validation
We present several examples to show the limitations LLMDFA path feasibility validation. Specifically, we discuss three complex forms of path conditions.
Case I: Usage of Library Functions.
Listing shows the code snippet in CWE369 DBZ d connect _cp__iivde___ee_____e 09.java. The con- dition of the second if it-stattment is Math. abs (data) >0. 000001, which is apparently not satisfied when data is equal to 0. In our evaluation, we find that LLMDFA tends to take Math abs (data) constraint and append it to Z3 instance directly, which yields crash in the execution of the synthesized script. After several rounds of fixing, LLMDFA can generate script program encoding the path condition correctly. However, we still observe that LLMDFA fail synthesize the correct script programs for several benchmark programs. Specifically, LLMDFA can wrongly interpret the semantics of Math. abs (data) 000001 with the conjunction And (data O. 0.000001, data < -0. 000001,, while the correct interpretation should be the disjunction Or (data 0. .000001, data 000001). It shows one of the limitations of LLMDFA. When a branch condition contains library function, LLMDFA may offer a wrong interpretation of its semantics. Although in- terpreting Math. abs (data) >0. 000001 as And (data 0.000001, data -0. 00000100 also makes LLMDFA identify the path as an infeasible one, the path is not discarded in correct way.
Listing CWE369 DBZ float connect_tep_coee div_divide_____ee 09
public class CHE369 beclcat_ccmnet_tayee public void goodB201 if FI..STATIC_FIMAL_TRRR
data 0.0r;
) else data 2.0f;
(Hath. abathaab (data) 0.000001) int reault (int) (100.0 data); I0. ID.vritee.ine(reeutt))
}
Case II: Usage of User-defined Functions
Listing shows an example of using user-defined function in branch condition. Specifically, randomly generates True or False as the return value.
the function statiicReturssSTuerFFaaaa Actually, the branch condition should be symbolized with an unconstrained variable in a Z3 instance. In our current implementation of LLMDFA, we do not support the retrieval of the function definition of PaaticcRtuunssTreerFaaaa
and the L.MMs may directly interpret the branch condition as True or False incorrectly. For the program shown in Listing 6 L.MDFF would cause false negative if the branch condition is interpreted as False.
Listing 6: CWE369_DRD BB7 caapt_onnettt__diiiiiee wivittpp_diii________
public CWE369_DRE [e0___flaa__comnctttoo divido_12
public void bad() oeC...sssaaaeeeuuusssrrrrrrleee {
data 0.0f; } else 2.01;
1f (t0..attticcttummtrruuattaa... {
int result (int) (100.0 data); I0. www.wiieeiieeeee (resuutt;;
22

---

public boolean #aat:cketurrsstrudraalaaa return (new java.util (eva.util.Random)) ()) nextBooleen
Case III: Usage of Global Variables
Listing 7 shows an example where the branch condition is guarded by a static member field badPublicStatic, which can be regarded global variable for the member functions, such as the functions bad and badSink. Initially, IadPublicState is set to False. The function bad further sets it to True. Hence, the branch condition badPublicState is satisfied when the function badSink is invoked after the statement badPublicStatic
true in the function bad.
In our implementation of LLMDFA, we just retrieve the initialization of each class field via sim- ple parsing. LLMDFA can introduce false negative in this example, it not aware that badPublicStatt is set to True. By simple parsing, we cannot obtain the precise value of a global variable that can be modified multiple program locations. Once the global variables are used to construct branch condition, LLMDFA may determine the feasibility of the program path incorrectly, introducing false positives or false negatives. To prune the infeasible path with high recall, we can concentrate the branch conditions in simple forms. For example, if we encounter branch condition using global variable, we can assume that can be satisfied. Although this strategy may introduce false positives, we still have the opportunity to reject many infeasible paths.
Listing 7: CWE369 B003669D_Z______ hea____oaa_cooeeetcpppoooooo
public class CVE369 CWE369_082__ Eleaat_conneee sop_divide_22 public static boolean badPublicStatie false;
public void bad() badPublicStatic true; int data 0; (ddSin)(dataa;
public void (anSink(int data) { if (badPublicStatic)
result (int) (100.0 data);
10. (0.aritatline(reautt)
Lastly, is worth noting that encoding path conditions precisely is quite challenging. Existing studies of compilation- based dataflow analysis have explored it for several decades while still failing to achieve satisfactory performance in real-world scenarios. our work, LLMDFA has demonstrated its potential in discovering the path conditions that exhibit conflicting patterns. Notably, it can understand commonly used library functions according their names, while such library functions can not be analyzed by compilation- baailatioo---edddddd approaches when their implementations are unavailable. In the future, we can further improve LLMDFA in encoding path constraints by more advanced strategies, such as adopting the CoT prompting to the library function encoding and feeding LLMSs with more detailed path info. Besides, we can enforce L.LDFFA only focus on specific simple individual branch conditions, such as p != 0, and generate the condition that over-approximates the actual path condition. This strategy can eventually achieve semi-path sensitivity, which would improve the precision of specific analysis instances with little sacrifice of the recall.
23

---

A.4.3 Examples of False Positives and Negatives of LLMDDA upon TaintBench
Listing 8: A false negative example of LLMDFA upon TaintBench
private String getSun/eesagezous5
String 0 projection
String ("id", "addrese");
Stringbuilder str nez StriagBailder()
//uri
Cursor uri getContentReeclver Serbattetteeeleeeo-uqueeee/ http://aaaaaeeetttttttt//aaaaa str. aeppppppproeeseeluluaaaaeeee true)); return str. str.toString();
projection, "id deac");
private Stringäuilder procezsRenulta (Carsor cur, beolean all) { //cur: Start point the miased dataflos summary StringBuilder str new StringBuilder() tzy { while (cur.noveoPirrst()
String phoneluuber sur.getttring (phomeiommp)
atr atr.aappen(phonehuubee + "(n");
} catch (Exception e)
Log. aag.effhhoeyyccerriiccc.c o)toString));;
1/str: End point of the nissed dataflou sunnary stx;
public void BacktomTask() { Socket socket new Socket (Ioet&ddreas Beeeeecc www.///mwwwawo...eeeoooooooae 5001);
outStrean. outStrean.vritaff (rita(("result. ""aae"rrreutt..eaaaoooo"" getSnakesaagesout () -etBytte(""Exx")) (rr //The argunent is
sink
outStrean. urite("\a" srita("Ma".geeBBytss()) (e)
Listing 9: A false positive example of LLMDFA upon TaintBench. The lengthy function onMessage makes LLMDFA identify spurious dataflow summary from url to the argument msg. The spurious dataflow summary eventually introduces a spurious dataflow path from source value url, i.e., the return value of getStringExira, to sink value in the function sendBackgrunddessagg..
public void onNassage (Context context, Intent intent)
Utila utils Utila. www.ggeennnneeeeeeeo (context);
String comnand intent. ("teriinnnEtrreeccmema
final Context scontext; String url;
(comannd, equsIa("START"))
context. www.ttttriicaaeaaateaa (new Intent (context, (orkservvic.cllass))
elae if (comnand equals ("SEND SMS") {
String utils. www.:eaccgoooonoeeeaaeeeeooooooe
intent wwwttringgStrra ("datta)
//nsg: End point of the spurious dataflow summary } alse if (connand. equals ("SEND_SMC (ao____MSS_O"")
String ana_nov intent, getttrrgggstttrrataatt..... utile. wew.ieeessgeloooeen now);
else if (comnand. equala (CHAKGE_URL")) {
//url: Start point the spurioue dataflow sumary. 1e uel iintent.geS.rinngiieeee. www.gestiiigxxtreeMaaaa. also if (url mull åk www.aalllaillaaaarrgg..oo..
ut:la.satUri (url);
elee (command, "oommnddequals((
scontext
final String data
Thread Runnable()
public void run() { Vrils. RealaegeIIsstanceeeee (scontextt, instal//aak((ats))
)eetart();
}
24

---

NeurIPS Paper Checklist
The checklist is designed encourage best practices for responsible machine learning research. addressing issues of reproducibility. transparency, research ethics, and societal impact. Do not remove the checklist: The papers not including the checklist will be desk rejected. The checklist should follow the references and follow the (optional) supplemental material. The checklist does NOT count towards the page limit.
Please read the checklist guidelines carefully for information on how to answer these questions. For each question in the checklist:
You should answer [Yes]. [No] or [NA]-
[NA] means either that the question is Not Applicable for that particular paper or the
relevant information is Not Available.
Please provide short (1-2 sentence) justification right after your answer (even for NA).
The checklist answers are an integral part of your paper submission. They are visible to the reviewers, area chairs, senior area chairs, and ethics reviewers. You will be asked to also include it (after eventual revisions) with the final version of your paper, and its final version will published with the paper.
The reviewers of your paper will be asked use the checklist one of the factors their evaluation. While "[Yes]" " is generally preferable to "[No]" ", it is perfectly acceptable to answer "[No] provided a proper justification is given (e.g., "error bars are not reported because it would be too computationally expensive" or "we were unable to find the license for the dataset we used"). In general, answering binary way, we
"[No] " or "[NA] is not grounds for rejection. While the questions are phrased acknowledge that the true answer is often more nuanced, so please just use your best judgment and write justification to elaborate. All supporting evidence can appear either in the main paper or the supplemental material, provided in appendix. If you answer [Yes] to a question, in the justification please point to the section(s) where related material for the question can found.
IMPORTANT, please:
Delete this instruction block, but keep the section heading "NeurIPS paper checklist",
Keep the checklist subsection headings, questions/answers and guidelines below.
Do not modify the questions and only use the provided macros for your answers.
Claims
Question: Do the main claims made in the abstract and introduction accurately reflect the
paper's contributions and scope?
Answer: [Yes]
Justification: Please refer to Abstract and Section 1
Guidelines:
The answer NA means that the abstract and introduction do not include the claims
made in the paper.
The abstract and/or introduction should clearly state the claims made, including the contributions made in the paper and important assumptions and limitations. A No or
NA answer to this question will not be perceived well by the reviewers.
The claims made should match theoretical and experimental results, and reflect how much the results can be expected to generalize to other settings. It is fine to include aspirational goals as motivation long is clear that these goals are not attained by the paper.
2. Limitations
Question:
Does the paper discuss the limitations of the work performed by the authors?
Answer: [Yes]
Justification: Please refer to Section 4.7
Guidelines:
The answer NA means that the paper has no limitation while the answer No means that the paper has limitations, but those are not discussed in the paper.
The authors are encouraged to create separate "Limitations" section in their paper.
The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g., independence assumptions, noiseless settings,
25

---

model well-specification asymptotic approximations only holding locally). The authors should reflect on how these assumptions might be violated in practice and what the implications would be.
The authors should reflect on the scope of the claims made, e.g., if the approach was only tested a few datasets or with few runs. In general, empirical results often depend on implicit assumptions, which should be articulated.
The authors should reflect the factors that influence the performance of the approach. For example, facial recognition algorithm may perform poorly when image resolution is low images are taken in low lighting. Or speech-to-text system might not be used reliably to provide closed captions for online lectures because it fails to handle technical jargon.
The authors should discuss the computational efficiency of the proposed algorithms
and how they scale with dataset size.
If applicable, the authors should discuss possible limitations of their approach to address problems of privacy and faimess.
While the authors might fear that complete honesty about limitations might be used by reviewers as grounds for rejection, worse outcome might be that reviewers discover limitations that aren't 't acknowledged in the paper. The authors should use their best judgment and recognize that individual actions in favor of transparency play an impor- tant role in developing norms that preserve the integrity of the community, Reviewers will be specifically instructed to not penalize honesty concerning limitations.
3. Theory Assumptions and Proofs
Question: For each theoretical result, does the paper provide the full set of assumptions and a complete (and correct) proof?
Answer: [NA]
Justification: The paper contains theoretical result. The approach is evaluated empirically, Guidelines:
The answer NA means that the paper does not include theoretical results.
All the theorems, formulas, and proofs in the paper should be numbered and cross- referenced.
All assumptions should be clearly stated or referenced the statement of any theorems. The proofs can either appear in the main paper or the supplemental material, but if they appear in the supplemental material, the authors are encouraged to provide a short proof sketch provide intuition.
Inversely, any informal proof provided in the core of the paper should be complemented by formal proofs provided in appendix supplemental material. Theorems and Lemmas that the proof relies upon should be properly referenced.
4. Experimental Result Reproducibility
Question: Does the paper fully disclose all the information needed to reproduce the main ex- perimental results of the paper to the extent that affects the main claims and/or conclusions of the paper (regardless of whether the code and data are provided or not)? Answer: [Yes]
Justification: We have demonstrated the details of our technique in Section 3 Section offers the detailed evaluation settings and descriptions of the experimental subjects. Ad- ditionally, we have provided the designs of prompts used in our approach and its baseline in Appendix AA.2] We believe the illustrations and figures these sections enable other researchers reproduce the main results of our paper.
Guidelines:
The answer NA means that the paper does not include experiments. If the paper includes experiments, a No answer to this question will not be perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not.
If the contribution is dataset and/or model, the authors should describe the steps taken to make their results reproducible or verifiable.
Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution is a novel architecture, describing the architecture fully might suffice, or if the contribution is specific model and empirical evaluation, may be necessary to either make it possible for others to replicate the model with the same dataset, or provide access to the model. In general. releasing code and data often
26

---

one good way to accomplish this, but reproducibility can also be provided via detailed instructions for how replicate the results, access to a hosted model (e.g., in the case of a large language model), releasing of a model checkpoint, or other means that are appropriate to the research performed.
While NeurlPS does not require releasing code, the conference does require all submis- sions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example
(a) the contribution is primarily a new algorithm, the paper should make clear how reproduce that algorithm.
(b) the contribution is primarily a new model architecture, the paper should describe the architecture clearly and fully.
(c) If the contribution is a new model (e.g., a large language model), then there should either be way to access this model for reproducing the results or way to reproduce the model (c.g.. with an open-soure dataset or instructions for how to construct the dataset).
(d) We recognize that reproducibility may be tricky in some cases, in which case authors are welcome describe the partieular way they provide for reproducibility. In the case of closed-source models, it may be that access to the model is limited in some way (c.g., to registered users), but it should be possible for other researchers to have some path to reproducing verifying the results.
5. Open access to data and code
Question: Does the paper provide open access to the data and code, with sufficient instruc- tions to faithfully reproduce the main experimental results, as described in supplemental material?
Answer: [Yes]
Justification: We have open-sourced our data and tool httpa://github. com/ chengpeng- wang///ggwaan//nnn waMg//LLFA///AAAAA ALMDFA
Guidelines:
The answer NA means that paper does not include experiments requiring code.
Please see the NeurIPS code and data submission guidelines (https://nips.co
public/guide httal//guuieee/ooouuubiiissss Swwee/ooieiiiiiioooooo casssoiicyyyyl for more details.
While we encourage the release of code and data, we understand that this might not be possible, so "No" is an acceptable answer. Papers cannot be rejected simply for not including code, unless this is central to the contribution (e.g., for new open-source benchmark).
The instructions should contain the exact command and environment needed to run to reproduce the results. See the NeurlPS code and data submission guidelines (https
/ craips.cc/pubicc/gue guw.s/////////eee/eo CooeeSumiiissse ssi ssionolycy for more details.
The authors should provide instructions data access and preparation, including how to access the raw data, preprocessed data, intermediate data, and generated data, etc.
The authors should provide scripts to reproduce all experimental results for the new proposed method and baselines. only subset of experiments are reproducible, they should state which ones are omitted from the script and why.
At submission time, to preserve anonymity, the authors should release anonymized versions (if applicable).
Providing as much information as possible in supplemental material (appended to the paper) is recommended, but including URLs to data and code is permitted.
6. Experimental Setting/Details
Question: Does the paper specify all the training and test details (c.g., data splits, hyper- parameters, how they were chosen, type of optimizer, etc.) necessary to understand the results?
Answer: [Yes]
Justification: We have provided the detailed experimental settings, including subject selec- tion and temperature setting in Section 4 The designs of the prompts used in our approach and its baseline have been demonstrated in Appendix A.2 Lastly, we have also listed all the concrete prompts in the supplementary material, which is separate submitted file. Guidelines:
The answer NA means that the paper does not include experiments.
27

---

The experimental setting should be presented in the core of the paper to a level of detail that is necessary appreciate the results and make sense of them.
The full details can be provided either with the code, in appendix, as supplemental material.
7. Experiment Statistical Significance
Question: Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?
Answer: [No]
reported because it would be too computationally expensive. However, we have repeated a specific component of our approach multiple times, i.e., source/sink extractor synthesis, and listed the detailed statistics in Appendix [A.3.I] including the average fixing number and the proportion of successful synthesis without any fixes. Guidelines:
Justification: Error bars
The answer NA means that the paper does not include experiments.
The authors should answer "Yes" if the results are accompanied by error bars, confi- dence intervals, or statistical significance tests, at least for the experiments that support the main claims of the paper.
The factors of variability that the error bars are capturing should be clearly stated (for example, train/test split, initialization, random drawing of some parameter, or overall
run with given experimental conditions).
The method for calculating the error bars should be explained (closed form formula,
call to a library function, bootstrap, etc.)
The assumptions made should be given (e.g.. Normally distributed errors).
It should be clear whether the error bar is the standard deviation or the standard error of the mean.
It is OK to report I-sigma error bars, but one should state it. The authors should preferably report a 2-sigma error bar than state that they have 96% CI, if the hypothesis of Normality of errors is not verified.
For asymmetric distributions, the authors should be careful not to show in tables or figures symmetric error bars that would yield results that out of range (e.g. negative error rates).
If error bars reported in tables or plots, The authors should explain in the text how they were calculated and reference the corresponding figures or tables in the text. 8. Experiments Compute Resources
Question: For each experiment, does the paper provide sufficient information on the com- puter resources (type of compute workers, memory, time of execution) needed reproduce the experiments?
Answer: [Yes]
Justification: We utilize the APIs to invoke the LLMs mentioned in Section 4
We have
provided the average financial cost of analyzing each program in Section 4
Guidelines:
The answer NA means that the paper does not include experiments.
The paper should indicate the type of compute workers CPU or GPU, internal cluster, or cloud provider, including relevant memory and storage.
The paper should provide the amount of compute required for each of the individual experimental runs as well as estimate the total compute.
The paper should disclose whether the full research project required more compute than the experiments reported the paper (e.g., preliminary or failed experiments that didn't 't make it into the paper).
9. Code Of Ethics
Question: Does the research conducted in the paper conform, in every respect, with the http:///wwwrppps.cpppccee///e/ee
NeurlPS Code of Ethics Answer: [Yes]
Justification: We have read the code of ethics and confirmed that we do not violate the code of ethics.
Guidelines:
The answer NA means that the authors have reviewed the NeurIPS Code of Ethics.
If the authors answer No, they should explain the special circumstances that require a deviation from the Code of Ethics.
28

---

The authors should make sure to preserve anonymity (e.g., if there is special consid- eration due to laws or regulations their jurisdiction).
10. Broader Impacts
Question: Does the paper discuss both potential positive societal impacts and negative societal impacts of the work performed?
Answer: [Yes]
Justification: We have discussed the broader impacts in Appendix A.1
Guidelines:
The answer NA means that there is no societal impact of the work performed.
If the authors answer NA or No, they should explain why their work has no societal
impact why the paper does not address societal impact.
Examples of negative societal impacts include potential malicious or unintended uses (e.g., disinformation, generating fake profiles, surveillance), fairness considerations (e.g., deployment of technologies that could make decisions that unfairly impact specific groups). privacy considerations, and security considerations.
The conference expects that many papers will be foundational research and not tied particular applications, let alone deployments. However, if there is direct path to any negative applications, the authors should point it out, For example, it is legitimate point out that an improvement in the quality of generative models could be used to generate deepfakes for disinformation. On the other hand, it is not needed to point out that a generic algorithm for optimizing neural networks could enable people train models that generate Deepfakes faster.
The authors should consider possible harms that could arise when the technology is being used as intended and functioning correctly, harms that could arise when the technology being used as intended but gives incorrect results, and harms following from (intentional unintentional) misuse of the technology.
there are negative societal impacts, the authors could also discuss possible mitigation strategies (e.g., gated release of models, providing defenses in addition to attacks, mechanisms for monitoring misuse, mechanisms to monitor how a system learns from feedback over time, improving the efficiency and accessibility of ML).
11. Safeguards
Does the paper deseribe safeguards that have been put in place for responsible release of data or models that have a high risk for misuse (e.g., pretrained language models, image generators, scraped datasets)?
Question:
Answer: [NA]
Justification: This paper does not introduce particular safety risks. Guidelines:
The answer NA means that the paper poses such risks.
Released models that have high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model. for example by requiring that users adhere to usage guidelines or restrictions to access the model or implementing safety filters.
Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images. We recognize that providing effective safeguards is challenging, and many papers do not require this, but we encourage authors to take this into account and make best faith effort.
Licenses for existing assets
Question: Are the creators or original owners of assets (c.g., code, data, models), used in the paper. properly credited and are the license and terms of use explicitly mentioned and properly respected?
Answer: [Yes]
Justification: We have described the data and tools used for the evaluation in Section which are open-sourced and granted by the authors.
Guidelines:
The answer NA means that the paper does not use existing assets.
The authors should cite the original paper that produced the code package dataset.
The authors should state which version of the asset is used and, possible, include a URL.
29

---

The name of the license (e.g., CC-BY 4.0) should be included for each asset. For scraped data from a particular source (e.g.. website). the copyright and terms of service of that source should be provided.
If assets are released, the license, copyright information, and terms of use in the package should be provided. For popular datasets, paperswi thcode. com/ datasets has curated licenses for some datasets. Their licensing guide can help determine the license of dataset.
For existing datasets that are re-packaged, both the original license and the license of the derived asset (if it has changed) should be provided. If this information is not available online, the authors are encouraged to reach out to the asset's 's creators.
13. New Assets
Question: Are assets introduced in the paper well documented and is the documentation provided alongside the assets?
Answer: [NA]
Justification: The paper does not release new assets.
Guidelines:
The answer NA means that the paper does not release new assets.
Researchers should communicate the details the dataset/cooee/model as part of their submissions via structured templates. This includes details about training, license, limitations, etc.
The paper should discuss whether and how consent was obtained from people whose asset used.
At submission time, remember to anonymize your assets (if applicable). You can either create an anonymized URL or include an anonymized zip file.
14. Crowdsourcing and Research with Human Subjects
Question: For crowdsourcing experiments and research with human subjects, does the paper include the full text of instructions given to participants and screenshots, if applicable, as well as details about compensation (if any)?
Answer: [NA]
Justification: The paper does not involve crowdsourcing nor research with human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing nor research with
human subjects.
Including this information in the supplemental material is fine, but if the main contribu- tion of the paper involves human subjects, then as much detail as possible should be included in the main paper.
According the NeurlPS Code of Ethics, workers involved in data collection, curation, or other labor should be paid at least the minimum wage in the country of the data collector.
15. Institutional Review Board (IRB) Approvals or Equivalent for Research with Human Subjects
Question: Does the paper describe potential risks incurred by study participants, whether such risks were disclosed to the subjects, and whether Institutional Review Board (IRB) approvals (or equivalent approval/review based on the requirements of your country or institution) were obtained?
Answer: [NA]
Justification: The paper does not involve crowdsourcing nor research with human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing nor research with
human subjects.
Depending on the country in which research is conducted, IRB approval (or equivalent)
may be required for any human subjects research. If you obtained IRB approval, you should clearly state this in the paper.
We recognize that the procedures for this may vary significantly between institutions and locations, and we expect authors to adhere to the NeurlPS Code of Ethics and the guidelines for their institution.
For initial submissions, do not include any information that would break anonymity (if applicable), such as the institution conducting the review.
30


Reviews:
[{"review_id": "2hJtFEb3a7", "reviewer": "Reviewer_KJcQ", "summary": "The author proposes a data flow analysis tool based on LLM, named LLMDFA. This tool addresses the LLM hallucination problem by decomposing tasks. The method is divided into three stages: the first stage involves calling and extracting sources and links through LLM-generated scripts; the second stage generates summaries of the data flow; the third stage conducts path analysis using synthesis tools and scripts. The study was validated on the Java programming language and considered four closed-source LLM models. Experimental results show that LLMDFA has high Recall and F1 metrics.", "questions": "- Your method has so far only been validated on the Java language. Do you have plans to experiment with other programming languages such as Python, C++, etc.? If so, what are the experimental results?\n- How do you think LLMDFA applies to other programming languages? Does the method need to be adjusted to adapt to different programming environments?\n- Why not try using open-source models?", "limitations": "See Weaknesses", "rating": 5, "confidence": 3, "soundness": 2, "presentation": 2, "contribution": 2, "strengths": "- The author explores the effective application of LLM in the field of code analysis.\n- Utilizes the generative capabilities of LLM to call external programs.", "weaknesses": "- The third part is relatively obscure. Although the author attempts to formalize the method of LLM analysis data flow, this expression is difficult for readers lacking a background in code analysis and data flow analysis to understand.\n- This paper is an application-type article of LLM. The generalizability of the research has not been fully verified, as experiments were only conducted on the Java language, limiting the general applicability of the conclusions.\n- LLMDFA is still affected by the LLM hallucination problem and may generate incorrect summaries, but the experimental section does not explore the impact of this issue on the method.\n- The experimental data volume is small, with only 37 programs tested for each type of bug, which may lead to significant bias in the experimental results. It is recommended to verify with a larger dataset to improve the reliability of the conclusions. TaintBench also has only 39 real-world android malware (line 242). The author should verify on a larger dataset to ensure the feasibility of the conclusions. Some datasets can be referenced [1,2].\n- The related work section lacks an introduction to the current research progress of LLM in the field of code analysis, such as [3].\n\n**Citation Suggestions:**\n[1] Yiu Wai Chow, Max Schäfer, Michael Pradel. 2023. \"Beware of the Unexpected: Bimodal Taint Analysis.\" *Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA 2023)*. ACM, New York, NY, USA, 211–222. https://doi.org/10.1145/3597926.3598050\n[2] Liu Wang, Haoyu Wang, Ren He, Ran Tao, Guozhu Meng, Xiapu Luo, Xuanzhe Liu. 2022. \"MalRadar: Demystifying Android Malware in the New Era.\" *Proc. ACM Meas. Anal. Comput. Syst.* 6, 2, Article 40 (June 2022), 27 pages. https://doi.org/10.1145/3530906\n[3] Haonan Li, Yu Hao, Yizhuo Zhai, Zhiyun Qian. 2024. \"Enhancing Static Analysis for Practical Bug Detection: An LLM-Integrated Approach.\" *Proc. ACM Program. Lang.* 8, OOPSLA1, Article 111 (April 2024), 26 pages. https://doi.org/10.1145/3649828", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "### **I. Answers to Questions**\n**Q1. Experiments upon Other Languages**\n\nAlthough we did not claim any contribution of multi-lingual support, it is easy to extend LLMDFA to support other languages due to its compilation-free design. During the rebuttal, we extended it to support C/C++/JavaScript and evaluated it with gpt-3.5 upon the Juliet Test Suite for C/C++ and SecBench.js benchmark [R2]. Due to the limited time, we did not evaluate LLMDFA using the other three LLMs.\n\nThe Juliet Test Suite for C/C++ does not contain XSS bugs. Hence, we chose another bug type, namely Absolute Path Traversal (APT), which is a typical security vulnerability in Common Weakness Enumeration. As shown in Table 9, the performance of LLMDFA on C/C++ is equally good as on Java.\n\nSecBench.js includes 138 vulnerabilities in JavaScript packages, covering command injection, taint path, and code injection vulnerabilities, which have been assigned with CVE IDs due to significant security impact. Table 10 shows that our compilation-free analysis upon SecBench.js achieves 92.54% precision and 71.74% recall, which are comparable with the compilation-dependent approach in [R2]. \n\n**Q2. Migration Details for Other Languages**\n\nLLMDFA can be extended to support other languages with low implementation effort. Based on dataflow analysis theory, we only need to construct the control flow graph with corresponding tree-sitter packages and then reuse the current implementation. To migrate Java analysis to C/C++/JavaScript analysis, we changed no more than 100 lines of code. Most of the changes relate to the changes to AST node types and parser initialization.\n\n**Q3. Reasons for Not Using Open-Sourced Models**\n\nWe actually tried to utilize open-sourced models, such as CodeLlama-7b-Instruct-hf. However, these models do not seem to have the capabilities to meet the output constraints in the presence of lengthy prompts. In several rounds of prompting for extractor synthesis, the open-sourced models, such as CodeLlama-7b-Instruct-hf, kept generating the following response without synthesizing the extractors at all.\n\n```\nI will examine the examples and their abstract syntax trees according to the given instructions. I will then generate the extractors to identify desired sources and sinks. Let me start the synthesis.\n```\n\nSimilarly, the LLMs are required to generate Yes or No to indicate whether the value of a program variable can depend on the value of another value. However, CodeLlama-7b-Instruct-hf did not explicitly give Yes or No as its answer in several cases. Instead, it even responded, “It is unknown whether the two values are dependent or not.”\n\nDue to the above reasons, we could not specify a fixed grammar to parse the responses. Similar problems were reported in existing works [R3, R4]. Another option is to use ultra-large open-sourced models. However, it requires GPU resources that are beyond our reach. To mitigate the threat of validity of relying on a single closed-source model, we tried to use as many such models as we could. \n\n### **II. Other Concerns**\n**C1. Hallucinations in Dataflow Summarization**\n\nThe rows named **Summarize** in Table 1 show the precision, recall, and F1 score of dataflow summarization. Consider the DBZ detection using gpt-3.5 as an example. 9.05% of identified dataflow summaries are spurious due to the LLM hallucination in the dataflow summarization. Meanwhile, 2.43% of valid dataflow summaries are not identified by the LLMs. In Appendix A.4.3, we also demonstrate the cases of false positives and negatives caused by the hallucinations in dataflow summarization.\n\n**C2. Evaluation Subjects**\n\nJuliet Test Suite contains 1,850 DBZ, 666 XSS, and 444 OSCI bugs, which are scattered in 3,809, 1,084, and 902 Java files, respectively. The precision, recall, and F1 score of the bug detection are measured upon all these Java files. To measure the performance of the dataflow summarization and path feasibility validation, we have to manually examine the intermediate results. This process would be quite laborious if we checked the intermediate results for all the programs. Hence, we chose 37 programs as the representatives, as the rest of the programs only differ from the selected ones in terms of sources and sinks. We have stated such settings from line 256 to line 259. We will add more justifications to avoid potential confusion.\n\nTaintBench offers rigorous definitions of malicious dataflows, which enable us to write bug specifications and few-shot examples for customization.The bugs in TaintBench are manifested by 53 different source-sink pairs, covering typical buggy patterns of sensitive information leakage. Due to its diverse taint flow forms, TaintBench has been widely used by many research papers published in top-tier conferences in software engineering and security [R5, R6, R7]. We believe choosing this benchmark can provide strong empirical evidence of LLMDFA’s effectiveness in the real world.\n\nWe appreciate the reviewer's recommendation of the two works [R2, R8]. However, the benchmarks they used are not suitable for the evaluation during the rebuttal. First, the constructed benchmark in [R8], namely MalRadar, and all the datasets listed by Table 1 in [R8], are currently unavailable or require authentication. Second, the experimental subjects used in [R2] include proprietary projects on LGTM.com and an open-sourced real-world benchmark SecBench.js. We tried our best to extend and evaluate LLMDFA upon SecBench.js during the rebuttal phase. For more evaluation details upon SecBench.js, please also refer to the answer to Q1 as above.\n\n**C3. Related Work**\n\nActually, we cited the preprint of the work LLift [R9] as [47]. By inferring how library functions initialize variables with LLMs, LLift detects uninitialized variables in the program. Different from LLMDFA, it still requires a compilation-dependent analyzer as its backend and can only detect uninitialized variables without customization support.", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "1JnQ4zXPi1", "reviewer": "Reviewer_jfEP", "summary": "This paper presents LLMDFA, an LLM-powered compilation-free and customizable dataflow analysis framework for bug detection. To mitigate LLM hallucination, LLMDFA breaks down the dataflow analysis (DFA) task into multiple subtasks and delegates complex reasoning to specialized external tools. In bug detection evaluations involving synthetic programs and real-world Android applications, LLMDFA achieves a precision of 87.10% and a recall of 80.77% on average. These results outperform existing baselines.", "questions": "Based on my best understanding, the dataflow summarization stage generates dataflow paths between sources and sinks. I am curious if any deterministic algorithms could handle this task instead of relying on an LLM. Furthermore, considering the potentially numerous rules involved in forming the paths, could you provide the actual prompt used at this stage?", "limitations": "The authors addressed limitations in their work.", "rating": 6, "confidence": 4, "soundness": 2, "presentation": 3, "contribution": 3, "strengths": "1. This paper investigates a promising direction in leveraging LLMs for code dataflow analysis. The motivation and methodology are clearly articulated and well-structured.\n2. To mitigate LLM hallucinations, the authors introduce a novel three-stage workflow: In the Source/Sink Extraction and Path Feasibility Validation stages, LLMDFA employs an LLM as a coordinator, delegating the complex analysis to external tools. In the Dataflow Summarization stage, LLMDFA uses a few-shot chain-of-thought (CoT) prompting strategy to align LLMs with program semantics. These approaches effectively reduce the intrinsic hallucinations associated with LLMs.\n3. The empirical results demonstrate that LLMDFA significantly outperforms existing baselines, including the classic dataflow analyzer CodeFuseQuery and an end-to-end CoT solution.\n4. LLMDFA can be applied to arbitrary programs without the need for compilation.", "weaknesses": "1. In the Path Feasibility Validation stage, the LLM's role is to synthesize a Z3 solver script. However, producing a runnable Z3 solver script does not necessarily ensure that the path is feasible, as the generated Z3 constraints may not accurately reflect the actual path conditions.\n2. Since LLMDFA does not require compilation, the presence of any unknown external call (e.g., `a = unknown_func(a)`) can terminate the dataflow analysis. This scenario is particularly common in real-world code.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "### **I. Answers to Questions**\n**Q1. Technical design of dataflow summarization**\n\nMany existing techniques, such as Pinpoint [R10] and SVF [R11], can derive dataflow paths deterministically. However, they all require the intermediate representations generated by a successful program compilation. As motivated by Figure 2, we want to fill the gap and establish a compilation-free program analysis. That is why we do not apply existing deterministic techniques and instead leverage LLMs for code semantic interpretation to achieve dataflow summarization.\n\nWe uploaded the prompts and responses as supplementary material. The details of dataflow summarization can be found in Listing 5, where the prompt and response of this phase are clearly demonstrated. By specifying a few typical patterns of value propagation, such as assignments and direct uses, we can inspire the LLMs to discover dataflow paths through the few-shot CoT prompting. This process does not require numerous rules specifying the dataflow facts induced by various program constructs, as the LLMs can capture the essence of the relationship between two values due to their exceptional generalization ability in code understanding.\n\n### **II. Other Concerns**\n**C1.Hallucinations of Path Feasibility Validation**\n\nAlthough the synthesized Z3 scripts may not correctly encode path conditions, we find that 78.57%, 88.68%, and 83.65% of them are correct in the DBZ, XSS, and OSCI detection, respectively. The most common reason for incorrect encoding is complex operations that appear in branch conditions, such as library functions.\n\nAnother point we want to make is that partially correct path encoding may be sufficient to filter out false positive bug reports. For example, the dataflow path for a false positive DBZ bug may not have all the path conditions correctly encoded. However, as long as the guard that checks the divisor not being zero is correctly encoded, Z3 can already rule out the bug report.  Several existing studies have also reported and utilized similar observations [R12, R13].\n\n**C2.External Function Call**\n\nHandling external function calls is a classic challenge in static analysis. In our work, LLMDFA validates a dataflow path based on the summaries generated in the second phase. Without the summaries of external functions, it can still discover dataflow paths formed by internal function calls (i.e., the functions available in the code base).\n\nBesides, for commonly used external function calls, such as standard library functions, LLMDFA can potentially understand the dataflow facts induced by their invocations. For example, when analyzing the project `samsapo` in TaintBench, LLMDFA encounters the following code snippet where the function `append` is a library function of the class `StringBuilder`. Due to the lack of its function body in the prompt, LLMDFA cannot summarize the dataflow facts for the callee function `append`. However, it can derive the dataflow summary from `str` to `stringBuilder`, which indicates that the value of the parameter `str` can propagate to the StringBuilder variable. This benefits from the ability of LLMs in code understanding, especially for the commonly used library functions.\n\n```\npublic static Fragment instantiate(Context context, String str, Bundle bundle) {\n    ...\n    stringBuilder = stringBuilder.append(str);\n    ...\n}\n```", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "UXpa4DArJ9", "reviewer": "Reviewer_ep1y", "summary": "The paper proposes LLMDFA, a compilation-free and customizable dataflow analysis, which takes a program and its CFG as input.\nThe authors decompose the problem into several subtasks including Source/Sink Extraction, Dataflow Summarization, and Path feasibility Validation, and introduce some strategies. They evaluate LLMDFA on synthetic programs to detect three representative types of bugs and on real-world Android applications for customized bug detection.", "questions": "- What is the cost of each part?\n- How much validation code using Z3 can be successfully generated? \n- Can the whole procedure be automated? Or how can the user be involved in LLMDFA?", "limitations": "The limitation has been discussed.", "rating": 6, "confidence": 4, "soundness": 2, "presentation": 3, "contribution": 3, "strengths": "+ easy to follow\n+ interesting idea\n+ impressive improvement\n\nThe presentation is easy to follow and the experiment results are impressive.", "weaknesses": "- some designs are not well-motivated \n- high cost \n\nI have some reservations about the efficacy and meaningfulness of employing Z3 for verification, especially considering the preceding processes are generated by LLMs, which might inherently carry some inaccuracies. It seems challenging to ascertain whether the results from the final Z3 verification justify the associated costs, given these potential uncertainties. When Z3 fails to verify, what is the possible fixing mechanism? How to locate the error? \n\nAdditionally, preparing code for Z3 verification involves intricate steps such as defining data types, data structures, and functions, and then also need to translate constraints into Z3's language. While I appreciate that the authors admit these challenges with illustrative examples shown in the appendix, the results presented in Table 1 are notably impressive. Could this suggest that the dataset primarily comprises simpler structures and operations? It would be enlightening if more detailed results for the specific tasks mentioned could be shared, beyond a general ablation study.\n\nFinally, comparing the costs of traditional methods and those involving LLMs directly can be quite complex. Including a more nuanced comparison of human effort and financial implications might provide clearer support for the strengths and contributions of the LLMDFA approach.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "### **Answers to Questions**\n\n**Q1. The costs of the three stages**\n\nPlease refer to the common concern in the global response.\n\n**Q2. The statistics and details of path feasibility validation**\n\nIn Appendix A.3.2, we demonstrate the detailed statistics of path feasibility validation. In our evaluation, we set the upper bound of the fixing number to three in the script program synthesis. According to Figure 13 (a), 75.20%, 96.43%, and 85.25% of scripts are synthesized using gpt-3.5 without any fixes in the DBZ, XSS, and OSCI detection. After feeding the error messages thrown by the Python interpreter iteratively, 99.39%, 96.43%, and 95.08% script programs can be synthesized within three fixes, respectively. For the remaining cases, which only take up 0.61%, 3.57%, and 4.92%, we leverage LLMs to directly determine whether the path is feasible or not. Similar observations can also be derived from the results when using other LLMs.\n\nWe also noticed that not all successfully synthesized scripts encode the path conditions correctly. We have shown three typical examples in Appendix A.4.2. We further investigated all the synthesized cases and found that 78.57%, 88.68%, and 83.65% of synthesized scripts encode the path conditions correctly. As pointed out by the reviewer, complex operations, such as library functions, can cause LLMs to fail to generate precise path conditions. \n\nLastly, it is worth mentioning that partially correct path encoding may be sufficient to filter out false positive bug reports. For example, the dataflow path for a false positive DBZ bug may not have all the path conditions correctly encoded. However, as long as the guard that checks the divisor not being zero is correctly encoded, Z3 can already rule out the bug report. Several existing studies have also reported and utilized similar observations [R12, R13].\n\n**Q3. User Interaction and financial cost**\n\nAs shown by the workflow in Figure 4, LLMDFA requires the users to provide a bug specification describing the forms of sources and sinks, few-shot examples containing sources and sinks, and ASTs generated by parsers. Then, the whole workflow can be fully automated without any human intervention. Specifically, the user can specify the bug specification and examples with little effort. In DBZ detection, for example, the user only needs to write six lines of the bug specification and five code examples. We asked five undergraduate students who had a background in Java programming to construct the prompts and found that their average time costs were only around five minutes.\n\nIn contrast, customizing the bug detection in a traditional compilation-based static analyzer often involves implementations with hundreds and even thousands of lines of code, which requires expert knowledge of compiler infrastructures, such as the LLVM infrastructure. The lack of customization support prevents the wide adoption of existing bug detectors, which is also stated by existing studies [R14].\n\nWe also measure the token costs of LLMDFA and further compute its financial costs of detecting different bug types. For more details, please refer to the response to the common concern in the global response.", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "dp7AasgeOS", "reviewer": "Reviewer_UBFi", "summary": "This paper proposes an LLM-based approach for detecting bugs with data flow analysis. The proposed approach LLMDFA consists of three parts: source/sinks extraction, dataflow summarization, and path feasibility validation. LLMDFA allows LLMs to interact with different program analysis tools. The authors conduct experiments on bug detection in both synthetic and real-world datasets.", "questions": "- Most baselines are non-deep-learning approaches. I wonder if there are any deep learning-based approaches previously proposed for similar bug detection tasks?\n\n- In my understanding, it is possible to write a single parser to extract the sources/sinks for all programs. What's the advantage in using LLM to generate different parsers for different programs? Also, I'd like to see more discussion on the impact of ASTs in source/sink extraction.\n\n- I’m a little confused about how the results of path feasibility validation can lead to the detection of bugs. Can the authors explain in more detail?", "limitations": "The limitations have been well-discussed.", "rating": 7, "confidence": 3, "soundness": 3, "presentation": 2, "contribution": 3, "strengths": "+The authors proposed an interesting approach for solving an important question in program languages. \n\n+LLMDFA decomposes bug detection into three steps, which are proven useful for complex data flow reasoning.\n\n+Experiments are conducted on both synthetic and real-world datasets.", "weaknesses": "-The results on synthetic datasets are very high, maybe the dataset is too easy?\n\n-All components in LLMDFA require multiple rounds of try-and-refine. It is better to discuss the cost of multiple-round generation.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "### **I. Answers to Questions**\n**Q1. Comparison with ML-based approaches**\n\nTargeting a compilation-free and customizable dataflow analysis, we have conducted a comprehensive survey of existing literature and have not encountered any ML-based approaches that specifically tackle the same problem as our research. The most related work is DeepDFA, which is cited in our paper as [25]. Specifically, DeepDFA introduces abstract dataflow embedding and applies a classification model to the embedding results for bug detection. By jointly training the embedding and classification models upon a large dataset containing targeted bugs, DeepDFA can obtain the capability of detecting the target bugs. Although it enables compilation-free analysis, it requires the training process to be repeated for individual dataflow analysis problems. Also, a large amount of training data may not be available for specific bug types. Hence, the lack of customization support limits the applicability of DeepDFA in real-world scenarios where flexible dataflow analysis requirements are necessary. These differences also prevent us from devising a fair empirical comparison between LLMDFA and DeepDFA.\n\nIn our evaluation, we hence choose few-shot CoT prompting as an LLM-based end-to-end solution that has the same assumptions as our technique. We acknowledge the Reviewer UBFi's suggestion to include further discussions on existing machine learning-based approaches in our paper. We will further add more justifications for the baseline choices in the evaluation section and compare LLMDFA with existing ML-based analysis from a methodological standpoint.\n\n**Q2. More details of source/sink extractor synthesis**\n\nFirst, as demonstrated in lines 169 and 170 in Section 3.1, we synthesize source/sink extractors for each bug type and apply them to different programs instead of synthesizing extractors for individual programs. If we target a specific bug type, the source/sink extractor synthesis is a one-time effort. The synthesized extractors can be deterministically applied to the target programs without introducing any hallucinations.\n\nSecond, manually specifying extractors requires the users to exhibit expert knowledge of compilation infrastructures, such as the tree-sitter parsing framework. Considering the tree-sitter-java supporting the parsing of Java programs, for example, 528 node types correspond to various Java constructs, such as call expressions and method declarations. Besides, these nodes exhibit diverse sets of child nodes. The intricacy of the parsing library poses a challenge for non-experts in manually creating extractors to cater to different analysis requirements.\n\nThird, the impact of source/sink extractor synthesis is demonstrated by our ablation study in Section 4.4. As shown in Figure 8, if we identify sources and sinks with LLMs directly instead of using synthesized extractors, the ablation, namely NoSynExt, yields a much lower precision, recall, and F1 score than full-featured LLMDFA. This indicates that the extractor synthesis enables us to mitigate the hallucinations in the source/sink extraction and eventually significantly improves the performance of the overall analysis. We also offer a concrete example in Appendix A.4.1 as a case study (See Case I) to show the spurious sources identified by LLMs while avoided by the synthesized extractors.\n\nWe appreciate Reviewer UBFi's comments on the source/sink extractor synthesis. We will include more discussions in our paper.\n\n**Q3. More details of path feasibility validation**\n\nThe path feasibility is a necessary condition of a dataflow path that may introduce a bug. As shown by the motivating example in Figure 1, the value of x at line 9 can be propagated to the argument z at line 13 and then propagated to the second parameter in the function foo. Furthermore, it is utilized at line 4 as a divisor. Such a dataflow path can be derived by concatenating the summaries of the two functions. However, it does not imply the bug’s existence, as the branch condition at line 3 is violated when the value is equal to 0. This means that we have to check the path feasibility after we concatenate the dataflow summaries obtained in the second stage. We will motivate the path feasibility validation with more explanations.\n\n### **II. Other Concerns**\n**C1. Dataset Details**\n\nJuliet Test Suite is a synthetic benchmark widely used for evaluating static analysis tools. The programs in the benchmark are relatively small. That said, it should be noted that the programs in Juliet Test Suite still exhibit complex features, such as complex path conditions, library function usage, and data structure usage. On the other hand, the programs in TaintBench are all real-world Android malware applications. Therefore, the high performance upon Juliet Test Suite and promising results upon TaintBench demonstrate the potential of LLMDFA in discovering dataflow facts for bug detection. \n\nDuring the response period, we further extended LLMDFA to support C/C++ and JavaScript analysis and meanwhile evaluated it upon three bug tracks in Juliet Test Suite for C/C++ and SecBench.js [R2]. The latter contains 138 bugs in real-world JavaScript programs, including command injection, taint path, and code injection vulnerabilities. Notably, many of the vulnerabilities have been assigned with CVE IDs due to their significant security impact. The results are shown in Table 9 and Table 10.\n\nThe above datasets cover different program domains, programming languages, and bug types. As demonstrated by empirical evaluation results, the satisfactory performance of LLMDFA can show its potential value in analyzing real-world programs in a compilation-free and customizable manner.\n\n\n**C2. Cost of LLMDFA**\n\nPlease refer to the common concern in the global response.", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}]

Author rebuttal:
We express our sincere gratitude to all the reviewers for their invaluable feedback and insightful questions. Prior to addressing each individual question and concern raised in the reviews, we present more experimental data, list several additional references, and address the common concerns of reviewers in the global response.

### **I. Additional Experimental Data**

We expanded the experiments during the rebuttal phase and uploaded a PDF file containing six tables as the attachment of this global response. To distinguish the tables from **Tables 1~4** in our original submission, the six tables are labeled with **Tables 5~10**. We will explain the additional experimental results in the individual responses.

### **II. Additional Reference**

In the responses, we will discuss the following papers, some of which are recommended by the reviewers.

[R1] Xia, Chunqiu Steven, et al. "Keep the Conversation Going: Fixing 162 out of 337 bugs for $0.42 each using ChatGPT", ISSTA 2024

[R2] Yiu Wai Chow, et al. "Beware of the Unexpected: Bimodal Taint Analysis", ISSTA 2023
 
[R3] Beurer-Kellner, et.al. "Prompting is programming: A query language for large language models”, PLDI 2023

[R4] Beurer-Kellner, Luca, et al. "Prompt Sketching for Large Language Models", ICML 2024.

[R5] Li, Kaixuan, et al. "Comparison and Evaluation on Static Application Security Testing (SAST) Tools for Java", FSE 2023.

[R6] Mordahl, Austin. "Automatic testing and benchmarking for configurable static analysis tools", ISSTA 2023.

[R7] Ami, Amit Seal, et al. False negative–that one is going to kill you: Understanding Industry Perspectives of Static Analysis based Security Testing", IEEE S&P 2024.

[R8] Liu Wang, et al. "MalRadar: Demystifying Android Malware in the New Era", Proc. ACM Meas. Anal. Comput. Syst. (June 2022)

[R9] Li, Haonan, et al. "Enhancing Static Analysis for Practical Bug Detection: An LLM-Integrated Approach", OOPSLA 2024.

[R10] Shi, Qingkai, et al. "Pinpoint: Fast and precise sparse value flow analysis for million lines of code", PLDI 2018.

[R11] Sui, Yulei, et al. "SVF: interprocedural static value-flow analysis in LLVM", CC 2016.

[R12] Cheng, Xiao, et al. "Fast Graph Simplification for Path-Sensitive Typestate Analysis through Tempo-Spatial Multi-Point Slicing", FSE 2024.

[R13] Das, Manuvir, et al. "ESP: Path-sensitive program verification in polynomial time", PLDI 2002.

[R14] Johnson, Brittany, et al. "Why don't software developers use static analysis tools to find bugs?", ICSE 2013

### **III. Common Concern**

Now, we address the common concerns of reviewers.

**C1. The costs of the three stages (Reviewer ep1y and Reviewer UBFi)** 

We measure the token cost of LLMDFA when analyzing each test program in Juliet Test Suite with different LLMs. In the following, we present the detailed statistics of the token cost of LLMDFA using gpt-3.5, including the input and output token costs of the three phases. The token costs when using the other three models are close to the following statistics.

**Cost of extractor synthesis:**

In the evaluation of extractor synthesis for each bug type, we repeated the experiment twenty times and measured the input and output costs in each round. As shown in Table 5, more than 90% of source extractors can be synthesized with no more than 4,000 input tokens except for the sink extractor synthesis for the OSCI bug detection. Besides, LLMDFA has to iteratively fix the synthesized scripts eleven times in an extreme case when synthesizing the source extractor for the DBZ detection, which introduces a relatively high token cost. However, such extreme cases do not frequently happen in our evaluation. The sub-column $p_{0.9}$ of the column *Input Token Cost* demonstrates the low input token cost of LLMDFA in most cases. We can derive similar observations on the output token cost from Table 5. According to the pricing policy of OpenAI, we obtain the average financial cost of synthesizing source/sink extractor for each bug type in Table 7.

**Cost of dataflow summarization and path feasibility validation:**

Table 6 shows the per-test input/output token costs in the dataflow summarization and path feasibility validation, respectively. Specifically, the token costs are higher in the DBZ detection than the ones in the XSS and OSCI detection. The reason is that the programs containing XSS and OSCI bugs have fewer sources and sinks than the ones containing DBZ bugs. Hence, LLMDFA prompts the LLM fewer times in the XSS and OSCI detection. Similar to the extractor synthesis, we can find that LLMDFA consumes more tokens in a small proportion of cases than the others. In 90% of cases, the input and output token costs of the dataflow summarization do not exceed 24,000 and 800, respectively, while input and output token costs of the path feasibility validation do not exceed 10,000 and 3,000, respectively. Notably, the input token costs in the dataflow summarization are mainly caused by the examples with explanations used for few-shot CoT. Also, the input token costs in the path feasibility validation are mainly introduced by the description of path information and hints for path constraint encoding. Finally, we compute the average per-test financial cost of the last two phases, which are shown in Table 8.


**Overall cost:**

By adding up the costs shown in Table 7 and Table 8, the average financial cost of the DBZ, XSS, and OSCI detection is 0.14 USD, 0.05 USD, and 0.04 USD, respectively. Such a cost is in line with works of a similar nature, such as [R1], which takes 0.42 USD to repair a bug. Notably, the extractor synthesis is one-time for a given bug type. Hence, the financial cost of the detection in practice is even lower.

In our implementation, LLMDFA invokes the online models via OpenAI APIs. The time cost of the LLM inference can be affected by many factors, such as network status, server scheduling, and runtime traffic. Hence, we do not measure LLMDFA's time overhead.

Meta-review: I propose to accept this paper

Strengths:

- Application of LLM in Code Analysis: LLMDFA effectively uses LLMs for code dataflow analysis in bug detection.
- Novel Approach: The three-stage process of source/sink extraction, dataflow summarization, and path feasibility validation
- Promising Results: The approach showed high precision and recall in experiments, outperforming existing baselines and demonstrating potential for real-world applications.
- Customization: LLMDFA's compilation-free design allows it to be adapted to different programming languages with small effort.
- Good Presentation and Structure: The methodology and motivation were clearly articulated, and the empirical evaluation was comprehensive.

Weaknesses:

 - Limited Generalizability: The experiments were only conducted on the Java programming language, raising concerns about the generalizability of the method to other languages.
- Potential for Hallucinations: LLMDFA may still suffer from hallucinations, particularly in dataflow summarization, which could lead to incorrect results.
- Small Dataset: The limited size of the experimental dataset (only 37 programs) could introduce bias, suggesting the need for validation with larger datasets.
- High Cost: The multi-round process required in LLMDFA, particularly in synthesizing scripts for Z3 verification, raised concerns about the cost and efficiency of the approach.

The authors addressed the weaknesses identified by the reviewers as follows:

- Limited Generalizability: During the rebuttal phase, the authors extended LLMDFA to support C/C++ and JavaScript languages and presented additional experimental results, which showed comparable performance to the original Java experiments.

- Potential for Hallucinations: The authors provided detailed statistics on hallucinations and demonstrated that their approach significantly mitigates this issue. They also explained how partially correct path encodings could still filter out false positives, thereby maintaining the effectiveness of the approach.

- Small Dataset: The authors justified the use of the small dataset by pointing to its complexity and relevance in static analysis benchmarks. They also extended their evaluation to other datasets, such as SecBench.js, during the rebuttal phase.

- High Cost: The authors provided a breakdown of the costs associated with each stage of LLMDFA, demonstrating that the financial costs are in line with similar works. They also discussed the potential for further optimization and emphasized the benefits of LLMDFA's customization capabilities.

Overall, the authors' rebuttal successfully addressed most of the reviewers' concerns, leading to an improvement in the reviewers' assessments.
Decision: Accept (poster)