Topic starter
02/08/2026 11:58 am
TL;DR: Static AI scanning finds vulnerabilities faster, Novee says, but it still cannot prove whether a weakness is exploitable in a running environment. Runtime validation is what turns business logic, identity context, and integrations into evidence for real risk decisions.
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: 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.
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.
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.
Glossary terms: Runtime Attack Validation, Exploitability context, Stateful Attack Path, Business Logic Flaw
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
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