As reported by Dark Reading, large language models are increasingly being deployed in application security workflows to help identify and prioritize vulnerabilities — but the results are falling well short of the hype, with elevated false-positive rates and a fundamental inability to reason about environmental context.
This is a story Shield53 has been watching closely, because the gap between AI marketing and AI reality in security tooling has real operational consequences. When AppSec teams adopt LLM-assisted scanning without understanding its limitations, they often end up increasing their workload rather than reducing it — precisely the opposite of the intended outcome.
The Core Problem: LLMs Don't Know Your Environment
Vulnerability prioritization isn't just a pattern-matching exercise. Effective triage requires deep contextual knowledge: What data does this application handle? Is the vulnerable component internet-facing? What compensating controls exist upstream? Does your threat model actually include the attack vector this CVE exploits?
LLMs, by their very architecture, are trained on generalized corpora. They can identify that a code pattern resembles a known vulnerability class, but they have no reliable mechanism for understanding whether that vulnerability is exploitable in your specific deployment context. The result is a flood of findings that are technically accurate in isolation but operationally irrelevant — the classic false-positive problem at scale.
A security tool that generates noise faster than humans can process it doesn't improve your security posture. It degrades it by consuming analyst bandwidth that should be spent on validated, high-priority findings.
Who Bears the Burden?
The impact falls disproportionately on mid-sized organizations and teams already operating lean. Enterprise firms with dedicated AppSec engineering functions can absorb false-positive volume — they have the staffing to build suppression rules, tuning pipelines, and validation workflows. Smaller teams cannot. For them, an LLM-assisted scanner that produces hundreds of uncontextualized findings per sprint is actively harmful to delivery velocity and team morale.
It's also worth noting the risk of alert fatigue normalization. When analysts are conditioned to dismiss large volumes of findings as noise, they become statistically more likely to dismiss genuine positives — a dangerous behavioral pattern that undermines the entire purpose of automated scanning.
Broader Implications for the AppSec Tooling Market
We're in an inflection point where vendors are racing to attach "AI-powered" labels to existing scanning products with LLM layers bolted on top. This isn't necessarily malicious — it reflects genuine experimentation — but buyers need to apply rigorous evaluation criteria before procurement. The key questions are not "does this use AI?" but rather:
Where LLMs Actually Add Value in AppSec
To be fair, dismissing LLMs entirely from security workflows would be an overcorrection. There are legitimate, well-bounded use cases where they perform well: generating natural language explanations of complex vulnerability findings for developer audiences, drafting remediation guidance from known CVE descriptions, and summarizing scan reports for executive communication. These are augmentation tasks, not autonomous decision-making tasks — and that distinction matters enormously.
The mistake is positioning LLMs as autonomous vulnerability analysts rather than as productivity multipliers for human analysts.
Shield53 Recommendations
For AppSec Teams Evaluating or Using LLM-Assisted Tools
- Demand a proof-of-concept in your environment before procurement — vendor demo environments are curated to minimize false positives.
- Instrument your false-positive rate from day one. Track dismissed findings by tool, finding type, and analyst. This data is essential for tuning and vendor accountability.
- Feed context into the tool, not just code. If the scanner supports asset metadata, SBOM integration, or network segmentation data, invest time in configuring these inputs. Context-free scanning is where false-positive rates spike.
- Build a human-in-the-loop validation gate before any LLM-generated finding reaches a developer ticket. Sending unvalidated AI findings to engineering teams destroys trust in the security program.
- Use LLMs downstream, not upstream. Let traditional SAST/DAST/SCA tools do detection; use LLMs to explain, prioritize narratively, and draft remediation guidance.
- Establish a feedback mechanism where analyst verdicts (valid/invalid) are logged and periodically reviewed with the vendor to improve model tuning.
For CISOs and Security Leaders
- Resist pressure to adopt AI-assisted scanning as a headcount-reduction strategy before the tools have matured sufficiently to operate with acceptable accuracy.
- Include false-positive rate SLAs in vendor contracts for any AI-driven scanning tool.
- Invest in your team's ability to evaluate AI tooling critically — this is now a core AppSec competency.
The promise of AI in application security is real, but it will be realized through disciplined integration, not uncritical adoption. The teams that emerge ahead will be those that treat LLMs as a force multiplier for skilled analysts — not a replacement for them.
