LLM-assisted vulnerability discovery still fails on whole files

At a glance

What this is: Semgrep tested five models on vulnerability discovery and found whole-file prompting failed reliably, while function-level slicing improved results but still did not deliver dependable primary findings.

Why it matters: This matters because security teams experimenting with AI-assisted code review need to separate capability from confidence, especially when false positives, false negatives, and inconsistent recall affect operational decision-making.

By the numbers:

• Qwen 3.6-plus got the correct function in 8 of 8 attempts on the OpenBSD TCP SACK test.
• Opus 4.6 and GPT 5.4 each reached 8 of 8 correct function identifications in the sliced-function test.

👉 Read Semgrep's analysis of LLM-assisted vulnerability discovery results

Context

Large language models can help with code review, but vulnerability discovery is not the same as verification. When the target is an unknown bug in a full source file, the model has to infer the threat, the path, and the weakness without a precise starting point, which is where current systems remain brittle. This is a code-security problem, but it also touches identity security because false confidence in automated analysis can hide exposed secrets, unsafe service credentials, and weak trust boundaries inside software delivery pipelines.

The article argues for a narrower workflow: use LLMs to interrogate hotspots after a deterministic pre-filter has identified suspicious code. That is a more realistic model for security operations because it reduces search space and helps teams focus review effort, rather than asking the model to replace expert reasoning. For practitioners, the starting position is already familiar: broad automated scanning finds noise, not certainty, unless it is paired with stronger triage and control logic.

Key questions

Q: How should security teams use LLMs in vulnerability research without overtrusting them?

A: Use LLMs as structured reasoning aids, not as final arbiters of exploitability. Keep them inside a workflow that includes architectural context, reachability checks, and human review of any claim that crosses a trust boundary. That approach preserves speed without turning AI output into an unvalidated security verdict.

Q: Why do whole-file AI scans miss vulnerabilities more often than focused reviews?

A: Whole-file scans force the model to solve an open-ended discovery problem across too much context. Focused reviews reduce ambiguity by giving the model a known function or hotspot, which shifts the task closer to verification. The limitation is not just model quality, but the search problem itself.

Q: What do security teams get wrong about model accuracy in code analysis?

A: They often treat a partially correct answer as proof of capability. In practice, the model may name the right function but miss the primary finding, the exploitable condition, or the mechanism. Accuracy should be measured across the full review chain, not as a binary yes or no.

Q: How do teams decide whether model-assisted review is good enough for production use?

A: Judge it by precision, recall, consistency, and reviewer time saved on real code samples. If the model needs repeated runs, heavy prompting, or extensive correction to find the same bug, then it is useful for assistance but not yet reliable as a standalone control.

Technical breakdown

Why whole-file prompting misses real vulnerabilities

Whole-file prompting asks a model to search an entire codebase or source file for an unknown weakness, which is a discovery problem, not a verification problem. Discovery requires the system to infer where to look, what matters, and which preconditions matter before it can reason about the bug itself. That makes the task far harder than checking a known flaw against a known description. In security terms, the model is operating under uncertainty and limited salience, so it can miss the right function even when it understands the general vulnerability class.

Practical implication: Use whole-file AI scanning only as a broad triage layer, not as evidence that a code path is safe.

How function slicing changes model performance

When the model is given the exact function that contains the flaw, the problem becomes constrained enough for current systems to perform much better. The model is no longer performing open-ended discovery across unrelated code, but evaluating a bounded unit where control flow, data flow, and preconditions are easier to assess. That does not make the output reliable by itself. It simply shifts the task closer to verification, where LLMs are stronger. Even then, false positives and incomplete bug chains remain a practical limitation.

Practical implication: Pre-filter suspicious code paths before asking an LLM to assess exploitability or root cause.

Why diversity and deterministic pre-filtering matter

The article shows that model diversity can outperform homogeneous reliance on a single system, because different models fail in different ways. That is a useful operating lesson for security engineering. Deterministic pre-filtering narrows the candidate set, while multiple model passes can expose disagreements worth human review. This is closer to a detection pipeline than a single verdict engine. For code security, the goal is not a perfect model response. It is a workflow that improves precision, reduces review cost, and makes missed findings more visible.

Practical implication: Combine deterministic filters with multiple model passes and human review for the final decision.

Threat narrative

Attacker objective: The attacker’s objective is to exploit unreviewed code paths that automated analysis failed to surface, turning missed findings into workable vulnerabilities.

1. Entry occurs when insecure or vulnerable code remains hidden in a large file that automation must discover without a precise prompt or hotspot.
2. Escalation happens when the model can only identify the issue after being told the exact vulnerable function or given highly specific hints.
3. Impact is a false sense of security, because teams may trust an incomplete scan result and leave exploitable code unreviewed.

NHI Mgmt Group analysis

LLM-assisted vulnerability discovery is a triage problem before it is a detection problem. Security teams are already using models to reduce review load, but this article shows that broad discovery remains unreliable without strong pre-filtering. That matters because code-security workflows often sit upstream of identity risk, secret leakage, and trust boundary failures in delivery pipelines. Practitioners should treat AI output as a prioritisation signal, not a finding.

Function-level context is the practical boundary for current model utility. Once the model is given a bounded function, it can reason more effectively about data flow and exploit conditions. That improves review efficiency, but it also makes the governance question sharper: who decides which code paths are worthy of model attention, and which findings are promoted for human review? Teams should align model scope with explicit triage rules.

Model diversity is an operational control, not a novelty metric. The article’s mixed results across frontier and open-source models show that different systems fail in different ways. In governance terms, that means single-model reliance creates blind spots that compound over time. For security programmes, the practitioner conclusion is straightforward: diversity, not confidence language, is what reduces analyst dependence on one imperfect view.

Deterministic filtering is the named control concept here: hotspot-first analysis. The article’s strongest result came from pairing LLM interrogation with deterministic pre-filtering to surface likely targets first. That is a better fit for security engineering because it constrains search space before reasoning begins. For practitioners, the lesson is to build model-assisted review around filtered hotspots, not raw repositories or entire files.

This pattern also has an identity-security intersection when code review is the last line before secrets, tokens, or service credentials ship. LLM misses in source analysis can leave NHI secrets embedded in code, configuration, or CI/CD paths. That links code-security tooling directly to NHI governance and secrets management. Security teams should therefore connect AI-assisted review to identity controls, not treat it as a standalone AppSec experiment.

What this signals

The operating signal for security programmes is that AI-assisted review is maturing into a workflow tool, not a judgment engine. Teams that want value from it should pair it with deterministic scanners, hotspot triage, and a reviewer loop that can absorb uncertainty without turning it into false confidence.

Hotspot-first analysis: this is the control pattern that will matter most as model-assisted security tooling spreads. If your pipeline can already isolate suspicious functions, secret-bearing files, and high-risk code paths, then model assistance becomes more usable and more governable. That same discipline helps identity teams reduce leakage of service credentials into code and CI/CD.

For identity-led programmes, the crossover point is secrets hygiene. AI code review will not compensate for weak service account governance, and it will not reliably catch every exposed credential. Security teams should therefore treat source-code analysis as one input to broader NHI and secrets management controls, not as a substitute for them.

For practitioners

• Use hotspot-first triage before model review Feed the model only code that deterministic scanners, taint analysis, or static rules have already flagged as suspicious. That reduces search space and makes the model’s job closer to verification than discovery.
• Require human validation for primary findings Treat model output as a candidate signal until a reviewer confirms the vulnerable function, preconditions, and plausible exploit path. Do not let a single model output close the case.
• Measure false positives and false negatives separately Track whether the model identifies the right function, the right mechanism, and the right exploit conditions. A partially correct answer should not count as a passed review if it misses the primary finding.
• Add identity and secrets controls to code review workflows Connect AI-assisted code review to secret scanning, service account hygiene, and CI/CD access controls so missed vulnerabilities do not become exposed credentials or persistent NHI trust issues.

Key takeaways

• Whole-file LLM prompting is too broad to serve as a dependable vulnerability discovery control.
• Focused, hotspot-first review improves results, but human validation remains necessary for primary findings and exploit conditions.
• The most effective operating model combines deterministic filtering, model diversity, and identity-aware secrets controls.

Key terms

• Hotspot-first analysis: A review method that narrows AI-assisted inspection to code paths already flagged as suspicious by deterministic controls. It improves signal quality by reducing the search space before the model reasons about exploitability, preconditions, and likely impact.
• False negative: A missed finding that is actually present in the code or system. In security review, false negatives are often more dangerous than noisy alerts because they create confidence that a vulnerable path, secret exposure, or trust issue does not exist.
• Primary finding: The main vulnerability or risk a reviewer should identify in a code path. A response can mention the right area but still fail if it does not name the actual flaw, the exploitation mechanism, or the conditions required for abuse.

What's in the full report

Semgrep's full post covers the experimental detail this analysis intentionally leaves for the source:

• Per-model result tables showing how each model performed across full-file and sliced-function tests.
• Per-iteration breakdowns that expose where models corrected themselves, missed the right function, or produced null responses.
• Appendix score definitions that explain how the team distinguished full, partial, broad, secondary, miss, and null outcomes.
• Operational comparison of naive whole-file prompting versus hotspot interrogator workflows with deterministic pre-filtering.

👉 Semgrep's full post covers the model-by-model tables, scoring rules, and hotspot workflow findings

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, identity lifecycle, and workload identity. It helps security practitioners connect identity controls to the operational risks created by modern delivery pipelines.