Topic starter
20/08/2026 5:52 pm
TL;DR: Modern application vulnerability scanning is being reshaped by 40,009 new CVEs since 2024, a 38% year-on-year increase, alongside AI-generated code that has become a major blind spot for AppSec teams, according to Cycode. The practical shift is from counting findings to proving exploitability, correlating code-to-runtime context, and reducing remediation drag before attackers exploit the gap.
Editorial analysis by NHI Mgmt Group, based on content published by Cycode: “Application Vulnerability Scanning: Tools and Guide”.
By the numbers:
- around 108 new vulnerabilities have been revealed every day.
- security teams are wasting 30%-40% of their time triaging false positives rather than actually remediating real risks.
- the average Mean Time to Remediation for high and critical application vulnerabilities now sits at 74.3 days.
Key questions
Q: What breaks when scanner findings are not tied to exploitability?
A: Teams end up treating theoretical issues as equal to production issues, which distorts prioritisation and inflates backlogs.
Q: Why do AI-generated code changes increase application security risk?
A: AI-generated code can increase risk because it accelerates output faster than review, testing, and secret hygiene can keep up.
Q: How should security teams reduce false positives in AI vulnerability scanning?
A: Require scanners to prove reachability, exposure, and privilege context before findings are allowed to block delivery.
Practitioner guidance
- Prioritise findings by exploitability, not count Require each high-severity finding to show reachability, runtime exposure, and business impact before it enters the urgent remediation queue.
- Correlate code and runtime evidence Join SAST, SCA, secrets, IaC, and runtime telemetry so teams can see whether a weakness is active in the deployed environment.
- Add AI-generated code to the highest scrutiny lane Tag assistant-produced changes so security review can validate dependency choices, authentication logic, and exposed interfaces more aggressively.
Bottom line: Application vulnerability scanning is becoming a prioritisation discipline because teams now need to prove which findings are actually exploitable.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:31 pm
Exploitability context is becoming the deciding control in application security: counting vulnerabilities no longer tells leaders what to fix first. When CVE volume rises and development speed increases, the control failure is not lack of visibility but lack of reachability testing. Practitioners should treat exploitability as the governance filter that separates static inventory from actionable risk.
A question worth separating out:
A: Start with exposure validation, not enumeration. CVE counts alone do not tell you whether a flaw is reachable, exploitable in your environment, or likely to be used by attackers. Prioritise assets that are internet-facing, business critical, or linked to known exploit activity, then verify whether the issue can actually be abused before spending remediation effort.
👉 Read our full editorial: Application vulnerability scanning now depends on exploitability context