Topic starter
02/08/2026 11:35 am
TL;DR: 82% of known vulnerabilities sit in the application layer, and only 2 to 5% of 101+ million findings were truly high risk in OXSecurity’s analysis of 178 organisations. AppSec teams need reachability, exploitability and provenance to keep low-value scanner output from crowding out issues that matter.
Editorial analysis by NHI Mgmt Group, based on content published by OXSecurity: “Top 10 Application Security Testing Tools (2026 Edition)”.
By the numbers:
- 82% of known vulnerabilities originate in the application layer, according to OXSecurity.
- OXSecurity analysed 101+ million findings across 178 organisations.
- Only 2 to 5% of alerts were truly high-risk, according to OXSecurity.
Key questions
Q: Why do application-layer flaws create more practical risk than infrastructure-only scans suggest?
A: Application-layer flaws often sit closer to authentication logic, session handling, business flows and secrets use, which means they can turn directly into account abuse or sensitive data exposure.
Q: What are the signs that an AppSec program is struggling to separate real risk from noise?
A: Common warning signs include too many findings scattered across disconnected tools, slow triage, and developers being overwhelmed by alerts that are not clearly prioritized.
Q: What breaks when AppSec teams rely on severity scores without identity context?
A: Severity scores break down when they are used without ownership, reachability, and delivery context.
Practitioner guidance
- Prioritise application-layer findings by reachability Classify issues by whether the vulnerable path is actually reachable in the deployed environment, then triage only those findings that can be exercised by a realistic attacker.
- Correlate findings with exploitability and business impact Add exploit preconditions, affected assets and likely blast radius to the triage workflow so severity alone does not drive remediation order.
- Tie every production finding back to source provenance Require file, commit, dependency and pipeline-stage attribution for each issue so the owner and fix point are unambiguous.
Bottom line: Application-layer weaknesses create more practical exposure than infrastructure-first strategies assume, because the business logic that attackers actually exploit lives there.
Glossary terms: Reachability analysis, Exploitability context, Code-to-runtime traceability, Application Security Testing Service
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 12:49 pm
Application-layer risk is now the control problem, not a side effect of infrastructure weakness. The article’s core finding is that most known vulnerabilities originate in application code, which means perimeter and cloud-first controls will always miss part of the real exposure picture. For identity programmes, that shifts attention toward session handling, token logic and delegated access paths that live inside the application itself. Practitioners should treat application-layer governance as a primary security domain, not a downstream hygiene task.
A question worth separating out:
Q: How should teams respond when application findings cannot be traced to the code that caused them?
A: They should treat that as a governance failure, not a reporting inconvenience. If a production issue cannot be tied to the file, commit, dependency or pipeline stage that introduced it, teams cannot assign accountability or prevent recurrence. Provenance and pipeline metadata are essential for moving from detection to remediation.
👉 Read our full editorial: Application layer risk outpaces infrastructure-first AppSec strategies