IRIS: LLM-Assisted Static Analysis for Detecting Security Vulnerabilities
Authors: Ziyang Li
Saikat Dutta
Mayur Naik
Venue: ICLR 2025 Poster (2025)
Keywords: Neuro-Symbolic
Program Analysis
Security Vulnerability
LLM
Primary area: neurosymbolic & hybrid AI systems (physics-informed, logic & formal reasoning, etc.)
TL;DR: We present IRIS, a static analysis tool assisted by LLM, that outperforms existing static analysis tools on whole-repository vulnerability detection

Abstract: Software is prone to security vulnerabilities. Program analysis tools to detect them have limited effectiveness in practice due to their reliance on human labeled specifications. Large language models (or LLMs) have shown impressive code generation capabilities but they cannot do complex reasoning over code to detect such vulnerabilities especially since this task requires whole-repository analysis. We propose IRIS, a neuro-symbolic approach that systematically combines LLMs with static analysis to perform whole-repository reasoning for security vulnerability detection. Specifically, IRIS leverages LLMs to infer taint specifications and perform contextual analysis, alleviating needs for human specifications and inspection. For evaluation, we curate a new dataset, CWE-Bench-Java, comprising 120 manually validated security vulnerabilities in real-world Java projects. A state-of-the-art static analysis tool CodeQL detects only 27 of these vulnerabilities whereas IRIS with GPT-4 detects 55 (+28) and improves upon CodeQL's average false discovery rate by 5% points.
Furthermore, IRIS identifies 4 previously unknown vulnerabilities which cannot be found by existing tools. IRIS is available publicly at https://github.com/iris-sast/iris.

Published as a conference paper at ICLR 2025
IRIS: LLM- STATIC ANALYSIS FOR DETECTING SECURITY VULNERABILITIES
Ziyang Li
Saikat Dutta
Mayur Naik
University of Pennsylvania liby 900ci, upenn. edu
Cornell University
University of Pennsylvania
kat.@ccoreell edu
mhna kêci upenn edu
ABSTRACT
Software is prone to security vulnerabilities. Program analysis tools detect them have limited effectiveness in practice due to their reliance on human labeled specifications. Large language models (or L.LMs) have shown impressive code generation capabilities but they cannot do complex reasoning over code to detect such vulnerabilities especially since this task requires whole-repository analysis. We propose IRIS, heuro-symbolic approach that systematically combines LLMs with static analysis to perform whole-repository reasoning for security vulnera- bility detection. Specifically, IRIS leverages LLMs infer taint specifications and perform contextual analysis, alleviating needs for human specifications and compris- inspection. For evaluation, curate new dataset, CWE-Bench-Jane ing 120 manually validated security vulnerabilities in wolld Java projects. A ofate-of-the-an static analysis tool CodeQL detects only 27 of these vulnerabilities whereas IRIS with GPT-4 detects 55 (+28) and improves upon CodeQL's average false discovery rate by 5% points. Furthermore, IRIS identifies previously un- known vulnerabilities which cannot be found by existing tools. IRIS is available publicly potttp:://githne com/ iris sast/iris
INTRODUCTION
Security vulnerabilities pose a major threat to the safety of software applications and its users. In 2023 alone, more than 29,000 CVEs were reported-almost 4000 higher than in 2022 (CVE Trends). Detecting vulnerabilities is extremely challenging despite advances in techniques to uncover them. promising such technique called static taint analysis is widely used in popular tools such GitHub CodeQL (Avgustinov et a 20166. Facebook Infer (FB Infer), Checker Framework (Checker Frame- work), and Snyk Code (Snyk.io). These tools, however, face several challenges that greatly limit their effectiveness and accessibility in practice.
Repository
Vulnerable Paths
!
Vulnerability Explanation
src/main/
Spark.java
othorres (ClassPothesourree) 0b1;
Vulnerable: CWE-22: user-controlled input from
README.mo mmd
Service.jave
B Access.jave
Handler,java
pathinfo request get get Pathinfo();
IRIS
Ht Htrereee BeteerreeReeuueee which common source taint. The sink method that potentially tainted path retrieve resource, which could lead to Peth Traversel..
AVB. >008k lines of code
requast giutttri ...
!
CWE Information
Interim Stops without Sanitiration...
Path-Traversal
Improper Limitation Restricted Directory: product uses external Input to construct pathneme...
<>>
CasssPahhResouros java
Sink
clazz, Besour cedud (pa
Figure I:
Overview of the IRIS neuro-symbolic system. It checks given whole repository for given type of vulnerability (CWE) and outputs set of potential vulnerable paths with explanations.
False negatives due to missing taint specifications of third-party library APIs. First, static taint analysis predominantly relies on specifications of third-party library APIs as sources, sinks, or sanitizers. In practice, developers and analysis engineers have manually craft such specifications based on their domain knowledge and API documentation. This a laborious and error- process that often leads missing specifications and incomplete analysis of vulnerabilittis. Further,

---

Published as a conference paper at ICLR 2025
even if such specifications may exist for many libraries, they need to be periodically updated to capture changes in newer versions of such libraries and also cover new libraries that are developed.
False positives due to lack of precise context-sensitive and intuitive reasoning. Second, it is well-known that static analysis often suffers from low precision, i.e., may generate many false alarms (Kang et al. 2022, Johnson et al. (2033). Such imprecision stems from multiple sources. For instance, the source or sink specifications may be spurious, or the analysis may operaappro over branches in code or possible inputs. Further, even if the specifications are correct, the context in which the detected source or sink used may not be exploitable. Hence, a developer may need to triage through several potentially false security alerts, wasting significant time and effort.
L Limitations of prior data-driven approaches to improve static taint analysis. Many techniques have been proposed to address the challenges of static taint analysis. For instance, [ivshits et al.) (2009) proposed probabilistic approach, MERLIN, to automatically mine taint specifications. A more recent work, Seldon (Chibotaru et al., 2019), improves the scalability of this approach by formulating the taint specification inference problem as linear optimization task. However, such approaches rely on analyzing the code of third-party libraries to extract specifications, which is ex- pensive and hard to scale. Researchers have also developed statistical and learning -aaee techniques to mitigate false positive alerts (Jung et al. 2005 Heckman & Williams] 2009 / Hanam et al. 2014).
However, such approaches still have limited effectiveness practice (Kang et al. (0022).
Large Language Models (or LLMs) have made impressive strides in code generation and summa- rization. LLMs have also been applied to code related tasks such as program repair (Xia et al.) 2023), code translation (Pan et al. 2024), test generation (Lemieux al. 2023), and static analy- sis (Li et al.] 2024). Recent studies (Steenhoek et al., 2024] Khare et al. 2023 evaluated LLMs' effectiveness at detecting vulnerabilities at the method level and showed that LLMs fail to do com- plex reasoning with code, especially because it depends on the context in which the method is used in the project. On the other hand, recent benchmarks like SWE-Bench (Jimenez al. 2023) show that LLMS are also poor at doing project-level reasoning. Hence, an intriguing question is whether LLMs can be combined with static analysis to improve their reasoning capabilities. In this work, we answer this question in the context of vulnerability detection and make the following contributions:
Approach. We propose IRIS, a neuro-symbolic approach for vulnerability detection that combines the strengths of static analysis and LLMs. Fig. [ presents an overview of IRIS. Given a project to analyze for given vulnerability class (or CWE), IRIS applies LLMs for mining CWE-specific taint specifications. IRIS augments such specifications with CodeQL, a tool for static taint analysis. Our intuition here is because LLMs have seen numerous usages of such library APIs, they have an understanding of the relevant APIs for different CWES. Further, to address the imprecision problem of static analysis, we propose a contextual analysis technique with LLMs that reduces the false positive alarms and minimizes the triaging effort for developers. Our key insight is that encoding the code-context and path- seth-sensitive information the prompt elicits more reliable reasoning from LLMs. Finally, our neuro-symbon seuro-symbolic approach allows LLMs to do more precise wholc-repository reasoning and minimizes the human effort involved in using static analysis tools.
Dataset. We curate a dataset of manually vetted and compilable Java projects, (We-Bench-Java, containing 120 vulnerabilities (one per project) across four common vulnerability classes. The projects in the dataset are complex, containing 300K lines of code on average, and 10 projects with more than million lines of code each, making it a challenging benchmark for vulnerability detection. The dataset and the corresponding scripts to fetch, build, and analyze the Java projects are available publicly at
htw.tttoooooooooeeeeee iris sast sawe beeeheeechhhee java
Results. We evaluate IRIS on CWWF-Bncc-Jaay using diverse open- and closed-source L.Mss. Overall, IRIS obtains the best results with GPT-4, detecting 55 vulnerabilities, which is 28 (103.7%) more than CodeQL, the existing best-perfore pest-performing static analyzer. We show that the increase is not at the expense of false positives, as IRIS with GPT-4 achieves average false discovery rate of 84.82% which is 5.21% 21% lower than that of CodeQL. Further, when applied to the latest versions of 30 Java projects, IRIS with GPT-4 discovered 4 previously unknown vulnerabilities.
2

---

Published as a conference paper at ICLR 2025
B
E cronutiis/ proortis/prree///rooaaasrraava
Poverrida
Perse string with eron ex Dssion
public 1eaan 1sValid(
public Cron parse( se(final Strang expression)
String Value, tonstrainntellsdatoroontet context)
{ */ catch threw new IllegalaguneEEeeettiin formaat "Failled to parse "ts'. 3s", expression, e.getNessage()), e);
cronParser. pww.ppreeeeeeeeeeeee. velidar
catch (#1legaarrguennteeeppto
context
busilfonsttraannioolatinnttt wwmpllatttttttttteetcccm gegteessgge addioonstranntVollaattnn))
Figure 2: An example of Code Injection (CWE-94) vulnerability found in cron-utils (CVE-2021- 41269) that CodeQL fails to detect. We number the program points of the vulnerable path.
MOTIVATING EXAMPLE
We illustrate the effectiveness of IRIS in detecting a previously known code-injection (CWE- 094) vulnerability in cron-utils (ver. 9.1.5), a Java library for Cron data manipulation. Fig. 2 shows the relevant code snippets. A user-controlled string value passed into isValid function is transferred without sanitization to the parse function. If an exception is thrown, the function constructs an error message with the input. However, the error mes- sage is used to invoke method mulicoonstrriiitooolaiiio Templllaaatteee of class Const r i i idiitrCoottteettttce in javax. wawaa..alllaaoo waw.vvalattt. idator, which interprets the message string Java Expression Language (Java EL) expression. A malicious user may exploit this vulnerability by crafting a string containing a shell command such as (') delete critical files on the server.
( 'rm -rf
Detecting this vulnerability poses several challenges. First, the cron-utils library consists of 13K SLOC (lines of code excluding blanks and comments), which needs to be analyzed to find this vulnerability. This process requires analyzing data and control flow across several internal meth- ods and third-party APIs. Second, the analysis needs identify relevant sources and sinks. In this case, the vue parameter of the public ssvalie method may contain arbitrary strings when invoked, and hence may be a source of malicious data. Additionally, external APIs like bui www.onoottaattiiiioiio
can execute arbitrary Java EL expressions, hence they should be treated as sinks that are vulnerable to Code Injection attacks. Finally, the analysis also requires identifying any sanitizers that block the flow of untrusted data.
Modern static analysis tools, like CodeQL, are effective at tracing taint data flows across complex codebases. However, CodeQL fails to detect this vulnerability due to missing specifications. Cod- eQL. includes many manually curated specifications for sources and sinks across more than 360 popular Java library modules. However, manually obtaining such specifications requires significant human effort to analyze, specify, and validate. Further, even with perfect specifications, CodeQL. may often generate numerous false positives due lack of contextual reasoning, increasing the developer's 's burden of triaging the results.
In contrast, IRIS takes different approach by inferring project- and vulnerability-speeffee specifica- tions on-the-fly by using LLMs. The LLM-based components in IRIS correctly identify the untrusted source and the vulnerable sink. IRIS augments CodeQL with these specifications and successfully detects the unsanitized dataflow path between the detected source and sink in the repository. How- ever, augmented CodeQL produces many false positives, which are hard to eliminate using logical rules. To solve this challenge, IRIS encodes the detected code paths and the surrounding context into a simple prompt and uses an LLM to classify it as true or false positive. Specifically, out paths reported by static analysis, 5 false positives are filtered out, leaving the path in Fig, as one of the final alarms. Overall, we observe that IRIS can detect many such vulnerabilities that are beyond the reach of CodeQL-like static analysis tools, while keeping false alarms to a minimum.
IRIS FRAMEWORK
At a high level, IRIS takes a Java project P. the vulnerability class to detect, and a large language model LLM, inputs. IRIS statically analyzes the project P, checks for vulnerabilities specific to C, and returns a set of potential security alerts A. Each alert is accompanied by a unique code path from taint source to taint sink that is vulnerable to C (i.e., the path is unsanitized).
3

---

Published as a conference paper at ICLR 2025
Section 3.2
Section 3.3
Section 3,4 Static Taint Analysis
Section 3.5 Contextual Analysts
Candidate Extractor
Label Source/Sinkss
External API Candidates
API Labelo
package
class
nee thod
type
target
+
Data-Flow Path
! Vulnerability Analysis
30
oejectInoutStrrca
jeod
return-valuw
boolean Levoliol String value, -)
C Is Vulnerable: The Source is user input buing parsed validated,
Javax. va. ConstraintVelsdb.
buildbonstra.
mink
argueens[M]
Cron parset String eepr)
excepttio with controlled message. The sink is uaing the exception message in potentially used ssscuttion, watielying the crtaria for Cade pectionn vuluurabiiity (CWE- 094).
Internal Function Param Candidates
Function Param Labols
clase
eethed documettation
type
target
throw illagulA.
FieldExpression
accept "Accopt visitor_"
parameter
context doconarra Teeplate(e (1)
GronParser
parse
"Parse strinng"
paraector|
Figure 3: An illustration of the IRIS pipeline.
As illustrated in Fig. IRIS has four main stages: First, IRIS builds the given Java project and uses static analysis to extract all candidate APIs, including invoked external APIs and internal function parameters. Second, IRIS queries an LLM to label these APIS as sources or sinks that are specific to the given vulnerability class C. Third, IRIS transforms the labeled sources and sinks into spec- ifications that can be fed into a static analysis engine, such as CodeQL, and runs a vulnerability class-specific taint analysis query to detect vulnerabilities of that class in the project. This step gen- erates a set of vulnerable code paths (or alerts) in the project. Finally, IRIS triages the generated alerts by automatically filtering false positives, and presents them to the developer.
3.1 PROBLEM STATEMENT
We formally define the static taint analysis problem for vulnerability detection. Given project P. taint analysis extracts an inter-procedugy data flow graph G (V, E), where V is the set of nodes representing program expressions and statements, and E C V x V is the set of edges representing data or control flow edges between the nodes. A vulnerability detection task comes with two sets vC yoweer S V, VC S V that denote source nodes where tainted data may originate and sink nodes sink
where a security vulnerability can occur if tainted data reaches it, respectively. Naturally, different classes C of vulnerabilities (or CWEs) have different source and sink specifications. Additionally, there can be sanitizer specifications, VC sumitizer E V, that block the flow of tainted data (such as
escaping special characters in strings).
The goal of taint analysis is to find pairs of sources and sinks, (V. VC Visuncer V3 E V such that there is an unsanitized path from the source to the sink. More formally, Unsanitized Paths(Vs Vs, Vi) = 3 Path(V V. Vi) s.t. VV, Path Vs, Vo), Vn VC sonitizr- Here, Path(Vi, Vz) denotes sequence of nodes (V1, Vi,.... Vi), such that Vú E V and Vi E to 1: (v,, ";+1) E E.
Two key challenges in taint analysis include: 1) identifying relevant taint specifications for each class C that can be mapped to VC sink for any project P, and 2) effectively eliminating false positive paths in Unsamitized Paths( V., Vz) identified by taint analysis. In the following sections, we discuss how we address each challenge by leveraging L.MSs
3.2 CANDIDATE SOURCE/SINK EXTRACTION
A project may use various third-party APIs whose specifications may be unknown-redducin the effectiveness of taint analysis. In addition, internal APIs might accept untrusted input from down- stream libraries. Hence, our goal to automatically infer specifications for such APIs We define specification SC as 3-tuple (T, F, R), where T E (ReturnValuee Argument, Parameter,... is the type of node to match in C. F an N-tuple of strings describing the package, class, method name, signature, and angument/parameter position (if applicable) of API, and R (Source, Sink, Srdint-Propggaton Sanitizer} is the role of the API. For example, the specification (Argument, (java. ang, Runt i me, exec, (String ng [] 0), Sink) denotes that the first argu- ment of exec method of Runt i me class is a sink for vulnerability class (OS command injection). source VC in G.
A static analysis tool maps these specifications to sets of nodes VC
To identify taint specifications SC Suree and SC we first extract Sext, external library APIs that are invoked in the given Java project and are potential candidates to be taint sources or sinks. We also extract Sint internal library APIs that are public and may be invoked by downstream library. We
4

---

Published as a conference paper at ICLR 2025
+ User Prompt
Information
Analyze the following dataflow path in Jave-prōjct and predict whether it contains Cade-Injection vulnerabilaty (CME-094), or a relevant wulnerability. Please note that injection of malicious expression night lead to arbitrary code execution well.
Response (GPT-4)
"explanstion": 'The source is input being parsed and validated, which common entry point for tainted data. The sink is an error nessage being used in a way that could potentially be executed downstrean code, fitting the oriteria
Source (expression : string):
Context surrounding the source
Large Langer age Model (2e) pero--a S0
public class CronParser
public Cron parse(String expression) Preconditions cheiklotlllllexpr
SOURCE
Marking source location comment
Steps:
CME-094 vulnerability if the error nessage 1s mishandled. However, without evidence of the error nessage being executed, it's speculative to confirn vulnerability solely based on this dataflow.", "source_is, www.esll..aa....eeeeeeeeeeeeeees fasste. false, "sink_is, is, fannk_is__lle__pppp folse_positive": false, "is, 'is.vulnerable": true
(cronParser.jaaa]] String rep expr.replaccl Step
Intermediate Steps
Sink (getNessage(... ..)....)) :]):
public class CronValidator implenents ComstraintValidator public boolean isValad(String value,... ...)
Context surrounding
catch (IllegalArg ctx. wwwabbeeeeaaulCoot. fcy [ www.d.lldee.e.. etx.build-ee.getfeeeee (et.geefessageee))) ad)Co_(); //
sink
SINK
return false:
Marking exact sink
location in comment
LLM user prompt and response for contextual analysis of dataflow paths. In the user prompt, we mark with color the CWE and path information that is filling the prompt template. For cleaner presentation, we modify the snippets and left out the system prompt.
Figure 4:
use CodeQL to extract such candidates and their corresponding metadata such as method name, type signature, enclosing packages and classes, and even JavaDoc documentations, applicable.
3.3 INFERRING TAINT SPECIFICATIONS USING LLMS
We develop an automated specification inference technique: LabelSpecs((*t LLM,CCC = Sh where S# = gext U Sint are candidate specifications for sources and sinks. In this work, we do consider sanitizer specifications, because they typically do not vary for the vulnerability classes that we consider. We use LLMS to infer taint specifications. Specifically, external APIs in S can be classified as either source or sink, while internal APIs in Sint can have their formal parameters identified as sources. In the Appendix, we show the user prompts for inferring source and sink specifications from external APIs and internal function formal parameters.
Due to the sheer number of APIs to be labeled, we insert a batch of APIs in a single prompt and ask the LLM to respond with JSON formatted strings. The batch size is a tunable hyper-parameter. We adopt few-shot (usually 3-shot) prompting strategy for labeling external APIs, while zero-shot used for labeling internal APIs. Notably for internal APIs, we also include information from repository readme and JavaDoc documentations, if applicable. In practice, we find that this extra information helps LLM understand the high-level purpose and usage of the codebase, resulting in better labeling accuracy. At the end of this stage, have successfully obtained St: Soorre and sink which are going to be used by the static analysis engine in the next stage.
3.4 VULNERABILITY DETECTION
Once we obtain all the source and sink specifications from the LLM, the next step is combine with a static analysis engine to detect vulnerable paths, i.c., Unsanitized Paths (V.. Vi), in given project. In this work, we use CodeQL. (GitHub) 2024a) for this step. CodeQI. represents programs as data flow graphs and provides query language, akin to Datalog (Smaragdakis & Bravenboer, 2010), to analyze such graphs. Many security vulnerabilities can be modeled using queries written in CodeQL and can be executed against data flow graphs extracted from such programs. Given data flow graph GP of a project P. CWE-specificc source and sink specifications, and query for a given vulnerability class C, CodeQL returns set of unsanitized paths in the program. Formally,
CodeQL(GP, SC SC Sinke Query = {Path ..... P.thy.
CodeQL itself contains numerous specifications of However, as we show later in our evaluation, despite having such specialized queries and extensive specifications, CodeQL fails to detect majority of vulnerabilities in real-worke projects. For our
APIs for each vulnerability class.
5

---

Published as a conference paper at ICLR 2025
analysis, write specialized CodeQL query for each vulnerability that uses mined specifica- tions instead of those provided by CodeQL. Details of our queries are described in the Appendix.
3.5 TRIAGING OF ALERTS VIA CONTEXTUAL ANALYSIS
Inferring taint specifications only solves part of the challenge. We observe that while LLMs help uncover many new API specifications, sometimes they detect specifications that are not relevant to the vulnerability class being considered, resulting in too many predicted sources or sinks and consequently many spurious alerts as a result. For context, even few hundred taint specifi- cations may sometimes produce thousands of Unsamitized Paths(P Vs, Vt) that a developer needs to triage. To reduce the developer burden, we also develop LLM-based filtering method, FilterPath(Pathy G, LLM, C) = True|Faise that classifies a detected vulnerable path (Path) in G as a true false positive by leveraging context-based and natural language information.
Fig. presents an example prompt for contextual analysis. The prompt includes CWE information and code snippets for nodes along the path, with an emphasis the source and sink. For the intermediate steps, we include the file names and the line of code. When the path is too long, we keep only a subset of nodes limit the size of the prompt. More details and design decisions of this prompt are described in the Appendix. We expect the LLM to respond in JSON format with the final verdict as well an explanation to the verdict. The JSON format prompts the LLM generate the explanation before delivering the final verdict. as presenting the judgment after the reasoning process is known to yield better results. In addition, if the verdict is false, we ask the LLM to indicate whether the source or sink is a false positive, which helps to prune other paths and thereby save on the number of calls to the LLM.
3.6 EVALUATION METRICS
We evaluate the performance of IRIS and its baselines using three key metrics: number of vulner- ability detected (#Detected), average false discovery rate (AvgFDR), and average FL (AvgFI). For ovaluation, we assume that we have a dataset D = [P....... P.. where each P. is a Java project, and known to contain at least one vulnerability. The label for project P is provided as a of crucial program points V = (Vi,-... V.} where the vulnerable paths should pass through, indicated by Path vul * 0. In practice, these are typically the patched methods that can be collected from each vulnerability report. If at least one detected vulnerable path passes through fixed location for the given vulnerability, then we consider the vulnerability detected. Let Paths" ? be the set of detected paths for each project P from prior stages. The metrics are formally defined as follows:
#VulPath(P) = Patth E Paths" Path n V + 0}}, #Deiected(D) = EreD Rec(P),
Rec(P) LoValPathi P)>0>
Prec(P) (P) = Patth"" Av) DDT
&VulPathh P))
AD) = INSrED./PudtPPdd
Prec(P),
EreD
2-Procl P)) (ec(P) Prec(P)+RccC)
Specifically, a lower AvgFDR is preferable, as it indicates a lower ratio of false positives. We note that Prec(P) might sometimes be undefined due to wwvision-b-zzere if the detection tool retrieves no path (Pathss = 0). Therefore, for AvgFDR to be meaningful, we only consider the projects where at least one positive result is produced (Patths P| > 0). AvgFI avoids this issue since Rec(P) = 0 when no positive labels exist, forcing the Fl term to be zero regardless of Prec(P).
4 CWE-BENCH-JAVA: A DATASET OF SECURITY VULNERABILITIES IN JAVA
To evaluate our approach, we require dataset of vulnerable versions of Java projects with several important characteristics: 1) Each benchmark should have relevant vulnerability metadata, such as the CWE ID, CVE ID, fix commit, and vulnerable project version, 2) each project in the dataset must be compilable, which is a key requirement for static analysis and data flow graph extraction, 3) the projects must be real-world, which are typically more complex and hence challenging to analyze compared to synthetic benchmarks, and 4) finally, each vulnerability and its location (e.g., method) in the project must be validated so that this information can be used for robust evaluation of vulnerability detection tools. Unfortunately, no existing dataset satisfies all these requirements.

---

Published as a conference paper at ICLR 2025
Select Vul Classes
Fetch Vulnerabiltiie
Obtain Git Info
CWE-22:
Pach-Treversal
GitHub Advisory Database
librarics.io
Li Statistics
CWE 78: OS Command Injoction
CWE 79: Cross Site Scripting
WWE-94: Code Injection
Octain CVE, CWE, MAVEN Pkc.
GitHun URL,
RCVE: 1065
GitHub vulnerable
fix
CVV:: 430
Num Vuis: 120
CWE-22: 55
CWE-78: 13
CWE-79: 31
Cross-Validate Fixes
Build and Compile
Manual Checks
CWE-94:
enyk.io
some java Addling fix information and foxing commits
Menually spedif Java and MAVEN versions
MAVEN build
CWE dlassifeed correctlly
Vulnerability not dependency
Protect
300K
Manually label vuinerable code
CVE: 120
Figure 5: Steps for curating CWE-Bench- and dataset statisties.
To address these requirements, curate our dataset of vulnerabilities. For this paper, focus only on vulnerabilities in Java libraries that are available via the widely used Maven package manager. We choose Java because it is commonly used develop server-side, Android, and web applications, which are prone to security risks. Further, due to Java's 's long history, there are many existing CVEs in numerous Java projects that available for analysis. We initially use the GitHub Advisory database (GitHub, 2024b| c) to obtain such vulnerabilities, and further filter it with cross- validated information from multiple sources, including manual verification. Fig. illustrates the complete set of steps for curating CWE-Bench-Jvaa.
As shown in the statisties (Fig. 5 the sheer size of these projects make them challenging to ana- lyze for any static analysis tool or ML--based tool. Each project in CWF-Bench-Java comes with GitHub information, vulnerable and fix version, CVE metadata, a script that automatically fetches and builds, and the set of program locations that involve the vulnerability.
5 EVALUATION
We perform extensive experimental evaluations of IRIS and demonstrate its practical effectiveness in detecting vulnerabilities in real-world Java repositories in results and analyses are provided in the Appendix, we address the following key research questions:
While additional
RQ 1: How many previously known vulnerabilities IRIS detect?
RQ 2: Does IRIS detect new, previously unknown vulnerabilities?
RQQ 3: How good are the inferred source/sink specifications by IRIS?
RQ 4: How effective are the individual components of IRIS?
5.1 EXPERIMENTAL SETUP
We select two closed-source LLMs from OpenAI: GPT-4 4pt-4-01255-p-reviee and GPT-3.5 (gpt-3.
for our evaluation. We also select instruction-tunel versions of four open-source LLMs via huggingface API: Llama (L3) 8B and 70B, Qwen-2.5-Coder (Q2.5C) 32B, Gemma-2 (G2) 27B, and DeepSeekCoder (DSC) 7B. For the CodeQL baseline, we use version 2.15.3 and its built-in Security queries specifically designed for each CWE. Other baselines included Facebook Infer (FB Infer), SpotBugs (Lavazza et al. 2020), and Snyk (Snyk.io). We expand further on the other experimental setups in the Appendix.
5.2 RQI: EFFECTIVENESS OF IRIS ON DETECTING EXISTING VULNERABILITIES
The results in Table 1 highlight IRIS's superior performance compared to CodeQL. Specifically, IRIS, when paired with GPT-4, identifies 55 vulnerabillties-22 more than CodeQL. While GPT-4 shows the highest efficacy, smaller, specialized LLMs like DeepSeekCoder 7B still detect 52 vul- nerabilities, suggesting that our approach can effectively leverage smaller-scale models, enhancing accessibility. Notably, this increase in detected vulnerabilities does not compromise precision, as evidenced by IRIS's lower average false discovery rate (FDR) with GPT-4 compared to CodeQL. Moreover, IRIS improves average Fl by 0. reflecting a better balance between precision and re- call. We note that the reported average FDR is coarse measure our metrics may consider true (but unknown) vulnerability found by IRIS as a false positive. Hence, the reported FDR is an upper bound. To get better sense of detection accuracy, by IRIS (using GPT-4) and found that 27/50 alarms exhibit potential attack surfaces, yielding a more refined estimated false discovery rate 46%. Hence, IRIS will likely be more effective in practice.
manually analyzed 50 random alarms reported
7

---

Published as a conference paper at ICLR 2025
Table 1: Overall performance comparison of CodeQL vs IRIS on Detection Rate (f), Average FDR ()), and Average F1 (1). We present results of IRIS with LLMs including GPT-4 and GPT-3.5, L3 8B and 70B, Q2.5C 32B, G2 27B, and DSC 7B.
Method
#Detected (/120)
Detection Rate (%)
Avg FDR (%)
Avg Score
CodeQL
27
22.50
90.03
0.076
GPT-4
55 28)
45.83 (1 23.33)
84.82 (L 5.21)
0.177 (1 0.101)
GPT-3.5
47 (1 20)
39.17 (f 16.67)
90.42 (1 0.39)
0.096 (1 0.020)
L3 8B
41 (1 14)
34.17 (f 11.67)
95.55 (1 5.52)
0.058 (L 0.018)
IRIS+ +
L3 70B
54 (1 27)
45.00 (1 22.50)
90.96 (1 0.93)
0.113 (1 0.037)
Q2.5C:328 32B
47 (1 20)
39.17 (1 16.67)
92.38 2.35)
0.097 (1 0.021)
G2 27B
45 18)
37.50 (T 15.00)
91.23 1.20)
0.100 (1 0.024)
DSC 7B
52 (1 25)
43.33 (1 20.83)
95.40 (1 5.37)
0.062 (L 0.014)
Table presents a detailed breakdown of detected vulnerabilities, comparing IRIS against various baselines. With the exception of IRIS using Llama-3 8B, which underperforms in detecting CWE-22 vulnerabilities, IRIS consistently outperforms all other baselines. Notably, CWE-78 (OS Command Injection) remains particularly challenging for all LLMs. Our manual investigation revealed that the vulnerability patterns in CWE-78 are highly intricate, often involving OS command injections via gadget-chains (Cao et al., 2023) or external side effects, such file writes, which are difficult to track using static analysis. This highlights the inherent limitations of static analysis, as opposed to dynamic approaches an area that we leave for future work.
5.3 RQ2: PREVIOUSLY UNKNOWN VULNERABILITIES BY IRIS
We applied IRIS with GPT-4 to the latest versions of 30 Java projects. Among the 16 inspected projects where IRIS raised at least one alert, we identified 4 vulnerabilities, including instances of path injection (CWE-22) and one case of code-injection (CWE-94). To ensure that these vulnera- bilities were indeed uncovered due to IRIS's integration with LLMs, verified that CodeQL alone did not detect them. We highlight one such vulnerability in Fig. g CodeQL. was unable to detect this issue due to missing source specification, while GPT-4 successfully flagged the API endpoint restoreF rowCheckpooooooooooocoooooooopo int as a potential entry point for attack.
5.4 RQ3: QUALITY OF LIM-INFERREE TAINT SPECIFICATIONS
The LLM-inferred taint specifications are fundamental to IRIS's effectiveness. To assess the quality of these specifications, we conducted two experiments. First, we used CodeQL's taint specifica- tions as benchmark to estimate the recall of both source and sink specifications inferred by LLMs (Fig. (6). However, since CodeQL offers a limited set of specifications, we also needed to assess the quality of inferred specifications outside of its known coverage. To this end, manually lyzed 960 randomly selected samples of LLM-inferred source and sink labels (30 per combination of CWE and I.M) and estimated the overall precision of the specifications (Fig. 7
LLM-inferred sinks can replace CodeQL sinks. Overall, LLMs demonstrated high recall when tested against CodeQL's sink specifications (Fig. 6). with GPT-4 scoring the highest (87.11%).
Table 2: Per- Per-CWE statistics of number of vulnerabilities detected (#Detected) by baselines and IRIS.
The compared baselines are CodeQL (QL), Facebook Infer (Infer), Spotbugs (SB), and Snyk. The values in parentheses show the differences of detection by IRIS against CodeQL.
Baselines
IRIS with
CWE
#Vuls
QL
Infer
SB
Snyk
GPT4
GPT-3.5
L3 8B
L3 70B
DSC 7B
CWE-22
55
22
0
2
21
31 (1 9)
25 (1
19 () 3)
29 (1 7)
25 (1 3)
CWE-78
13
0
1
3 (1
(
2 1)
14 (
3 (1
CWE-79
0
(1 9)
(1
(
14 (1 10)
CWE-99 94
21
0
0
8 (
8
11
9
10
(1 10)
All
120
27
0
55 (1 28)
47 (1 20)
41 (1 14)
54 (1 27)
52 (1 25)
8

---

Published as a conference paper at ICLR 2025
Source
100%
100%
87.11%
82. 76.7%
78.78%
75.73%
65.19%
75%
69. 12%
60.58
Recall
50%
Precision
38:11%:44::22%
35.03
02.022
33.56%
30.77%
29.29%
25%
0%
70B 7B
GPT-4
GPT-35 1lama
DSC
Figure 6: Recall of LLM-inferred taint specifi- cations against CodeQL's taint specifications.
Figure 7: Estimated precision of LLM-inferred specifications on randomly sampled labels.
/tt.:////dorr/oore/./////////// http::///wll.ooorrr///////////// /
alluxioo /luss///oor//ooeee..oo///fcffoso
oesprrerreecaceooooororoooooooor inpus) ...
siaFile. 2apArensveE enery
Fila(dirPath. (1.().
(#Lle0urpurttres Fillobrpputterren/ttpppttt
Ioutils. corcils..oooyiiiig (input, 1o8ls
if (lenzry. (.Directoory() try (Fileoutputttreee out new PileDutputStren www.ettttteeetttttiiii (ESTUUENEEE
Sipusita.dccoopresss decompress Paths, pat (ebbaa)))))) Aapziprleeracil
Figure 8: A previously unknown vulnerability found in alluxio 2.9.4. The snippets slightly mod- ified for presentation purpose. A user with database restoration permission may supply database checkpoint Zip file with malicious entry name. When unzipped, the entry may be written arbi- trary directory, causing a Zip-Slip vulncrability (CWE-022) that could corrupt the hosting server.
While the recall for source specifications was generally lower, found that CodeQL tends over- approximate its source specifications to compensate for low detection rate. On the other hand, GPT-4 achieved high precision (over 70%) in manual evaluations (Fig. 7. aligning with the lower false discovery rate previously reported in Table For other LLMs, the combination of high recall but lower precision suggests tendency to over-approximate sink specifications.
Over-approximating specifications can benefit IRIS. Although the precision for LLMs other than GPT-4 is lower, over-approximation restricted set of taint specifications. By over-approximating LLMs expand the coverage of taint analysis, offering partial solution CodeQL's limited scope. The impact of this imprecision can be mitigated through contextual analysis as we show next in the ablation studies.
actually help address
limitation of CodeQL- its
5.5 RQ4: ABLATION STUDIES
Both LLM-inferred sources and sinks are necessary. Table presents additional results when using either only the source or sink specification from an LLM in IRIS. For this experiment, we only use the results with GPT-4 for comparison. Each row present the number of detected vulnerabilities per CWE. We observe that omitting either source or sink specifications inferred by GPT-4 causes drastic reduction in overall recall.
Performance gain of contextual analysis depends LLM's reasoning capability. As shown in Fig. 9 contextual analysis is highly necessary for the precision and F1 score improvements. However, only GPT-4, GPT-3.5, and Llama-3 70B while the smaller models see negative. The false positive reduction of contextual analysis is the effective when the LLM possesses decent reasoning capability. Indeed, smaller models more likely to respond with "vulnerable" than larger models.
positive impact after contextual analysis,
RELATED WORK
Learning-based approaches for vulnerability detection. Numerous prior techniques incorporate deep learning for detecting vulnerabilities. This includes Graph Neural Network based models such Zhou et al. (2019); Chakraborty al. (2020); Dinella et al. 2020); Hin et al. (0022): Li et al.

---

Published as a conference paper at ICLR 2025
Table 3: Ablation on LLM inferred source and sink specifications (CodeQL. (QL) versus GPT-4), evaluated using the #Detected met- rics. When replacing either source sink
Avg. Precision
Avg.
GPT-4
0.073
0.074
GPT-3-5
0.043
0.055
with CodeQL specs, we see significantly less vulnerabilities detected.
IRIS with
13 8B
0.008
13 70B
0.028
0.033
CWE
22
78
79
94
Total
DBC
0.012
004
Sreor + Snkot.
22
4
0
27 (L 28)
Srerr:: Snkgu.
28
0
36 ( 19)
-0.03 -0.02
0.00
0.02
0.0g
0.05
0.06
0.08
0.09
Improvement after contextual analysis
STeoL + Snkorrs
10
(4 31)
Figure 9: Improvements Avg. Precision and
Srearr: Snkarrs
31
13
8
55
Avg. Fl after contextual analysis.
2021a);
LSTM-based models such as Li et al. (2020) 2021b); and fine-tuning of Transformer-
based models such as Fu & Tantithamthavorm (2022); Steemhoek et al. (2023); Cheng et al. (2022).
These approaches focus on method-level detection of vulnerabilities and provide only a binary label
classifying a method as vulnerable or not. In contrast, IRIS performs whole-project analysis and provides a distinct code path from a source to a sink and can be tailored for detecting different CWES. More recently, multiple studies demonstrated that LLMs are not effective at detecting vulnerabilitics in real-world code (Stcenhock et al. 2024 Ding et al.) 2024 Khare et al. (023). While these studies only focused on method-level vulnerability detection, it reinforces our motivation that detecting vulnerabilities requires whole-project reasoning, which LLMs currently cannot do alone.
2016), other static analysis tools Code Checker) also include analyses for vul- nerability detection. More general query engines (Scholz et al.) 2016, Li et al. 2023b) have also been applied to find program bugs. But these tools are not feature-rich and effective Cod- eQL (Li et al., 2223a; Lipp et al., (022). Recently, proprietary tools such as Snyk (Snyk.io) and SonarQube (SonarQube) are also gaining in popularity, although sharing the same fundamental lim- itations of missing specifications and false positives. which IRIS improves upon. We envision our technique to benefit all such tools. Works such MERLIN (Livshits al. (209)), Seldon (Chibotaru et al. 2019) and InspectIS (Dutta et al. 2022 tackle the problem of specification inference through probabilistic modeling. Specifically, like IRTS, InspectJS also augments CodeQL. with specifications inferred using machine learning. However, InspectIS relies on the quality of seed specifications and requires expensive analysis of each third-party library, which IRIS does not-making it more scal- able. Future work could explore incorporating probability estimates for specifications.
Static analysis tools. Apart from CodeQL (Avgustinov
(CPPCheck] Semgrep, 2023 FlawFinder FB Infer;]Code
LLM- approaches for software engineering. Researchers are increasingly combining LLMs with program reasoning tools for challenging tasks such as fuzzing (Lemieux et al. 2023; Xia et al.,
2024, program repair (Xia et al., 2023 Joshi et al. 2023 Xia & Zhang] (022). and fault local-
ization (Yang et al., 2023). While we are on a similar direction as (Li et al.) 2024 Wang et al.) 2024). to our knowledge, work is among the first to combine LLMs with static analysis to detect application-level security vulnerabilities via whole-project analysis.
7 CONCLUSION AND LIMITATIONS
We presented IRIS, novel neuro-symbolic approach that combines LLMs with static analysis for vulnerability detection. We curate a dataset, CWWE-Bench-aav,, containing 120 security vulnera- bilities across four classes in real-world projects. Our results show that systematically combining LLMs with static analysis significantly improves upon traditional static analysis alone in terms of both detected bugs and the alleviation of developer burden.
There are still many vulnerabilities that IRIS cannot detect. Future approaches may explore a tighter integration of these two tools to improve performance. In addition, IRIS makes numerous calls to LLMs for specification inference and filtering false positives, increasing the po- tential cost of analysis. While our results on Java well on other languages. Moreover, there is still gap between the IRIS generated report and the report that the developers would like see. We plan to explore this further in future work.
Limitations.
promising. it is unknown if IRIS will perform
10

---

Published as a conference paper at ICLR 2025
ACKNOWLEDGMENTS
We thank the anonymous reviewers for their valuable feedback and suggestions that helped improve this work. We also thank Claire Wang for helping with open-sourcing the project. This research was supported by NSF award CCF 2313010.
REFERENCES
Pavel Avgustinov, Oege de Moor, Michael Peyton Jones, and Max Schäfer. QL: Object-oriented queries relational data. In European Conference on Object-Oriented Programming, 2016.
Sicong Cao, Xiaobing Sun, Xiaoxue Wu, Lili Bo, Bin Li, Rongxin Wu, Wei Liu, Biao He, Yu Ouyang, and Jiajia Li. Improving Java deserialization gadget chain mining via overriding- guided object generation. In International Conference on Software Engineering, 2023.
Saikat Chakraborty, Rahul Krishna, Yangruibo Ding, and Baishakhi Ray. Deep learning based vulnerability detection: Are we there yet? IEEE Transactions on Software Engineering, 48: 3280-3296, 2020.
Checker Framework, 2024.
Xiao Cheng, Guanqin Zhang, Haoyu Wang, and Yulei Sui. Path-sensitive code embedding via contrastive learning for software vulnerability detection. In International Symposium on Software Testing and Analysis, 2022.
Victor Chibotaru, Benjamin Bichsel, Veselin Raychev, and Martin Vechev. Scalable taint specifica- tion inference with big code. In Conference on Programming Language Design and Implemenia- tion, 2019,
Code Checker, 2023. httpppssgggttt...cc///ccsss/ooea
CPPCheck, 2023. http:://apcheet..eucceo....r..
CVE Trends, 2024. bttpa://ww.cveeetaatt
Elizabeth Dinella, Hanjun Dai, Ziyang Li, Mayur Naik, Le Song, and Ke Wang. Hoppity: Learn- ing graph transformations to detect and fix bugs in programs. In International Conference on Learning Representations, 2020.
Yangruibo Ding, Yanjun Fu, Omniyyah Ibrahim, Chawin Sitawarin, Xinyun Chen, Basel Alomair, David Wagner, Baishakhi Ray, and Yizheng Chen. Vulnerability detection with code language models: How far are we? arXiv preprint arXiv:2403.18624 2024.
Saikat Dutta, Diego Garbervetsky, Shuvendu K Lahiri, and Max Schäfer. Inspectis: Leveraging code similarity and user-feedback for effective taint specification inference for Javascript. In International Conference on Software Engineering: Software Engineering in Practice (SEIP) Track, 2022.
FB Infer, 2023, https://fbinfer.com
FlawFinder, 2023. https://dwheeler.ce flawfinder
Michael Fu and Chakkrit Tantithamthavom. LineVul: A transformer-based line-level vulnerability prediction. In International Conference on Mining Software Repositories, 2022.
GitHub. Codegl, 2024a. fttt:s://codeel.itthue com
GitHub. Github advisory database, 2024b. httpa://ggttub.ccmm//a/
GitHub. Github security advisories,
2024c.
httpp:://gtthb..com//
advi dabissydrdaatabsee
Quinn Hanam, Lin Tan, Reid Holmes, and Patrick Lam. Finding patterns in static analysis alerts: improving actionable alert ranking. In International Conference on Mining Software Repositories, 2014.
11

---

Published as a conference paper at ICLR 2025
Jingxuan He and Martin Vechev. Large language models for code: Security hardening and adver- sarial testing. In Conference on Computer and Communications Security, 2023.
Sarah Heckman and Laurie Williams. A model building process for identifying actionable static analysis alerts. In International Conference on Software Testing, Verification and Validation, 2009.
David Hin, Andrey Kan, Huaming Chen, and Muhammad Ali Babar. Linevd: Statement-level vul- nerability detection using graph neural networks. In International Conference on Mining Software Repositories, 2022.
Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. SWE-Benche Can language models resolve real-world github issues? arXiv preprint arXiv:2310.06770, 2023.
Brittany Johnson, Yoonki Song, Emerson Murphy-Hill and Robert Bowdidge. Why don't soft- ware developers static analysis tools to find bugs? In International Conference Software Engineering, 2013.
Harshit Joshi, José Cambronero Sanchez, Sumit Gulwani, Vu Le, Gust Verbruggen, and Ivan Radičck. Repair is nearly generation: Multilingual program repair with LLMs. AAAI Con- ference Artificial Intelligence, 2023.
Yungbum Jung, Jachwang Kim, Jacho Shin, and Kwangkeun Yi. Taming false alarms from a domain-unaware C analyzer by Bayesian statistical post analysis. In International Static Anal- ysis Symposium, 2005.
Hong Jin Kang, Khai Loong Aw, and David Lo. Detecting false alarms from automatic static analysis tools: How far are we? In International Conference on Software Engineering, 2022.
Avishree Khare, Saikat Dutta, Ziyang Li, Alaia Solko-Breslin, Rajeev Alur, and Mayur Naik. Un- derstanding the effectiveness of large language models detecting security vulnerabilities. arXiv preprint arXiv:2311. 2023.
Luigi Lavazza, Davide Tosi, and Sandro Morasca. An empirical study on the persistence of spot- bugs issues in open-source software evolution. In Quality of Information and Communications Technology, 2020.
Caroline Lemicux, Jeevana Priya Inala, Shuvendu K Lahiri, and Siddhartha Sen. CODAMOSA:
Escaping coverage plateaus in test generation with pre-trained large language models. In Interna- fional Conference on Software Engineering, 2023.
Haonan Li, Yu Hao, Yizhuo Zhai, and Zhiyun Qian. Enhancing static analysis for practical bug detection: An lIm-integrated approach. In International Conference Object-Oriented Pro- gramming, Systems, Languages, and Applications, 2024.
Kaixuan Li, Sen Chen, Lingling Fan, Ruitao Feng. Han Liu, Chengwei Liu, Yang Liu, and Yixiang Chen. Comparison and evaluation on static application security testing (SAST) tools for Java. In Joint Meeting European Software Engineering Conference and Symposium the Foundations of Software Engineering, 2023a.
Yi Li, Shaohua Wang, and Tien Nhut Nguyen. Vulnerability detection with fine- fine-grained interpre- tations. In Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2021a.
Zhen Li, Deqing Zou, Shouhuai Xu, Hai Jin, Yawei Zhu, Zhaoxuan Chen, Sujuan Wang, and Jialai Wang. Sysevr: A framework for using deep learning to detect software vulnerabilities. IEEE Transactions on Dependable and Secure Computing, 19:2244-2258, 2021b.
Zhuguo Li, Deging Zou, Shouhuai Xu, Zhaoxuan Chen, Yawei Zhu, and Hai Jin. VulDeeLocator: A deep learning-based fine-grained vulnerability detector. IEEE Transactions on Dependable and Secure Computing, 19:2821-2837, 2020.
12

---

Published as a conference paper at ICLR 2025
Ziyang Li, Jiani Huang. and Mayur Naik. Scallop: A language for neurosymbolic programming. In Conference on Programming Language Design and Implementation, 2023b.
Stephan Lipp, Sebastian Banescu, and Alexander Pretschner. An empirical study on the effectiveness of static C code analyzers for vulnerability detection. In International Symposium on Software Testing and Analysis, 2022.
Benjamin Livshits, Aditya V. Nori, Sriram K Rajamani, and Anindya Banerjee. Merlin: Specifica- tion inference for explicit information flow problems. In Conference on Programming Language Design and Implementation, 2009.
Rangeet Pan, Ali Reza Ibrahimzada, Rahul Krishna, Divya Sankar, Lambert Pouguem Wassi, Michele Merler, Boris Sobolev, Raju Pavuluri, Saurabh Sinha, and Reyhaneh Jabbarvand. Lost in translation: A study of bugs introduced by large language models while translating code. In International Conference on Software Engineering, 2024.
Bernhard Scholz, Herbert Jordan, Pavle Subotić, and Till Westmann. On fast large-scale program analysis in Datalog. International Conference on Compiler Construction, 2016.
Semgrep. The Semgrep platform. https: /ttppp::///mgpppp..p wttp///mggep..../ dev/ 2023.
Yannis Smaragdakis and Martin Bravenboer. Using Datalog for fast and easy program analysis. In International Datalog 2.0 Workshop, 2010.
Snyk.io, 2024. https://snyk:
SonarQube, 2024. https://www. www.:sswaassurr....mm www.ar/swu.ce..coo/pprrttttaaaaa
Benjamin Steenhoek, Hongyang Gao, and Wei Le. Dataflow analysis-inspired deep learning for efficient vulnerability detection. arXiv preprint arXiv:2212.08100. 2023.
Benjamin Steenhoek, Md Mahbubur Rahman, Monoshi Kumar Roy, Mirza Sanjida Alam, Earl T Barr, and Wei Le. A comprehensive study of the capabilities of large language models for vulner- ability detection. arXiv preprint arXiv:2403. 140..12213 2024.
Chengpeng Wang, Wuqi Zhang, Zian Su, Xiangzhe Xu, Xiaoheng Xie, and Xiangyu Zhang. LLMDFA: Analyzing dataflow in code with large language models. In Neural Information Pro- cessing Systems, 2024.
Chunqiu Steven Xia and Lingming Zhang. Less training, more repairing please: revisiting auto- mated program repair via zero-shot learning. In Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2022.
Chunqiu Steven Xia, Yuxiang Wei, and Lingming Zhang. Automated program repair in the era of large pre-trained language models. In International Conference on Software Engineering, 2023.
Chunqiu Steven Xia, Matteo Paltenghi, Jia Le Tian, Michael Pradel, and Lingming Zhang. Fuzz4all: Universal fuzzing with large language models. In International Conference on Software Engineer- ing, 2024.
Aidan ZH Yang, Ruben Martins, Claire Le Goues, and Vincent J Hellendoorn. Large language models for test-free fault localization. arXiv preprint urXiv:2310.01722 2023.
Yaqin Zhou, Shangqing Liu, J. Siow, Xiaoning Du, and Yang Liu. Devign: Effective vulnerability identification by learning comprehensive program semantics via graph neural networks. In Neural Information Processing Systems, 2019.
13

---

Published as a conference paper at ICLR 2025
A IMPLEMENTATION DETAILS OF IRIS
A.1 SELECTING CANDIDATE SPECIFICATIONS
While extracting external APIs, we filter out commonly-used Java libraries that are unlikely to con- tain any potential sources or sinks. Such libraries include testing libraries like JUnit and Hamcrest or mocking libraries like Mockito. While we filter out methods that are defined in the project, we specifically allow methods that are inherited from an external class or interface. An example the get ree method of the generic class Class in java. baaa.laan lang package, which takes path as a string and accesses file in the module. Many projects commonly inherit this class and use this method. If the input path is unchecked, it may lead to a Traherrrlrssal vulnerability if the path accesses resources outside the given module. Hence, detecting such API usages is crucial.
Taint sources are typically values returned by methods that obtain inputs from external sources, such as response an HTTP request or a command line argument. Hence, we select external APIs that have "non-void" return type as candidate sources. Another type of taint sources are commonly seen in Java libraries. When used by downstream libraries, tainted information maybe passed into the library through function calls. Therefore, we also collect the formal parameters for public internal function as source candidates. Due to the excessive amount of such candidates, we pose a further constraint that the public internal function must be directly invoked by unit test case within the same repository. Here, the test cases are identified by checking whether the residing file path has arc/test within it.
On the other hand, taint sinks are typically arguments to an external API. This involves explicit argu- ments, such as the command argument passed Runtim ime. exec (String command) method, and implicil this i argument to non-static functions, such as the file variable in the function call file. deleeeeeeeeeeeeeee (). This is the only type of sink that we consider within IRIS.
We note that this is not the entire story as there might be other kinds of sources and sinks. Other types of source candidates include the formal parameter of protected but over- ridden internal functions (the reg parameter in protected HTTPServeletRespon doGet SurTSeerveletRegee
req)). ), arguments to an impure external function (the buffer argument to void read (bytell buffer, int size)), ), etc. Sink candidates in- clude the return value of public facing functions, thrown exceptions, and even static methods without any parameter (System. exit t () ). Due the complexity, do not tackle such kind of sources of sinks in this work. However, we plan to explore further in future work.
A.2 LLM PROMPTS FOR SPECIFICATION INFERENCE
There are two prompts that we use to query LLM for specification inference. The first one is used to label external APIS as either sources or sinks, illustrated in Listing ! At a high level, this is a classification task that classifies each API into one of [Source, Sink, Taint- Srint-Propggtor, ,None). As shown in the listing, the system prompt involves general instruction about the task and the expected output format, which is JSON. In the user prompt, we give the description of CWE, since the source and sink specifications of external APIs are dependent on the CWE. We additionally give few-shot examples that cover both sources and sinks for the given CWE. At the end, we list out a batch of methods akin to the format of CSV. Notably for sink specifications, we expect the LLM to give extra information about which exact argument be considered as the sink. This include explicit arguments as well as the implicit this argument. We also note that while taint-propagators are included in the prompt, we do not actually use it in the subsequent stages of IRIS. Primarily, the notion of protpprropagtor is to help LLMs differentiate between sinks and summary models, which are sometimes mistakened as sinks. In general, we find the prompt to serve the purpose well.
The second prompt, depicted in Listing 2 is used to label the formal parameters of internal APIs as sources. Since we are analyzing internal API, the information such as project README and function documentations are commonly available. The goal is find whether this internal API might be invoked by a downstream library with a malicious input passed to this formal parameter. This information is not CWE specific, hence no CWE information is included in this prompt.
We hypothesize that since LLMs are pre- pre-trained on internet-scale data, they have knowledge about the behavior of widely used libraries and their APIs. Hence, it is natural ask whether L.MMs can be
14

---

Published as a conference paper at ICLR 2025
System: You are a security expert. You are given list APIs be labeled as potential taint sources, sinks, or APIS that propagate taints. Taint sources are values that an attacker can use for unauthorized and malicious operations when interacting with the system. Taint source APIs usually return strings types. Setter methods are typically NOT taint sources. Taint sinks are progran. points that can use tainted data in an unsafe way, which directly exposes vulnerability under attack. Taint propagators carry tainted information from input to the output without sanitization, and typically have non-primitive input and outputs. Return the result as a json 1ist with each object in the format:
custom object
"package"; <package name>, "c "class": <class name>, "methoa": <method name?, "signature": <signature of the method>, <list of arguments or 'this', empty if the API is not sink
>,
"typo": <"source", "sink", or "taint-propagator*>
10 DO NOT OUTPUT ANYTHING OTHER THAN JSON.
13
User:
14
15
Some example (CWE_SOURCE_SINKC __AM__XXXAPPLS
methods are:
17
18
Among the following methods, assuming that the arguments passed to the given function is malicious, what are the functions that are potential source, sink, taint- [CWE_TITLE, attack (CWE- (CME-(CW__DD)) [D])?
19
20
propagators
22 Package, Mlass,Method, Signature [Packagel], [Class1), [Method1], (Signaturel] [Package2], [Class2], [Method2], [Si [naturee) [...]
25
Listing I: LLM prompt for labelling external APIs sources sinks.
used to identify APIs that are relevant as sources or sinks for any vulnerability class. successful, L.MMs alleviate manual effort, and drastically improve the effectiveness of static analysis tools.
A.3 DESIGN DECISIONS LLM PROMPTS
Here are some reasoning behind the design decisions for the LLM prompts:
1. Few-shot for labeling external API: Since the LLM is tasked with labeling source, sink, and trint-propagator APIs, we provide one example for each category, along with negative example of API that does not fall into any of these categories. We typically select examples from the Java standard libraries because they are widely used and their labels are readily available.
2. Zero-shot for labeling internal API: As labels for internal APIs are not available, rely on the zero-shot capabilities of the language model. To mitigate potential performance loss, include additional information, such documentation associated with important internal APIs.
3. +5 lines surrounding the source and sink location during contextual analysis: We chose +5 lines balanced approach to provide sufficient context while managing per- formance and cost. While technically possible to use a larger window, we observed that excessive context overwhelm the language model, leading reduced accuracy. Addi-
15

---

Published as a conference paper at ICLR 2025
System: You are a security expert. You are given implemented in established Java libraries, and you need to identify whether some of these APIS could be potentially invoked by downstream libraries with malicious end-user (not programmer) inputs. For instance, functions that deserialize or parse inputs might be used by downstrean libraries and would need to add sanitization for malicious user inputs. On the other hard, functions like НTTP request downstream
APIs
handlers are typically final and won't be called package. Utility functions that are not related to the primary purpose the package should also be ignored. Return the result as a json list with each object in the format:
"package": <package name>, "class": <class name>, "methoa": <method name?, "signature"; <signature>, "tainted inmbtted_ipput... <a list of argument names that are potentially tainted
In the result list, only keep the functions that might be used by downstream libraries and is potentially invoked with malicious end- user inputs. Do not output anything other than JSON.
11
12
User: You are analyzing the Java package [PROJECT [RROJECT_AMME Here is the package surmazy:
BEANECTTREADME_SUNEE
15
16 Please look at the following public methods in the library and their
documentations (if present). What are the most important functions that lcck like dependent on [PROJECT_NAME)] and that the function can be called with potentially malicious end-user inputs? If the package does not seem to be a library, just return empty list as the result. Utility functions that are not related to the primary purpose of the package should also ignored.
invoked by a downstream Java package that is
17
18 Package, Class, Metss, Doc
19
Packagell, 1, [Class]], , [Method]] , |Documentationi
[Package2] [Class2], [Method2] [Documentation2]
[...]
Listing 2: LLM prompt for labeling formal parameters of internal APIs as sources.
tionally, a larger context increases computational costs significantly, particularly given the large number of candidate APIs and paths that must be queried.
4. Selecting subset of nodes the alarm path during contextual analysis: We use hy- perparameter S control the number of intermediate steps included in the prompt. For paths with more than S intermediate steps, we divide the path into S equal segments and select one step from each. This selection prioritizes function calls, they may indicate sanitizations. If no function call is present, a node is randomly selected from the segment. In our experiments, we observe that setting to 10 provides a good balance between the cost and accuracy so that the prompt contains enough context and would not be too long.
A.4 CODEQL QUERIES FOR STATIC ANALYSIS
Listing presents our CodeQL query for Path- Traversal vulnerabilities (CWE 22). Lines 10 29 describe taint analysis configuration that describes which nodes in the data flow graph should be considered as sources or sinks. Here, Line [2] specifies our custom predicate sst.MDetectedSoorce that checks whether the method called is taint source based
16

---

Published as a conference paper at ICLR 2025
import java // other imports import MyScurces
import MySinks
/+.
* taint-tracking configuration for tracking flow from remote sources to the
creation of path.
*/
10
module MyTaintedPathContig implements DataFlow::Contigsli I
11
predicate isSource (Datarloxs :o:::Nde source) {
isliiMatttcteeduurreeeooo (source)
13
}
14
15
predicate isSink :aataFlow::Node sink) | IstiMeetectedSinkeet (sink)
18
19
predicate isBarrier (DataFlow: :Node sanitizer) {
20
sanitizer.getType. instancecf BoxedType or Sanitizer.getType instancecf PrimitiveType or samitizer.getllpee () instancecf NumberType or
23
sanitizer instanceof PataiajectionSanitiees
24
predicate isAdditional oosstep (Datarlow; Node ni, DataFlow: Node n2) isluMBetectedStte (n1, n2)
27
28
29
/** Tracks flow from remote sources the creation path. x/ module MyTaintedPathFlow
32
33
34
from MyTaintcdPathhFlow :athhNod scurce, MyTaintcdPathFlow Pathhode sink where MyTaaintedPachhlov: : FlowPath (scurce, sink)
35
16
select
17
Ret ngdode (sink, get ()),
38
source,
sink,
"This path depends source Nww.eeeeeeeeeeooo (),
$3.",
42
sourceType (scurce. get )))
Listing 3: CodeQL script for detecting vulnerabilities for Aath-Traversal (CWE 22).
specifications. Similarly, our predicates isLiMeetectedSi.. checks whether the node is taint sink based on our specifications. Line I checks if method call or method argument node is a taint
sink based on our specifications. We generate the source and sink specifications as predicates in QL file as shown in Listings 4 [5 respectivvy Given a taint configuration and the source and sink specifications, CodeQI. can automatically perform taint analysis on given project.
We use templates convert LLM inferred specifications into CodeQL queries. There are three kinds of queries:
formal parameter of an internal function as a source;
2. the return value an external function as a source; and
3. an argument to an external function as a sink.
Example queries for the two kinds sources are specified in Listing 4 while the example query for the sink is illustrated in Listing 5 As shown in the listings, not only match on function package,
17

---

Published as a conference paper at ICLR 2025
class, and name, but also match individual arguments parameters. Moreover, query han- dles generic functions or function in generic classes through the sor predicate provided by CodeQL. Notably, when the number of inferred specificatiinss is too large, will split the single predicate into multiple hierarchical ones, improving the CodeQL. performance.
()
predicate LstiMDetectedSourcc (DataE low: Node src) // sources: Return value from external APIS
src. ascppr) () (Call) getCallee gett () "getName" and src. asExpr) (Call) getCalleee() heg.eallleeeggtteeelrriiinggnggo get.Declaaingggyee
getsourceeeellarttion () SaaaQualifiedNamee jajava. jaa.a.aii...ipp.... "ZipEntry")
// sources: Function formal parameters of internal exists (Parameter p
10
11
and p.getCallable () getName () "setUserName" and P. p.getCallable ggeteeclarinngype .etsouuceeelllaaaiiii)
orc.asParameter()
hasQualifiedNene ("org.apacia apache dolphinschedduler dao "atiity,,"" "DeRule") and
14
(p.gctName () "userName"
16
17
Listing CodeQL predicate for source specifications.
predicate i (DataF 1 ow: Node snk) { exists (Call
gettCallee getName c. C.geeCallee () getDeclaringgyyee (gtttoorrereeeeaaariiiiooooooooo hasQualifiedNNaee (" jajaviioo io", "File") and
"createTempFiie* and
c. g.geenttument (0) snk.asExpr () (Argument) )
or
Listing 5: CodeQL. predicate for sink specifications.
A.5 VISUALIZATION METRICS
We provide a visualization of our VulDetected metric in Fig. 10 For evaluation, we assume that the label for project P provided as a of crucial program points VP [Vi,..., V,) where the vulnerable paths should pass through. In practice, these are typically the patched methods that can be collected from each vulnerability report. As illustrated in Fig. [0] least one detected vulnerable path passes through fixed location for the given vulnerability, then we consider the vulnerability detected. Let Paths be the set of detected paths for each project P from prior stages. The vulnerable paths inside project P is given by:
VulPaths P) [Path Paths Path V 0}
B ADDITIONAL DETAILS OF CWE-BENCH-JAVA
B. DETAILS OF DATASET EXTRACTION PROCESS
Because we use CodeQL for static analysis, we further need to build each project for CodeQL to extract data flow graphs from the projects. To build each project, need to determine the correct.
18

---

Published as a conference paper at ICLR 2025
Detected Source: two formal params of extractFile
public void extractFile(
String fileNane, String destinationPath, String newF (eeeeee throws ZipException
{
The Fix for the WVE-2018-1002200 the sanitizer to check the path
function assertCanonical PathsAreeaae
String comp
File(completePatte gettanonicallathh) String out new File(outPath) getCmmnissaPPaat)))))
if ('completePath, star tsttt WWWthhhhtttaa (auttaat)))))) {
x7
(na sanitization)
1f (!comp. startsWithouut) {
*/
Path Is Vulnerable
X
Not Vulnerable
Detected Sink A: write to output file
Detected Sink B: creating new dir
try (QutputStream rutputStrean
if ( diestinationPathy nkdirs()) {
A visualization of our metrics used for vulnerability detection, where the snippets are adapted from Zip4j v2. 12.11.5-2, with slight changes for clearer presentation. While both sinks are potential causes of Path-Traversal (CWE-22), only the dataflow path on the left passes through the fixed sanitizer function. Therefore, we consider only the path on the left as a vulnerability.
Figure 10:
Table Vulnerability dataset collection statistics.
Step
CWE-22
CWE-78
CWE-79
CWE-94
Total
Initial CVEs
236
39
681
109
1065
W/ Github URL and Version
119
37
219
55
430
W/ Fix Commit
89
27
99
50
265
Compilable
56
17
50
26
149
Fixes in Java Code
56
16
25
47
144
Manual Validation
55
13
31
21
120
Java and Maven compiler versions. We developed a semi-automated script that tries build each project with different combinations of Java and Maven versions. The fourth row in Table 4 presents the number of projects we were able to build successfully. Overall, this results in (o) 149 projects.
Finally, we manually check each fix commit and validate whether the commit actually contains fix to the given CVE in a Java file. For instance, we found that in some cases the fix is in files written in other languages (such as Scala or JSP). While code written in other languages may flow to the Java components the project during runtime or via compilation, determine if static analysis correctly detect such vulnerability. Hence, Further, we exclude cases where the vulnerability was in a dependency and the fix was just a version upgrade if the vulnerability we evaluate with IRIS. For this task, we divide the CVES among two co-authors of the project, who independently validate each case. The co-authors cross-check each other's results and discuss together to come up with the final list of projects.
not possible to correctly
exclude such CVEs.
mis-classified. Finally, we end up with (a) 120 projects that
The closest dataset ours, in terms of features, the Java dataset curated by Li et al. 2023a taining 165 CVEs. While we initially considered using their dataset for our work, we found several issues. First, their dataset does not come with build scripts, which makes it hard automatically run each project with CodeQL. Second, their dataset only has few CVEs for all but one CWE, which makes difficult to thoroughly analyze a tool for different vulnerability classes. Finally, they do not provide any automated scripts to curate more CVEs. Hence, we curated our own dataset and our framework also allows to easily extend to more vulnerability classes.
B.2 COMPARISON OF CWE-BENCH-JAN WITH EXISTING VULNERABILITY DATASETS
We compare TWV--Bnnch-Jawe with existing datasets for vulnerability detection in Java, C, and C++ codebases, the following criteria:
19

---

Published as a conference paper at ICLR 2025
Table 5: Comparison of CWE-Bench-Bad with existing vulnerability datasets.
Dataset
Languages
CVE Info Real-World Fix Locations
Compilable Vetted
BigVul
C/C+
X
X
x
Reveal
C/C++
x
X
CVEFixes
CIC++ Java,
1
X
Vuv
CIC+
X
X
DecpVD
C/C++
X
/
X
X
Juliet
C++, Java
X
J
J
Li al. 2023a)
Java
SVEN He Vechev 2023
C++
X
/
CWF-Bench-Java (Ours)
Java
/
1. CVE Info: whether CVE Metadata is contained in the dataset;
2. Real-World: whether the dataset contains real-world projects;
3. Fix Locations: whether the dataset contains fix information about the vulnerabilities;
4. Compilable: whether the dataset ensures that the projects are end-to-end and automatically compilable; and
5. Vetted: whether the vulnerability in the dataset is manually verified and confirmed.
As shown in Table compared existing datsets, CWE-Bench-Java, is the only that checks every criterion. This underscores the significance of our new dataset.
C EVALUATION DETAILS
C.I EXPERIMENTAL SETTINGS
We select two closed-source LLMs from OpenAl: GPT 4 (oppt---112----000 (opt-4-0125ppreview and GPT 3.5 (gpt-3. 5-rbobo- 01 25) for evaluation. GPT and GPT 3.5 queries used in the paper performed through OpenAl API during April and May of 2024.
We also select instruction-tuned versions of six state-of-the-ant open-source LLMs via huggingface API: Llama 3 8B and 70B, DeepSeekCoder 7B, QWEN-2.5-Codee 32B, and Gemma-2 27B. To the open-source LLMs we use two groups of machines: 2.50GHz Intel Xeon machine, with 40 CPUs, four GeForce RTX 2080 Ti GPUs, and 750GB RAM, and another 3.00GHz Intel Xeon machine with 48 CPUs, A100s, and 1.5T RAM.
We use CodeQL version 2. 15.3 as the backbone of our static analysis. We have patched CodeQL with an additional feature that augments the Dataflow edge between throw statement and its closest surrounding try-catch block. We use this CodeQL. pull request as the base of our patch.
C.2 CODEQL BASELINE
For baseline comparison with CodeQL,, we use the built-in Securi i ty queries specifically designed for each CWE that comes with CodeQL. 2.13. Note that there are multiple security queries for each CWE, and each produce alarms of different levels (error, warning, and recommendation) For each CWE, we take the union of alerts generated by all queries and do not differentiate between alarms of different levels. For instance, there are queries from CodeQL for detecting CWE-22 vulnera- bilities, namely Tainted8 ath, TaintedP a thhocal,, and ZipSlip. While Taint edP ath and ZipS1ix ip produce error level alarms, Taine raintedPP at Local produces only alarm recommen- dations. To CodeQL's advantage, all alarms are treated equally in our comparisons.
C.3 HYPER-PARAMETERS AND FEW-SHOT EXAMPLES
During IRIS, we have 2 prompts that are used to label external and internal APIs. Recall that the prompts contain batched APIs. We use batch size of 20 and 30 for internal and external, respectively.
20

---

Published as a conference paper at ICLR 2025
In terms of few-shot examples passed to labeling external APIs, use 4 examples for CWE-22, examples for CWE-78, examples for CWE-79, and 3 examples for CWE-94, We use temperature of O, maximum tokens to 2048, and top-p of for inference with all the LLMs. For GPT 3.5 and GPT 4, we also fix a seed to mitigate randomness as much as possible.
C.4 DETAILS OF SELECTED LLMS
We include the versions of the 7 selected LLMs in Table
Table 6: Versions and model IDs of the selected LLMs in our evaluation.
LLM Version and Size
Model ID
GPT 4
gpt-4-0125-previie.
GPT 3.5
gpt-3.5-turbo--112
Llama 3 8B
Llama 3 70B
DeepSeekCoder
Qwen-2.5-44 2.5-oo-rr 32B Instruct
Gemma-2 2 27B
3oogle/gemma-2227b-1t
C.5 STATISTICS OF UNIQUE AND RECURRING SPECIFICATIONS
Table 7: Unique source and sink specifications across all projects in CWE-Bench-Java.
Table 8: Recurring source and sink specifica- tions in CWE-Bench-lava.
CWE
22
78
94
CWE
79
#Unique Sources
1348
899
598
810
#Recurring Sources
908
232
1118
626
#Unique Sinks
1069
575
514
1281
#Recurring Sinks
919
201
911
961
Continuous taint specification inference is necessary. Our results show that there is high number of both unique and recurring sources and sinks. sink specifications that occur only in a single project CWF-Bench-Jawe whereas Table S presents the specifications that occur in at least two projects. This indicates that even if previously inferred specifications are useful, a significant number of new relevant APIs still remain and need to be labeled for effective vulnerability detection. This observation strongly motivates the design of IRIS that infers these specifications on-the-fly for each project via LLMs, instead of relying on a fixed corpus of specifications like CodeQL.
the number of inferred source and
C.6 STATISTICS OF INFERRED TAINT SPECIFICATIONS
We show the statistics of inferred taint specifications Table As shown by the percentage, GPT-4 generates smaller of sources and sinks than smaller-scale L.LMs like DeepSeekCoder 7B.
Table 9: Ratio of API candidates labeled as source (S) or sink (N) by GPT-4 and DeepSeekCoder
(DSC) 7B, per CWE and total.
GPT-4
DSC 7B
CWE
#Cand.
%
%N
%
%
130,974
2.03%
1.90%
4,27%
4.01%
78
25,605
4.73%
3.37%
3.67%
3.33%
79
37,138
5.69%
4.69%
4.28%
4.56%
94
36,325
5.12%
7.83%
6.11%
6.21%
Total
230,042
3.41%
3.45%
4.50%
4.37%
21

---

Published as a conference paper at ICLR 2025
C.7 ERROR ANALYSIS: CAUSE OF UNDETECTED VULNERABILITIES
In general, we find the following three main causes of undetected vulnerabilities by employing IRIS:
1. Vulnerability cannot be modeled by simple taint dataflows: for instance, the vulner- ability CVE-2020-11977 (CWE-94) is manifested by an unexpected exit(I) call, with no direct taint dataflow going into it. In fact, the taint dataflow goes into the condition of an "if" statement surrounding the exit. In this case, the model of sink API cannot capture the vulnerability.
2. Missing dataflow edge due to side-effects: for instance a taint information is written to temporary file, and later read from the same file, subsequently causing vulnerabil- ity. However, the dataflow edge is carried through side-effects, which is not captured by CodeQL.
3. Missing dataflow edge due to unspecified library usage: The vulnerability can only be manifested through a concrete usage of the library; but within the library itself there is no possible dataflow connect the source and the sink.
Overall, we view the above as general limitations for the static analysis. terms of LLM induced false negatives, here are the two main failure modes:
1. Missing phitt-roopagttr labels from LLM: this would cause missing dataflow edges stopping source to flow to sink.
2. Missing source or sink specifications from LLM: if there no relevant source/sink spec- ification then the static analysis tool would not have the anchor for analysis.
D ANALYSIS RUNTIME
We include the full table containing statistics to provide more details about projects and our analysis (Table [T).. For each project, we present its corresponding CWE ID, the lines-of-code (SLOC), the time it takes to run the full analysis, the number candidate APIs and the number of labeled source and sinks by Llama
We also color code cells of interest: For SLOC, we mark cell as IM; yellow if 100k. For Time, mark cell as red if > lh; yellow if 5m. For the number of candidates, we mark cell as red > 10k. Lastly for the numbers of sources and sinks, we mark cell as red if the number is larger than 200.
Table 10: Details of analysis runtime, candidates, and inferred sources and sinks for all projects (Llama 3 8B).
CWE-ID
Project
SLOC
Time #Candidates
#Sources
#Sinks
22
DSpace
218.2K
15s
3.61K
162
217
22
spark
10.7K
Im
679
35
27
22
spark
9.77K
57s
598
33
22
22
wildfly
496.28K
4m
14.13K
457
425
22
vertx-web
51.01K
1m
2.06K
80
77
22
camel
1.16M
293
22
22
hutool
135.34K
4m
6.17K
115
211
22
tika
106.3K
2m
3,84K
277
177
22
retrofit
19.28K
1m
880
28
13
22
jspwiki
149.45K
Im
1.83K
62
80
22
camel
1.21M
11m
4.43K
53
80
22
tapestry-5
160.06K
Im
3,04K
91
66
22
spring-cloud-co
18.56K
1m
1.16K
40
64
22
spring-cloud
18,44K
59s
1.16K
40
64
22
rocketmq
94.64K
Im
2.78K
28
54
22
mpxj
181.55K
1m
1.6K
37
43
22
flink
1.14M
2h
5.16K
39
61
22

---

Published as a conference paper at ICLR 2025
22
Java
1M
2m
8.04K
96
41
22
commons-io
29.24K
58s
1.07K
12
47
22
karaf
135.22K
Im
5,43K
150
210
22
james-
434.32K
4m
14.58K
209
226
22
vertx-weh
49.28K
1m
2.36K
83
96
22
esapi-java-lega
35.26K
59s
1,48K
43
67
22
xwiki-commons
103.05K
1m
3,76K
104
137
22
zip4j
16.78K
58s
532
6
34
22
agejaava-agent
5.19K
51s
327
11
20
22
myfaces
161.02K
1m
2.4K
68
44
22
undertow
86.03K
2,58K
66
93
22
DependencyCheck
28.57K
1m
1,23K
47
66
22
plexus-archiver
13.04K
51s
573
34
47
22
plexus-archiver
13.04K
51s
573
34
47
22
zt-zip
6.64K
52s
337
14
31
22
curekit
511
43s
73
2
4
22
aws-sdk-java
7.72M
38m
12K
62
65
22
venice
115.44K
2.27K
36
79
22
DSpace
237.33K
1m
3.67K
179
233
22
Payara
1.12M
16.05K
379
427
22
DSpace
237.33K
1m
3.67K
179
233
22
goomph
12.68K
59s
1.12K
35
111
22
dolphinschedule
90.69K
1m
3.36K
65
92
22
dolphinschedule
91,94K
3.4K
65
92
22
testng
95.53K
1m
2.08K
33
73
22
uima-uimaj
226.81K
2m
5.66K
103
176
22
keycloak
614.82K
12m
13.34K
325
252
22
glassfish
1.19M
5m
12.19K
293
346
22
graylog2-server
382K
4m
13.3K
227
171
22
mina-sshd
130.14K
1m
3.64K
52
120
22
shiro
38.68K
Im
1.5K
41
42
22
plexus-archiver
15.51K
57s
666
37
56
22
plexus-utils
23.3K
58s
754
16
36
22
yames
693.6K
2m
11K
98
113
22
yames
693.6K
11K
98
22
shiro
38.94K
1m
1.53K
41
43
22
sling-org-apach
8.34K
54s
695
28
25
78
xstream
43.49K
Im
1.39K
91
30
78
xstream
59.79K
Im
1.64K
107
42
78
xstream
52.25K
1m
1,64K
107
43
78
docker-commons.
2.79K
54s
362
25
20
78
workflow-cps-pl
17,02K
1m
1,38K
72
61
78
workflow-cps-gl
4.31K
55s
523
40
38
78
workflow-multib
3,45K
53s
500
30
30
78
activemq
442.42K
4m
6.34K
234
192
78
plexus-utils
22.76K
714
34
17
78
git-client-plug
16.41K
1m
1.06K
83
50
78
perfecto-plugin
667
54s
107
10
78
nifi
915.95K
11m
22.44K
894
614
78
script-security
8.17K
Im
678
40
46
79
antisamy
6.38K
57s
381
42
33
79
antisamy
6.38K
56s
381
42
33
79
jspwiki
149.33K
1m
1,84K
156
110
79
jspwiki
149.33K
1m
1.84K
156
110
79
jspwiki
149.33K
1m
1.84K
156
110
79
jspwiki
157.09K
Im
1,85K
157
110
79
hibernate-valid
93.6K
Im 2.06K
79
57
79
exf
798.53K
lh 16.54K
821
756
79
xxl-job
9.32K
60s
540
42
41
23

---

Published as a conference paper at ICLR 2025
79
sson-sanitizer
1,47K
52s
67
4
5
79
hawkbit
112.09K
1m
4.07K
144
151
79
nacos
203.78K
2m
4.08K
201
139
79
antisamy
4.93K
1m
362
43
34
79
esapi-java-lega
35.26K
1m
1,48K
107
85
79
antisamy
5.14K
Im
377
44
36
79
jolokia
29.97K
1,66K
117
97
79
keycloak
60.6K
1m
2.1K
170
136
79
exf
722.83K
15m
15.09K
766
710
79
sling-org-apach
1,37K
55s
136
4
13
79
DSpace
237.33K
3.67K
347
320
79
keycloak
615.6K
3h
13.37K
606
461
79
keycloak
615.6K
3h
13.37K
606
461
79
xwiki-commons
105.92K
Im
3,94K
244
151
79
xwiki-commons
105.94K
1m
3,94K
244
151
79
xwiki-rendering
97.01K
1m
1,22K
73
92
79
xwiki-commons
106.87K
Im
3.99K
254
161
79
jspwiki
158.7K
1m
2.22K
176
126
79
keycloak
617.15K
4h
14.04K
643
479
79
xwiki-commons
107.09K
Im
3.03K
209
143
79
jstachio
53.02K
54s
792
40
46
79
xwiki-rendering
97.63K
1,24K
74
92
94
spring-security
43.9K
1m
1,83K
120
176
94
xstream
52.25K
1.64K
111
145
94
cron-utils
13.08K
1m
476
13
26
94
struts
160.51K
12m
4.39K
301
357
94
activemg
547.68K
1h
7.55K
370
607
94
spring-fruad framewor
666.11K
45m
17.71K
688
846
94
spring-cloud-ga
25.56K
1m
2.01K
130
153
94
dubbo
175.63K
2m
6,73K
342
383
94
incubator-dubbo
96.35K
Im
3,68K
194
255
94
spring-securig
57.34K
Im
2,43K
192
234
94
kubernetes-clis
806.35K
2,33K
93
130
94
commons-text
24.87K
1m
962
40
47
ff4j
46.21K
2.39K
274
94
spring-boot-adm
18.29K
1m
1.83K
92
157
94
sqlite-jdbe
17.71K
59s
732
50
74
94
nifi
993.76K
25m
57
2
11
94
rocketmg
108.39K
2m
3.4K
117
164
94
nifi
1.01M
27m
261
27
24
94
rocketmq
197.78K
2m
6,28K
205
252
94
dolphinschedule
154.95K
4m
5,78K
229
353
94
dolphinschedule
154.95K
4m
5,78K
229
353
24


Reviews:
[{"review_id": "lwr7PR9V3m", "reviewer": "Reviewer_EvMB", "summary": "This paper presents a hybrid approach that combines static analysis (CodeQL) with LLMs to detect vulnerabilities. Specifically, IRIS uses LLMs to find taint specification of external APIs and use CodeQL to compute paths as context and feed into the prompts to LLMs. The authors evaluated their work on 120 manually  validated Java vulnerabilities. The results show that their approach can detect 56 vulnerabilities, 28 more than the ones reported by CodeQL", "questions": "-  How are the subset of paths selected when paths are too long?\n-  There are many vulnerability datasets available, such as PrimeVul, Sven datasets. Why do you not run your tool on these datasets?", "limitations": "", "rating": 3, "confidence": 4, "soundness": 2, "presentation": 3, "contribution": 2, "strengths": "+ IRIS demonstrated the improved results over CodeQL \n+ IRIS found unknown vulnerabilities \n+ This paper is well written and contains details.\n+ It's interesting to learn that the LLMs can infer taint specifications with 70% accuracy", "weaknesses": "Soundness:\nThis paper contains a problematic evaluation: \n- The authors curated 120 examples. All of them are vulnerable labels. The results focus on vulnerabilities detected. The false positive rates are not evaluated?\n- There are many vulnerability datasets available, such as PrimeVul, Sven datasets. Why do you not run your tool on other datasets?\n- The baselines of CodeQL (QL), Infer (Infer), Spotbugs (SB), and Snyk are all static analysis tools?  Should you also compare any AI based approaches? e.g., what about feeding the entire function into a prompt and see how LLMs perform?\n- only 5 models are experimented\n\nPresentation:\n- How subset of paths are selected when paths are too long for the prompt? It's not clearly presented\n- We typically don't call such an approach neural-symbolic\n\nContribution:\n- This paper makes incremental contributions \n(1) Using LLMs for getting taint information. Typically in static analysis, we provide a list of taint APIs, it can be done precisely by the domain experts.\n(2) Using paths reported by CodeQL as context when prompting LLM. There have been work that uses output of the static analysis tools like infer as prompts", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "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": "UjCwCiDAqk", "reviewer": "Reviewer_j2y3", "summary": "The paper proposed IRIS, a neuro-symbolic approach that leverages LLMs to infer taint specifications and perform contextual analysis for security vulnerability detection in combination with static analysis tools like CodeQL. The evaluation comes with a newly curated dataset CWE-Bench-Java, comprising 120 manually validated security vulnerabilities in real-world Java projects. The experiment result shows that IRIS with GPT-4 detects 28 more vulnerabilities than CodeQL alone.", "questions": "1. As mentioned in the limitation section, \"IRIS makes numerous calls to LLMs for specification inference and filtering false positives, increasing the potential cost of analysis\" I would like to know the actual cost of LLM call for IRIS on CWE-Bench-Java in total and on average.", "limitations": "", "rating": 6, "confidence": 4, "soundness": 2, "presentation": 2, "contribution": 2, "strengths": "1. Originality: The paper proposed a new method that combined LLM with static analysis tool CodeQL to infer taint specifications and perform contextual analysis.\n2. Quality: The experiment shows huge improvement on bug detection effectiveness\n3. Clarity: The paper is well-written and implementation details like prompts and QL scripts are provided in appendix.\n4. Significance: The paper addressed challenges of static taint analysis like false negatives due to missing taint specifications, contributing to the field in the long term.", "weaknesses": "1. The paper doesn't address potential data leakage and memorization by LLMs, since they are asked to infer sources/taints purely based on method name and signature instead of implementation. The method may work well for projects where the APIs (sources and taints) are already publicly known, but not for private projects or less well-known projects. \n2. The comparison with baseline CodeQL may not be fair enough as the LLM-based method will always have advantages on bug detection numbers due to more source/sinks. It might be more convincing if LLM-based approach can be compared with heuristics shown in prompts like \"Taint source APIs usually return strings or custom object types.\" to see that LLM's advantage against heuristics like name and signature type matching.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "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": "6kLqaoDCVY", "reviewer": "Reviewer_3b2y", "summary": "This paper proposes using a neuro-symbolic approach, combining LLM and static taint analysis tool CodeQL, for whole-repository level, Java vulnerability detection. The authors curate CWE-Bench-Java, a vulnerability dataset of Java projects. Evaluation results show that IRIS is able to detect significantly more vulnerabilities compared with the baselines and are able to uncover previously unknown vulnerabilities.", "questions": "1. Can you add related works where the vulnerability is considered detected when the vulnerable path passes through some crucial program points (line 297-298)?\n2. Can you explain the design choices in Section 3? It seems to me that these may affect LLM's taints specification inference and predictions of false positives.\n   1. Few-shot (3-shot) for external APIs and zero-shot for internal APIs: does the number of shots affect the precision of LLM-inferred specifications?\n   2. $\\pm$ 5 lines surrounding the source and sink location (line 261), \n   3. A subset of nodes (line 263 - 264): how are they selected?", "limitations": "", "rating": 6, "confidence": 4, "soundness": 3, "presentation": 4, "contribution": 3, "strengths": "- IRIS includes a LLM filtering step via contextual analysis, as the use of LLM for sources and sinks predictions may incur many spurious alerts. The ablation study shows that this step can greatly improve Avg F1 score for larger models.\n- IRIS significantly outperforms prior methods in terms of the number of vulnerabilities detected and is able to uncover previously unknown vulnerability.\n\n- IRIS focus on project-level vulnerability detection on CWE-Bench-Java, which is inherently a challenging task as the projects are of large sizes.", "weaknesses": "- The false discovery rate of IRIS is very high (~90%) and the F1 score is low (around 0.1). The Avg FDR and Avg F1 scores for IRIS + GPT-3.5 / Lamma-3 / DeepSeekCoder are either worse or comparable to the CodeQL baseline.\n  - What are the causes of the undetected vulnerabilities (among the 120)?\n- A more rigorous discussion or evaluation should be conducted beyond random sampling of 50 alarms to argue that the actual false discovery rate should be much lower (line 397-399).\n- Models other than GPT-4 are over-approximating the specifications (Figure 7). The paper would benefit more from method designs to improve LLM-inferred specifications to lower the false discovery rate to save manual efforts of triaging through the alerts.\n\n- Presentation\n  - Line 377: \"IRIS's superior performance compared to CodeQL:\" Should be more careful with the language here, as Table 1 doesn't show its superiority on Avg FDR and F1 metrics.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "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": "hOjnCcBI4g", "reviewer": "Reviewer_nTbW", "summary": "The paper claims to be the first work to combine LLMs with static analysis to detect application-level security vulnerability via whole-project analysis. They propose a contextual analysis technique with LLMs that reduces false positive alarms and minimizes the triaging effort for developers. Their insight is that encoding the code context and path-sensitive information in the prompt elicits more reliable reasoning from LLMs. They curated a benchmarking dataset of real-world JAVA programs that contain 120 security vulnerabilities. They evaluate IRIS on the Java dataset using eight diverse open- and closed-source LLMs. Doing an extensive evaluation, they show that their method IRIS obtains the best results by detecting 55 vulnerabilities, which is 28 (103.7%) more than CodeQL, the existing best-performing static analyzer.", "questions": "1. They hypothesize that since LLMs are pre-trained on internet-scale data, they know about the behavior of widely used libraries and their APIs. So, can any new package or Java module not processed by the LLMs cause detection or specification generation issues?\n2. I want more details on the specification tuples, such as what are all the possible values for the type of node to match in G and what is the upper bound for N from the N-tuple of F?\n3. The authors mentioned including ±5 lines surrounding the exact source and sink location and the enclosing function and class. How did they come up with the \"5\" value? Can it be arbitrarily large, bounded by the LLM's token limitation?\n4. I would like to know if, in the event that CodeQL does not detect a vulnerability even with correctly labeled specifications,will it be marked as negative? Can you give me any statistics on how many such instances there are? If I understand correctly, CodeQL is still a critical part of the vulnerability detection pipeline. LLM just ensures that the data fed into the static analyzer is of quality, and once detection is made, LLM helps weed out false positives?\n5. Has it ever happened that LLM made a mistake and marked a positive case as negative even after the positive detection of a vulnerable path by CodeQL? I am trying to understand how accurate the LLM-based filtering method is and how drastic the change in explanation for detection will be based on the different specifications provided.", "limitations": "", "rating": 8, "confidence": 4, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "1. The paper addresses the long-standing security problem of decreasing the false positive rate of vulnerability detection while maintaining high enough accuracy.\n2. They have done a thorough evaluation using both open—and close-source LLMs and different static analysis baselines, such as Facebook Infer, SpotBugs, and Snyk.\n3. They introduced a new dataset with important characteristics such as containing vulnerability metadata, being compilable, demonstrating real work, and being validated.", "weaknesses": "1. Tested only on Java codebase.\n2. They have excluded code written in other languages that may flow to the Java components in the project during runtime or via compilation.\n3. An evaluation of how many detection misses were due to CodeQL's fault and how many were due to LLM's incorrect specification or filtering fault.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "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:

Decision: Accept (Poster)