The main sign is a backlog of plausible findings that never map cleanly to real requests, real responses, or confirmed attack paths. If authentication, access control, and business logic issues are repeatedly uncertain after review, the programme is over-trusting source analysis and under-testing runtime behaviour.
When review catches issues but not exploitability
Code review is missing real exploitability when it can describe weakness but cannot connect that weakness to a concrete request, response, state transition, or attack path. Findings stay theoretical when reviewers debate whether something “looks bad” instead of showing how an attacker would trigger it in the running system. In that state, review is producing hypotheses, not security evidence.
A practical warning sign is that the same class of issue keeps reappearing with no closure because the team never verifies the runtime conditions that make it exploitable. Authentication, authorization, and business logic mistakes are especially likely to be overcalled or undercalled if the review process does not check how the application actually behaves under malformed input, replay, race, or privilege changes.
Another sign is that the review output is rich in source-level commentary but poor in exploit chain detail. If the team cannot show the exact parameter, object, session, or state boundary that would be abused, the review is probably optimized for code aesthetics rather than security impact. That usually means the process is not testing whether the weakness survives normal validation, routing, session handling, or downstream enforcement.
Why the backlog of findings does not become a backlog of risk
A backlog filled with plausible findings is not the same as a backlog of exploitable issues. The signal to watch is whether findings can be turned into reproducible abuse cases with a clear before-and-after state. If they cannot, the review function may be overfitting to static patterns, framework warnings, or checklist language instead of checking whether an attacker can actually influence system behaviour.
This matters most where the code path depends on trust assumptions that only runtime can confirm. Access control bugs, object reference mistakes, and logic flaws often look obvious in the diff but only become real when paired with the right account state, session state, workflow order, or alternate client request. A review process that never validates those conditions will accumulate noise and miss the cases that matter.
For a broader view of how exploitability is distinguished from vulnerability appearance, teams often cross-check weak findings against NIST National Vulnerability Database records, FIRST EPSS prioritisation, and the CISA Known Exploited Vulnerabilities Catalog when deciding whether a pattern has a credible exploitation track record.
What to look for instead of source-level confidence
The most reliable sign of missing exploitability is when reviewers cannot answer three questions together: what request changes the state, what response proves the state changed, and what attack path follows from that change. If any one of those is missing, the review has not yet reached security-grade certainty. You want evidence of behaviour, not just evidence of suspicious code.
Exploitability also becomes harder to assess when review findings do not map to observable runtime checks. If the control is supposed to be enforced by the server, the review should validate server-side enforcement rather than trusting UI logic, client code, or implied invariants. If the finding is about authentication or privilege boundaries, the team should be able to describe the exact boundary that fails and the conditions under which it fails.
Threat-intel and prioritisation sources such as CISA KEV and EPSS are useful here because they force the question from “is it plausible?” to “has it been exploited, or is it likely to be exploitable in practice?”
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | Exploitability assessment depends on validating whether findings are actionable in practice. |
| SI-2 — Flaw Remediation | Repeated review findings should drive remediation only when they are confirmed and material. | |
| Recommendation — Validate findings with runtime checks and exploitability evidence before treating them as confirmed risk. Prioritise confirmed exploitable flaws for remediation and keep unvalidated findings in triage. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | The question hinges on whether a code issue can become a real attack path. |
| Recommendation — Map review findings to likely attack paths and test whether they enable exploitable application abuse. | ||
| OWASP ASVS | V8 — Authorization | Exploitability often depends on whether access control fails at runtime, not in static review. |
| Recommendation — Verify authorization decisions with live requests and ownership checks, not source inspection alone. | ||
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Object reference and authorization issues are classic cases where review must confirm real abuse paths. |
| Recommendation — Test whether object access can be abused across accounts or roles before accepting a finding as exploitable. | ||
Practitioner Guidance
What to verify: Treat a review finding as incomplete until someone can reproduce the issue with a request, a response, and a state change that survives normal application checks. If the only evidence is a code snippet or a static pattern match, keep the finding open but do not score it as confirmed exploitability.
Decision rule: If a finding cannot be linked to a concrete attack path after a small amount of validation, downgrade it to “needs runtime test” rather than “confirmed vulnerability.” That keeps the queue honest and prevents static noise from crowding out issues with actual abuse potential.
What practitioners underestimate: Authentication and access-control bugs are often misjudged because the exploit hinges on context the source review cannot fully see, such as session state, object ownership, or workflow order. The review process is strongest when it forces those hidden assumptions into explicit test cases.
Practitioner takeaway: Real exploitability is proven when source concerns survive a runtime challenge, not when they merely sound concerning in review.
Related resources from NHI Mgmt Group
- What are the signs that a rule-based security scan is missing real issues in application code?
- What are the signs that a code security programme is missing real-world vulnerability patterns?
- What are the signs that a non-empty statement is failing to do real work in a code review?
- What are the signs that AI code review is being used as a substitute for real verification?