Notifications
Clear all
Topic starter
01/08/2026 9:01 pm
TL;DR: Code scanners and AI review tools can spot bugs in source files, but they cannot determine whether a finding is exploitable in a given deployment because the trust model, architecture, and runtime context live outside the code, according to Gecko Security. That gap turns AI-driven code volume into a triage problem, not a risk-reduction breakthrough.
NHIMG editorial — based on content published by Gecko Security: analysis of Claude Code Review, Claude Code Security, and exploitability context
By the numbers:
- Code output per developer jumped 200 percent while security review capacity stayed flat.
Questions worth separating out
Q: What breaks when code scanners cannot see deployment context?
A: They can still find code defects, but they cannot tell whether those defects are reachable in the live system.
Q: Why do large codebases make AI-assisted security review harder?
A: Large repositories create context loss.
Q: How do security teams know if a code finding is actually dangerous?
A: They need to check exposure, trust boundaries, and compensating controls before assigning priority.
Practitioner guidance
- Integrate deployment context into code review Require reviewers to validate exposure, segmentation, and compensating controls before accepting a scanner finding as actionable.
- Rank findings by exploitability, not just detection Create a triage workflow that separates theoretical defects from reachable attack paths.
- Align IAM and application security review Make identity teams part of reviews for endpoints, service calls, and privileged workflows that could turn a code defect into an access control failure.
What's in the full article
Gecko Security's full article covers the operational detail this post intentionally leaves for the source:
- The comparison between Claude Code Review and Claude Code Security across PR review and standalone scanning workflows.
- The full breakdown of the five-agent review architecture and how the 80-point confidence threshold affects output.
- The specific examples Gecko uses to show where code-only scanners miss exploitability in deployment context.
- The article's practical notes on installing the review plugins and using them in a live development workflow.
👉 Read Gecko Security's analysis of why code-only scanners miss exploitability context →
Code-only vulnerability scanning: why exploitable risk is still slipping through?
Explore further
01/08/2026 9:07 pm
Code-only analysis creates a context gap that security teams now have to govern explicitly. The article’s core point is not that scanners are useless, but that their verdicts stop at the source file. That leaves architecture, deployment, and trust boundaries outside the control loop. For identity programmes, this is the same failure mode seen when entitlement reviews ignore where access is actually reachable. Practitioners should treat exploitability as a governed decision, not a static code property.
A question worth separating out:
Q: How should IAM teams think about application code review?
A: IAM teams should treat code review as one input into access-risk assessment, not the final decision. The important question is whether the affected function is reachable by a human user, service account, or delegated workload, and under what trust conditions. That is where identity governance and application security meet.
👉 Read our full editorial: AI code review is missing the context that determines exploitability
