Topic starter
02/08/2026 11:58 am
TL;DR: AI-assisted static code review can surface vulnerabilities faster, but it still misses how real attackers chain misconfigurations, integrations, and runtime behaviour in live systems, according to Novee. The security gap is no longer finding flaws in repositories, but proving exploitability against working environments before attackers do.
Editorial analysis by NHI Mgmt Group, based on content published by Novee: “AI Can Find Bugs. But Can It Prove You’re Actually Secure?”.
By the numbers:
- Novee's model reached 90% accuracy on constrained web exploitation challenges validated in a live browser.
- Novee's AI agent uncovered 16 new zero-day vulnerabilities in two widely used PDF engines.
Key questions
Q: Why is static AI code scanning not enough to prove application security?
A: Static scanning finds candidate flaws in code, but it cannot show whether those flaws are reachable, chainable, or exploitable in a working environment.
Q: Should teams prioritise runtime controls over more vulnerability scanning?
A: Teams should not choose one at the expense of the other, but runtime controls deserve priority when exploitation speed outpaces human response.
Q: What breaks when security teams rely only on static findings instead of exploit proof?
A: When teams stop at static findings, they usually overcount risk, under-prioritise real exposure, and create backlogs that developers cannot act on efficiently.
Practitioner guidance
- Validate exploitability against live systems Run black-box or grey-box testing against production-like environments to confirm whether high-risk findings can actually be chained into compromise.
- Prioritise runtime validation for business-logic paths Focus testing on authentication flows, feature flags, state transitions, and API sequences where static scanning is least reliable.
- Treat identity context as part of the attack surface Test whether delegated access, service credentials, and integration trust can be abused once the application is executing with real permissions.
Bottom line: Static AI scanning improves discovery, but it does not prove whether a weakness can be exploited in a running environment.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:05 pm
Runtime exploitability is the control gap that static AI scanning cannot close. Static review is useful for finding candidate weaknesses, but it does not prove whether an attacker can actually chain them in a live environment. The governance failure is assuming repository visibility equals production assurance. Security teams should treat exploitability validation as a distinct control stage, not a nicer form of code review.
A few things that frame the scale:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How should IAM and security teams test live trust relationships in applications?
A: They should validate the full trust chain, including service credentials, delegated permissions, integration boundaries, and authentication flows. That approach shows whether identity and authorisation decisions hold up under active probing, which is where many modern application compromises actually occur.
👉 Read our full editorial: AI code scanning is not enough without runtime attack validation