PaperlayerView exact revision on arXiv

Source-linked AI summary

IRIS: LLM-Assisted Static Analysis for Detecting Security Vulnerabilities

Ziyang Li, Saikat Dutta, Mayur Naik

arXiv:2405.17238v3cs.CRcs.PLcs.SE

TL;DR

Static vulnerability analysis is limited by missing manually authored taint specifications, false positives from imprecise context handling, and the difficulty of whole-repository reasoning. IRIS combines LLM-inferred taint specifications and contextual analysis with static analysis, achieving stronger detection results on CWE-Bench-Java while retaining important scope and cost limitations.

  • Problem

    Static analysis depends on laborious, error-prone third-party API specifications and can produce false alarms, while LLMs struggle with the contextual reasoning required for whole-repository vulnerability detection.

  • Method

    IRIS combines LLMs with static analysis to infer CWE-specific taint specifications and perform contextual analysis for whole-repository vulnerability detection.

  • Results

    IRIS with GPT-4 detected 55 vulnerabilities on CWE-Bench-Java, 28 (103.7%) more than CodeQL, with an average false discovery rate of 84.82%, 5.21% lower than CodeQL's.

  • Takeaways & Limitations

    Systematically combining LLMs with static analysis improves detected bugs and alleviates developer burden compared with traditional static analysis alone.

  • Takeaways & Limitations

    IRIS makes numerous LLM calls that increase analysis cost, and its performance beyond Java is unknown.

Abstract

from arXiv · show

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.

1 INTRODUCTION

IRIS combines LLMs with static analysis to infer vulnerability-specific taint specifications and perform contextual, whole-repository reasoning. On CWE-Bench-Java, it detects more vulnerabilities than CodeQL while reducing false discovery rate and finding previously unknown vulnerabilities.

  • 1 INTRODUCTION: 29,000+ CVEs were reported in 2023, underscoring the challenge of detecting software vulnerabilities despite advances in static analysis.Static taint analysis is widely used in tools including CodeQL, Infer, Checker Framework, and Snyk Code.
  • 1 INTRODUCTION: Manual third-party API taint specifications are laborious and error-prone, causing missing specifications and incomplete vulnerability analysis.Existing specifications also require periodic updates for newer library versions and newly developed libraries.
  • 1 INTRODUCTION: Static analysis can generate false alarms because of spurious specifications, branch and input over-approximation, and non-exploitable usage contexts.Developers may need to triage numerous potentially false security alerts.
  • 1 INTRODUCTION: IRIS combines LLM-inferred CWE-specific taint specifications with CodeQL and uses LLM-based contextual analysis to reduce false positives and human inspection effort.The approach targets more precise whole-repository reasoning than LLM-only method-level vulnerability detection.
  • 1 INTRODUCTION: CWE-Bench-Java contains 120 manually vetted vulnerabilities across four classes in compilable real-world Java projects averaging 300K lines of code.Ten projects contain more than a million lines of code each, making the benchmark challenging for vulnerability detection.
  • 1 INTRODUCTION: 55 vulnerabilities were detected by IRIS with GPT-4, 28 (103.7%) more than CodeQL; its average false discovery rate was 84.82%, 5.21% lower than CodeQL's.Applied to the latest versions of 30 Java projects, IRIS with GPT-4 also discovered 4 previously unknown vulnerabilities.

2 MOTIVATING EXAMPLE

The cron-utils example shows why whole-repository vulnerability detection must connect data and control flow across internal methods and third-party APIs. IRIS infers missing specifications with LLMs, augments CodeQL, and applies contextual analysis to filter false positives.

  • 2 MOTIVATING EXAMPLE: The cron-utils vulnerability involves a user-controlled string flowing unsanitized from isValid to parse and into an error-message construction path.The resulting message is used with ConstraintValidatorContext, whose method interprets the message.
  • 2 MOTIVATING EXAMPLE: 13K SLOC and flows across internal methods and third-party APIs make the cron-utils vulnerability difficult to analyze.The analysis must identify relevant sources, sinks, and sanitizers, including the public isValid parameter and external APIs.
  • 2 MOTIVATING EXAMPLE: CodeQL fails to detect the vulnerability because of missing specifications, while manually obtaining and validating specifications requires substantial human effort.Even complete specifications may leave CodeQL with numerous false positives because it lacks contextual reasoning.
  • 2 MOTIVATING EXAMPLE: IRIS infers project- and vulnerability-specific specifications on the fly, augments CodeQL, and detects the unsanitized source-to-sink path.Its contextual analysis encodes detected paths and surrounding context to address false positives that logical rules cannot easily eliminate.

3 IRIS FRAMEWORK

IRIS combines LLM-inferred taint specifications with CodeQL-based static analysis and contextual path filtering to detect vulnerability-specific unsanitized dataflows across Java repositories.

  • Overview: IRIS takes a Java project, vulnerability class, and LLM as inputs, then returns potential alerts with vulnerable source-to-sink code paths.Each alert includes a unique path that is unsanitized for the target vulnerability class.
  • Taint specification inference: IRIS extracts external and internal API candidates, asks an LLM to label vulnerability-specific sources and sinks, and converts those labels into static-analysis specifications.External APIs may be sources or sinks, while internal API parameters may be identified as sources.
  • Design challenges: The framework addresses two taint-analysis challenges: identifying relevant specifications for each vulnerability class and eliminating false-positive paths.Unknown third-party API specifications reduce analysis effectiveness, while imprecise paths increase developer triage burden.
  • Static analysis: IRIS uses CodeQL to represent programs as dataflow graphs and run vulnerability-class-specific queries over the inferred specifications.The resulting query identifies candidate unsanitized paths between taint sources and sinks.
  • Contextual analysis: IRIS applies an LLM-based filter to classify detected paths as true or false positives using CWE information, code snippets, and surrounding path context.For long paths, the prompt retains only a subset of nodes; false-positive source or sink labels can help prune other paths.
  • Evaluation metrics: Evaluation uses vulnerability detection count, average false discovery rate, and average F1 over projects containing at least one known vulnerability.A vulnerability counts as detected when a reported path passes through a labeled vulnerable program location.

4 CWE-BENCH-JAVA: A DATASET OF SECURITY VULNERABILITIES IN JAVA

CWE-Bench-Java is a curated benchmark of manually validated vulnerabilities in compilable, real-world Java projects, created because no existing dataset met all evaluation requirements.

  • Dataset requirements: No existing dataset satisfied the required combination of vulnerability metadata, compilable projects, real-world complexity, and validated vulnerability locations.These properties support static analysis, dataflow extraction, and robust evaluation.
  • Dataset construction: CWE-Bench-Java contains 120 manually vetted vulnerabilities, one per project, across four common vulnerability classes.The dataset consists of compilable Java projects.
  • Dataset construction: The benchmark focuses on Java libraries available through Maven and draws candidate vulnerabilities initially from the GitHub Advisory database.Java was selected because of its use in server-side, Android, and web applications and its large history of CVEs.

5 EVALUATION

The evaluation tests IRIS across existing and previously unknown Java vulnerabilities, specification quality, and component ablations. IRIS with GPT-4 detects more vulnerabilities than CodeQL while reducing average false discovery rate, with performance depending on model reasoning capability.

  • RQ1: Effectiveness of IRIS: IRIS consistently outperforms the compared baselines across vulnerability classes, except Llama-3 8B on CWE-22; CWE-78 remains challenging for all LLMs.CWE-78 difficulties involve intricate gadget chains and external side effects that are difficult for static analysis to track.
  • RQ2: Previously Unknown Vulnerabilities: IRIS with GPT-4 finds 4 previously unknown vulnerabilities in 30 Java projects, including three path-injection cases and one code-injection case.CodeQL alone did not detect these vulnerabilities; one example resulted from GPT-4 identifying a missing source specification.
  • RQ3: Quality of LLM-Inferred Taint Specifications: GPT-4 achieves the highest sink-specification recall at 87.11%, while manual evaluation finds its inferred specifications have precision above 70%.Source-specification recall is generally lower, and other LLMs combine high recall with lower precision, suggesting over-approximation.
  • RQ4: Ablation Studies: Omitting either GPT-4-inferred source or sink specifications causes a drastic reduction in overall recall, showing that both are necessary.The ablation compares IRIS variants using only source or only sink specifications.
  • RQ4: Ablation Studies: Contextual analysis improves precision and F1 for GPT-4, GPT-3.5, and Llama-3 70B, but harms smaller models, indicating dependence on reasoning capability.Its false-positive reduction is most effective when the LLM has decent reasoning capability.

6 RELATED WORK

Prior vulnerability-detection approaches include learning-based method-level classifiers and static-analysis tools, while IRIS combines LLMs with static analysis for whole-project analysis and code-path reporting.

  • Learning-based approaches for vulnerability detection: Learning-based vulnerability detectors commonly use graph neural networks, LSTMs, or Transformer fine-tuning at the method level.These approaches generally provide a binary vulnerable/not-vulnerable label for each method.
  • LLM-based approaches for software engineering: Contextual analysis improves average precision and average F1 in the reported evaluation.
  • Learning-based approaches for vulnerability detection: IRIS performs whole-project analysis, reports a distinct source-to-sink code path, and can target different CWEs.
  • Static analysis tools: CodeQL is described as more feature-rich and effective than other listed static-analysis tools for vulnerability detection.
  • LLM-based approaches for software engineering: IRIS is among the first approaches to combine LLMs with static analysis for application-level security vulnerabilities through whole-project analysis.

7 CONCLUSION AND LIMITATIONS

IRIS combines LLMs with static analysis and is evaluated with CWE-Bench-Java, while the authors report improved detection and reduced developer burden but several remaining limitations.

  • Conclusion: IRIS combines LLMs with static analysis for vulnerability detection and is evaluated on 120 vulnerabilities across four classes in real-world projects.
  • Conclusion: The authors report improvements over traditional static analysis in detected bugs and alleviation of developer burden.
  • Limitations: IRIS cannot detect many vulnerabilities, and tighter integration of LLMs with static analysis is identified as future work.
  • Limitations: IRIS makes numerous LLM calls, increasing potential analysis cost, and its performance beyond Java remains unknown.
  • Limitations: The generated IRIS report still differs from the report developers would like to see.

A.1 SELECTING CANDIDATE SPECIFICATIONS

IRIS selects candidate source and sink specifications from external and internal Java APIs, then uses LLM prompts to classify APIs and contextual-analysis settings to support specification inference.

  • Candidate source and sink selection: IRIS considers non-void external APIs as candidate sources and external API arguments, including implicit this arguments, as sinks.
  • Candidate source and sink selection: The authors acknowledge that other source and sink kinds exist but exclude them because of complexity.
  • LLM prompts for specification inference: The external-API prompt classifies APIs as Source, Sink, Taint-Propagator, or None using CWE-specific information and JSON output.
  • LLM prompts for specification inference: The internal-API prompt uses project documentation to identify formal parameters that downstream libraries might invoke with malicious inputs.
  • LLM prompts for specification inference: Few-shot examples support external-API labeling, whereas internal-API labeling relies on zero-shot capabilities with additional documentation.
  • Contextual analysis: Contextual analysis uses ±5 lines around source and sink locations to balance available context against performance and cost.

B.1 DETAILS OF DATASET EXTRACTION PROCESS

The dataset-extraction process builds projects for CodeQL, validates Java-file fixes, and excludes unsuitable cases; the resulting benchmark addresses limitations in prior datasets.

  • Build and validation: IRIS requires each project to be built so CodeQL can extract data-flow graphs, using a script that tries Java and Maven version combinations.
  • Vulnerability-path validation: Figure 10 treats only the path passing through the fixed sanitizer as vulnerable when both sinks could cause Path-Traversal.
  • Dataset construction: The resulting dataset contains 120 manually vetted vulnerabilities across four classes in real-world Java projects.
  • Build and validation: The extraction process manually validates whether each fix commit fixes the target CVE in a Java file and excludes fixes implemented in other languages.
  • Dataset construction: Compared with a prior 165-CVE Java dataset, CWE-Bench-Java provides build scripts, broader CWE coverage, and scripts for extending the dataset.

B.2 COMPARISON OF OUR CWE-BENCH-JAVA WITH EXISTING VULNERABILITY DATASETS

CWE-Bench-Java is compared with existing vulnerability datasets using five coverage and quality criteria. It is reported as the only dataset satisfying all five criteria.

  • Dataset comparison: CWE-Bench-Java is compared with existing datasets using CVE metadata, real-world projects, fix locations, compilability, and manual vetting.These criteria assess dataset provenance, completeness, reproducibility, and validation.
  • Dataset comparison: CWE-Bench-Java is the only compared dataset reported to satisfy every criterion.The paper presents this result as evidence of the dataset’s significance.
  • Evaluation setting: The dataset comparison is presented alongside IRIS evaluations using selected closed-source and open-source LLMs and CodeQL as the static-analysis backbone.The evaluation uses GPT-4, GPT-3.5, six open-source LLMs, and CodeQL version 2.15.3.
  • Taint specifications: CWE-Bench-Java contains both unique and recurring inferred source and sink specifications across projects, indicating that new relevant APIs remain to be identified continuously.Table 7 covers project-specific specifications, while Table 8 covers specifications recurring across at least two projects.
  • Taint specifications: GPT-4 generates a smaller set of source and sink specifications than smaller-scale models such as DeepSeekCoder 7B.The comparison is reported using the per-CWE and total ratios of API candidates labeled as sources or sinks.

C.7 ERROR ANALYSIS: CAUSE OF UNDETECTED VULNERABILITIES

Undetected vulnerabilities arise from limits in simple taint-flow modeling, missing dataflow edges, and LLM omissions. The analysis distinguishes static-analysis limitations from LLM-induced false negatives.

  • Static-analysis limitations: Some vulnerabilities cannot be modeled as simple taint dataflows, such as an unexpected exit(1) call controlled by tainted conditional data.The sink-API model cannot capture this vulnerability because the taint reaches the surrounding if condition rather than the exit call directly.
  • Static-analysis limitations: Missing dataflow edges can result from side effects or unspecified library usage.Examples include taint written to and later read from a temporary file, and vulnerabilities requiring concrete library usage not connected inside the library.
  • LLM-induced false negatives: LLM-induced false negatives arise when taint propagator labels or source and sink specifications are missing.Missing propagator labels stop flow from source to sink, while missing source or sink specifications remove the analysis anchor.

D ANALYSIS RUNTIME

The runtime analysis reports project-level analysis costs together with project size, candidate API counts, and inferred source and sink counts. These details are organized in Table 10.

  • Runtime and project statistics: Table 10 reports each project’s CWE ID, source lines of code, full-analysis runtime, candidate API count, and Llama 3 8B source and sink labels.The table combines project characteristics with analysis workload and inferred specification counts.
  • Runtime and project statistics: Runtime cells are highlighted red at ≥1h and yellow at ≥5m, while SLOC cells are red above 1M and yellow above 100k.These thresholds identify projects with comparatively large codebases or longer analyses.
Loading 2405.17238v3…