LLM-assisted vulnerability discovery still fails on whole files

At a glance

What this is: Semgrep reports that whole-file LLM vulnerability discovery failed across five models, while function-level narrowing improved performance but did not eliminate misses or false positives.

Why it matters: Security teams should treat LLMs as scoped analysis tools inside a broader review workflow, not as autonomous vulnerability discovery systems that can reliably replace human triage.

Context

Large language models can assist security analysis, but whole-file vulnerability discovery still depends on precise context, strong prompting, and human interpretation. In this article, Semgrep tests whether models can move from recognising a known bug to finding it in an unfamiliar codebase, which is a harder governance problem for secure development and AI-assisted review.

The identity and access angle is indirect but real: when security teams use AI to inspect code, they are delegating parts of detection judgment to a system that can miss issues, overfit to hints, or produce false confidence. That makes tool placement, scope control, and validation as important as model choice, especially where the output feeds engineering or remediation decisions.

Key questions

Q: Why do whole-file LLM prompts fail more often for vulnerability discovery?

A: Whole-file prompts force the model to infer the bug, the relevant code path, and the preconditions from too much context at once. That expands noise, increases false positives, and makes the correct issue easier to miss. For security teams, the failure is architectural, not just model quality: the task is poorly bounded for reliable discovery.

Q: When should teams prioritise hotspot analysis over broad LLM scanning?

A: Prioritise hotspot analysis when the goal is finding likely vulnerabilities rather than summarising a codebase. Narrowing the scope improves signal, reduces irrelevant context, and makes human validation faster. If the review target is high risk or time sensitive, broad scanning should be treated as triage, not as a substitute for targeted inspection.

Q: How can security teams tell whether LLM evaluation is actually working?

A: Look for continuous coverage across live traffic, regression testing on new prompts or models, and sampled human review of judge outputs. If evaluation only runs during development, it is not detecting drift, prompt changes, or attack-path changes in production. Working evaluation should change deployment decisions, not just produce dashboards.

Q: What is the difference between LLM-assisted triage and autonomous vulnerability discovery?

A: LLM-assisted triage narrows attention, explains suspicious code, and helps humans review faster. Autonomous discovery implies the model can reliably find the bug, justify the finding, and do so with stable precision across runs. The article shows the first use case is realistic today, while the second still breaks down on whole files.

Technical breakdown

Why whole-file vulnerability discovery is harder than verification

Verification starts with a known target, while discovery requires the model to infer both the bug class and the relevant code path from much broader context. That difference matters because whole-file analysis increases noise, distracts the model with irrelevant code, and makes the correct function easier to miss. In security terms, the task is not simply pattern matching. It requires prioritising evidence, rejecting false leads, and maintaining consistency across long contexts, which current LLMs still do unevenly.

Practical implication: use LLMs to narrow candidate areas, not to replace targeted human review of the full codebase.

Why function slicing improves LLM security analysis

When the model is given a smaller unit, it can focus on local control flow, preconditions, and suspicious operations without having to reconstruct the entire file's intent. That improves the odds of finding the bug because the model spends less effort on irrelevant context and more on the immediate exploit surface. But slicing also changes the task itself. It reduces discovery burden while leaving residual risk around incomplete reasoning, because the model may still recognise the right area without proving the correct vulnerability.

Practical implication: pair scoped LLM analysis with deterministic filtering or code search that selects likely hotspots before review.

Why false positives and false negatives still define the boundary

The article shows that getting the right function is not the same as identifying the correct vulnerability, and that distinction is the core operational limit. Security workflows need both true positives and acceptable precision, because a flood of weak findings creates analyst fatigue while a missed bug creates residual exposure. In other words, LLMs can raise signal, but they do not yet close the loop between finding, validating, and exploiting with enough reliability to operate alone.

Practical implication: measure LLM-assisted review on precision, repeatability, and downstream validation cost, not on whether it can occasionally name the right file.

Threat narrative

Attacker objective: The practical objective is not adversary exploitation but accurate vulnerability identification, which the article shows remains fragile when the model is left to inspect whole files.

1. Entry occurs through broad, whole-file prompting that asks the model to discover vulnerabilities without narrowing the search space.
2. Credential access is not the issue here; the failure mode is analytical access to the right code path, which the model often does not obtain from the full file.
3. Escalation happens when the model latches onto the wrong function, yields a secondary finding, or misses the exploit preconditions that distinguish signal from noise.
4. Impact is incomplete vulnerability discovery, with false confidence on one side and false negatives on the other, making the workflow unreliable for autonomous triage.

Breaches seen in the wild

• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
• SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Whole-file prompting is not a governance model for secure code review: it is a search strategy with known failure modes. The article demonstrates that discovery degrades when the model must infer the bug from too much context, which means teams cannot treat a broad prompt as a control. Practitioners should see this as a workflow design problem, not a model marketing problem.

Context shaping is the real control surface: the difference between whole-file and function-level performance shows that security outcomes depend on how the task is framed. That is directly relevant to AI-assisted application security and code analysis, where the model's input boundary determines whether it can support review or merely generate plausible noise. The practitioner lesson is to govern task scope as carefully as output review.

False confidence is the main operational risk in AI-assisted vulnerability discovery: a model that names the right area but misses the preconditions still leaves analysts with work to do. In program terms, that means acceptance criteria, human verification, and repeatability thresholds must be explicit before LLM-assisted findings enter the remediation queue.

Targeted assistive use will outlast generic discovery claims: the article's strongest result is not that LLMs fail, but that they work better when paired with deterministic pre-filtering and narrow prompts. That points toward a durable operating model in which AI assists hotspot selection and explanation, while human reviewers and deterministic tooling retain final responsibility for exploit validation.

Code review teams need an AI assurance layer, not just an AI assistant: the article shows why security teams should measure how often the model finds the right issue, not just whether it says something plausible. In practice, that means establishing review thresholds, spot-checking consistency, and routing only high-confidence findings into the remediation path.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Top 10 NHI Issues

What this signals

Whole-file analysis still creates an assurance gap: if the task boundary is too wide, LLMs can sound confident while missing the decisive code path. Security teams should treat that as a programme design issue and place model output behind deterministic filters and human review.

Hotspot-first workflows are the more defensible pattern: the article reinforces a practical shift from asking models to find everything to asking them to inspect what other controls have already flagged. That aligns better with secure development operations, where human judgement remains the final gate on exploitability.

AI-assisted code review needs measurable trust boundaries: teams should define where model output is advisory, where it is validated, and where it is not allowed to influence remediation priority without corroboration. That governance line is what keeps AI assistance from becoming AI overreach.

For practitioners

• Define scope before model invocation Use function-level or hotspot-level prompts for vulnerability discovery, and reserve whole-file prompting for broad triage only when you can tolerate lower precision.
• Pair LLMs with deterministic pre-filtering Use code search, static rules, or pattern filters to identify suspicious regions before asking a model to assess exploitability or root cause.
• Set validation thresholds for AI findings Require human verification, repeatability checks, and a documented false-positive tolerance before an LLM finding enters the remediation workflow.
• Measure performance on precision and consistency Track how often the model identifies the correct function, the correct preconditions, and the correct primary finding across repeated runs.

Key takeaways

• Whole-file LLM vulnerability discovery still underperforms because the model is being asked to infer too much from too much context at once.
• Narrowing the task to a function or hotspot improves results, but false positives and misses still prevent autonomous use.
• Security teams should govern AI-assisted code review as a scoped triage aid with deterministic pre-filtering and human validation.

Key terms

• Whole-file vulnerability discovery: A review approach that asks a tool to find security flaws across an entire source file at once. It is harder than verification because the system must identify the relevant code, infer the bug mechanism, and filter out distracting context without losing precision.
• Hotspot pre-filtering: A control pattern that narrows review to code regions already flagged by other signals, such as static rules, search results, or prior triage. It reduces noise before model analysis and improves the chance that LLM output stays focused on plausible exploit paths.
• False Positive Rate: False positive rate is the share of alerts, detections, or test results that incorrectly indicate a problem when none exists. In security and identity operations, it measures how often a control flags benign activity as suspicious, usually expressed as a percentage of all negative cases. Lower rates reduce analyst noise and wasted response effort.
• Exploit Validation: The process of proving that a suspected vulnerability is actually exploitable by producing a working proof of concept. This is a high-value security task because it separates real exposure from noise and can be automated with sufficient model and workflow support.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build control-aware programmes that can handle automation, privilege, and validation risk.