💻 computer science

LLM vs. SAST: A Technical Analysis on Detecting Coding Bugs of GPT4-Advanced Data Analysis

This paper presents a controlled study demonstrating that GPT-4 (Advanced Data Analysis) significantly outperforms aggregated SAST tools (SonarQube and Cloud Defence) in detecting coding vulnerabilities across 32 security scenarios, achieving a 93.75% detection rate compared to 34.375% with statistical significance.

Original authors: Madjid G. Tehrani, Eldar Sultanow, William J. Buchanan, Mahkame Houmani, Christel H. Djaha Fodja

Published 2026-07-15

📖 3 min read☕ Coffee break read

CC BY 4.0

Original authors: Madjid G. Tehrani, Eldar Sultanow, William J. Buchanan, Mahkame Houmani, Christel H. Djaha Fodja

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you're a detective trying to catch a sneaky thief who hides in the code of a computer program. For years, you've relied on a team of robot inspectors (called SAST tools) to scan the code. These robots are great at following a strict checklist: "If you see a red door, mark it." But sometimes, the thief hides behind a blue door that looks like a red one, or they use a trick the checklist doesn't know about. The robots miss these sneaky tricks, or they get confused and flag harmless things as dangerous.

Now, a new detective has joined the team: GPT-4, a super-smart AI that reads code like a story. The big question was: Can this new AI detective spot the tricky security holes better than the old robot inspectors?

The Great Detective Showdown

To find out, the researchers set up a fair test. They created 32 specific "crime scenes" (security scenarios) based on real-world coding mistakes, like leaving a backdoor open or letting bad guys inject fake commands. They handed these scenes to:

The Robot Team: Two different robot inspectors (SonarQube and Cloud Defence). They worked together, and if either robot spotted a problem, it counted as a win for the robots.
The AI Detective: GPT-4, which was asked to read the code and explain what was wrong.

The Scoreboard

Here is what happened when they compared the results:

The Robot Team: They caught 11 out of the 32 crimes. That's about 34% of the time.
The AI Detective: GPT-4 caught 30 out of the 32 crimes. That's a whopping 93.75% success rate!

The researchers used a special math test (called McNemar's test) to make sure this wasn't just luck. The result was a clear "yes": the AI detective was statistically much better at finding these specific bugs than the robot team in this controlled experiment.

What This Means (and What It Doesn't)

The paper suggests that AI like GPT-4 could be a powerful sidekick to the robot inspectors. It's great at understanding the story behind the code and spotting complex tricks that rigid checklists miss. This could help developers fix holes faster and maybe even save money on expensive tools.

However, the paper is very careful not to say the robots are obsolete.

It's not a magic wand: The AI isn't perfect. It missed 2 out of 32 cases, and the robots caught some things the AI didn't.
It's not a replacement: The authors argue we shouldn't just throw away the robots. Instead, we should use the AI to help the robots, especially for tricky cases that need human-like reasoning.
New dangers: The paper warns that using AI brings new risks. Just like a thief can trick a robot, a bad actor could trick the AI (using things like "prompt injection" or hiding bad instructions in the training data). If we aren't careful, the AI could even generate code that looks safe but is actually full of holes.

The Bottom Line

In this specific test with 32 carefully chosen examples, the AI detective proved it could see things the robot inspectors missed. But the researchers say this is just the beginning. We need to be careful, keep testing, and remember that while the AI is a brilliant new tool, it's not a solved problem yet. It's a powerful partner, but it still needs a human to hold the flashlight and check its work.

Technical Summary: A Methodology for Analysing Coding Bugs for LLMs and SAST

Problem Statement

The paper addresses a critical gap in cybersecurity: the insufficient quantification of Large Language Models' (LLMs) practical effectiveness for vulnerability detection compared to established Static Application Security Testing (SAST) tools. While SAST is the industry standard for identifying security defects prior to deployment, it frequently suffers from high false-negative rates (missing exploitable vulnerabilities) and false positives (prioritizing non-issues), which delays remediation and widens the "window of vulnerability." Conversely, while LLMs like GPT-4 have demonstrated promise in code understanding, there is a lack of transparent, reproducible methodologies to determine if they can detect a broad set of real-world vulnerability patterns more effectively than traditional SAST tools under controlled conditions.

Methodology

The authors present a controlled comparative study designed to evaluate GPT-4 (specifically the Advanced Data Analysis interface) against two SAST tools: SonarQube (SonarCloud) and Cloud Defence.

Dataset: The study utilized 32 curated security scenarios representing common coding pitfalls and zero-day potential vulnerabilities. These scenarios were sourced from GitHub and Snyk, mapped to the MITRE Common Weakness Enumeration (CWE), and covered a diverse range of issues including SQL Injection, Buffer Overflows, and Container Privilege Escalation.
Experimental Design:
- SAST Baseline: The outputs of SonarQube and Cloud Defence were aggregated using a logical OR operation. A vulnerability was considered detected by the "SAST baseline" if either tool flagged it.
- LLM Execution: Each code snippet was submitted to GPT-4 with a fixed instruction to identify security vulnerabilities and explain the issue.
- Scoring: A binary scoring rule was applied. A detection was scored as 1 (Correct) if the tool explicitly identified the intended vulnerability type consistent with the assigned CWE. Otherwise, it was scored as 0 (Miss).
Statistical Analysis: Given that each code sample yielded paired binary outcomes (GPT-4 vs. Aggregated SAST), the authors employed McNemar's test for statistical inference on paired nominal data. A contingency table was constructed to categorize outcomes into: both correct, SAST-only, LLM-only, and both incorrect. A p-value below 0.05 was established as the benchmark for statistical significance.

Key Results

The study yielded the following quantitative findings:

Detection Rates: GPT-4 correctly detected 30 out of 32 scenarios (93.75%). The aggregated SAST baseline detected only 11 out of 32 scenarios (34.38%).
Discrepancy Analysis: The paired comparison revealed a significant directional imbalance. There were 22 cases where GPT-4 detected the vulnerability but the SAST tools missed it (cell c in the contingency table), whereas there were 0 cases where SAST tools detected a vulnerability that GPT-4 missed (cell b).
Statistical Significance: McNemar's test produced a Chi-square value of 20.046 with a p-value of 0.000007562.
Hypothesis Testing: Based on these results, the null hypothesis ( $H_0$ : GPT-4 performs the same or worse than SAST) was rejected in favor of the alternative hypothesis ( $H_1$ : GPT-4 performs better than SAST) at the 5% significance level.

Key Contributions

The paper's primary contribution is not the introduction of a new vulnerability detector, but rather the establishment of a transparent, reproducible evaluation protocol for comparing LLMs and SAST tools. This methodology includes:

A curated set of representative vulnerability scenarios.
A consistent binary scoring rule for detection outcomes.
An aggregated SAST baseline using a logical OR operation.
The application of paired statistical inference (McNemar's test) to compare detectors on identical inputs.

This framework allows for controlled measurement of relative detection capabilities, moving beyond anecdotal evidence to statistically grounded comparisons.

Significance and Claims

The authors claim that their findings demonstrate that general-purpose LLMs can serve as powerful supplements, and potentially alternatives, to traditional SAST tools for specific vulnerability detection tasks. The study suggests that LLMs may be particularly effective at identifying complex vulnerability mechanisms that rule-based static analysis misses.

However, the paper maintains a modest and cautious tone regarding the implications:

Complementary Role: The authors explicitly state the goal is not to replace SAST but to characterize when an LLM is complementary. SAST remains valuable for systematic, rule-based analysis and CI/CD integration.
Operational Constraints: The study highlights that LLMs are not infallible. They rely on training data patterns and may fail to detect novel vulnerabilities emerging after their training cut-off.
Security Risks: The paper acknowledges the security risks of integrating LLMs into secure workflows, including prompt injection, model theft, and the potential for LLMs to generate insecure code. It advocates for "Secure by Design" principles, Zero Trust Architecture, and the use of Federated Learning (FL-LLM) to enhance resilience.
Limitations: The authors note limitations including the bounded scenario set (32 samples), reliance on specific tool configurations at the time of testing, and the use of static snippets rather than full projects or runtime environments.

In conclusion, the paper provides empirical evidence that, under controlled conditions, GPT-4 significantly outperformed a combined SAST baseline in detecting a specific set of coding bugs, supporting the integration of LLM-assisted analysis into secure software development lifecycles as a complementary capability.