Topic starter
02/08/2026 12:19 pm
TL;DR: AI-based code review can flag weaknesses with high confidence but still miss whether an issue is actually exploitable, as Semgrep illustrates with a Host header injection finding that did not survive real-world OAuth and proxy constraints. The operational risk is not the alert itself, but the lack of policy context that separates weakness from reachability and keeps security backlogs credible.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “Through a Scanner Falsely: When AI-reported Critical Vulnerabilities Aren’t”.
Key questions
A: Treat the finding as a hypothesis, not a ticket.
Q: Why do code review tools confuse vulnerable code with real security risk?
A: Because pattern matching sees a suspicious data flow, while exploitability depends on the whole environment.
Q: How should security teams reduce false positives in AI vulnerability scanning?
A: Require scanners to prove reachability, exposure, and privilege context before findings are allowed to block delivery.
Practitioner guidance
- Define exploitability before triage Write review rules that require reachability, trust boundary crossing, and compensating control checks before a finding becomes a ticket.
- Tune policies to deployment reality Align AI review thresholds with proxy behaviour, header normalization, browser constraints, and accepted redirect controls.
- Separate weakness from backlog-worthy risk Use a severity model that distinguishes theoretical code weaknesses from issues that can survive the actual request path.
Bottom line: AI code review becomes noisy when it flags weaknesses without validating whether an attacker can actually reach them.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:20 pm
Exploitability is the real governance boundary, not vulnerability detection. AI code review can surface plausible weaknesses quickly, but security programmes fail when they treat every flagged pattern as equally actionable. The difference between a theoretical flaw and a reachable attack path must be encoded in policy, or teams will drown in noise. For appsec and IAM-adjacent flows, the control question is whether the issue can actually be used to cross an authentication or redirect boundary.
A question worth separating out:
Q: When should a host header finding be treated as a real risk?
A: Only when the application uses that value in a way that survives the surrounding stack and can influence a security-sensitive decision such as authentication, redirection, or token handling. If proxies, browsers, or server rules block the attack path, the issue may still be a weakness but not a practical exposure.
👉 Read our full editorial: AI code review needs exploit context, not just vulnerability flags