Notifications
Clear all
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.
NHIMG editorial — based on content published by Semgrep: AI code review false positives and exploitability context
Questions worth separating out
Q: How should security teams decide whether an identity-related code finding is actually exploitable?
A: Treat exploitability as a validation step, not a label assigned by the scanner.
Q: Why do AI code reviewers create so many false positives in authentication and redirect logic?
A: They are strong at pattern recognition but weak at environment reasoning.
Q: What do security teams get wrong about vulnerabilities that are not reachable?
A: They often treat a theoretical weakness as a production risk without checking whether the attacker can actually drive the input through the live system.
Practitioner guidance
- Define exploitability thresholds for identity-adjacent findings Require every OAuth, redirect, and host validation finding to include the exact conditions under which it becomes reachable, including proxy behaviour and allowed host handling.
- Add deployment context to review policies Teach AI reviewers and SAST rules about reverse proxies, load balancers, browser constraints, and trusted host allowlists so they can distinguish theoretical weakness from environment-specific exposure.
- Triage identity flow findings with engineering and IAM jointly Review callback, redirect, and session-related issues with both application security and identity stakeholders present.
What's in the full article
Semgrep's full article covers the operational detail this post intentionally leaves for the source:
- How the AI reviewer reasoned through the Host header injection pattern and where its conclusion broke down.
- Why OAuth redirect handling, reverse proxies, and browser constraints changed the real exploitability outcome.
- The practical tuning approach for custom rules and policies that reduce critical false positives.
- How Semgrep positions inline remediation and policy iteration for teams using AI-assisted review.
👉 Read Semgrep's analysis of AI code review false positives and exploitability context →
AI code review false positives: where does the governance gap sit?
Explore further
02/08/2026 1:20 pm
Context collapse is the core failure mode here. The finding looked severe because it matched a known vulnerability pattern, but the surrounding controls made the exploit chain non-viable. That is a governance problem, not just a tooling quirk, because review systems that cannot model runtime constraints will repeatedly surface non-actionable risk. For IAM and software teams, the lesson is to treat environmental trust assumptions as part of the control, not as afterthoughts.
A question worth separating out:
Q: How can organisations reduce false-positive fatigue in AI-assisted security review?
A: Use explicit policy gates for exploitability, route low-confidence findings out of critical queues, and require human review for identity-sensitive flows such as OAuth callbacks and host validation. The goal is not fewer findings overall, but fewer findings that waste engineering time without changing security exposure.
👉 Read our full editorial: AI code review needs exploit context, not just vulnerability flags
