Topic starter
02/08/2026 11:35 am
TL;DR: Application-layer weaknesses still account for 82% of known vulnerabilities, while OXSecurity’s analysis of 101+ million findings across 178 organisations shows that only 2 to 5% are truly high risk, leaving legacy scanners to bury actionable issues under noise. Reachability, exploitability and source-to-runtime context now matter more than severity alone.
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: 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.
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.
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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
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