Topic starter
18/08/2026 2:21 pm
TL;DR: CVSS-only triage leaves AppSec teams chasing volume instead of exploitable risk, as more than 48,000 CVEs were published in 2025 and roughly 3% of vulnerabilities account for 80% of exploitation activity, according to ArmorCode. The practical shift is toward exposure management, where reachability, business context, and automated routing decide what gets fixed first.
Editorial analysis by NHI Mgmt Group, based on content published by ArmorCode: “Managing Application Security Vulnerabilities: Moving Beyond the CVE Backlog”.
By the numbers:
- Roughly 3% of vulnerabilities account for 80% of actual exploitation activity, according to ArmorCode research cited by ArmorCode.
Key questions
Q: Why does CVSS-only triage fail for application security teams?
A: CVSS-only triage fails because it measures theoretical severity, not whether a weakness is reachable, exposed, or tied to sensitive business functions.
Q: What should teams do when security findings overwhelm developers?
A: Move remediation into the developer workflow and reduce the number of manual handoffs.
Q: How do you know if an application vulnerability is actually risky?
A: A vulnerability is risky when it is reachable from a real execution path, exposed on a meaningful asset, and able to affect important data or business functions.
Practitioner guidance
- Unify scanner output into one remediation queue Correlate SAST, DAST, SCA, API, and cloud findings into a single inventory so duplicate issues do not create false urgency or hide true exposure.
- Add reachability to prioritisation rules Score findings by whether the vulnerable code path is actually executed, especially for dependency CVEs that appear across many repositories but are never called.
- Weight business context before assigning SLAs Use asset criticality, data sensitivity, and internet exposure to decide whether a finding belongs in the fast lane or the standard queue.
Bottom line: Application security programmes break down when they treat every scanner finding as equally urgent, because volume quickly overwhelms manual triage.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:13 pm
Exposure management is now the only defensible AppSec governance model at scale. CVSS-only triage assumes severity is enough to decide remediation order, but modern application estates are too noisy, too interconnected, and too dynamic for that assumption to hold. The governance question has shifted from finding vulnerabilities to proving which ones are actually exploitable in context. Practitioners should treat exposure management as the operating model, not an optional enhancement.
A question worth separating out:
A: Security teams should define the policy and acceptance criteria, while engineering teams own implementation and verification inside the codebase. The IDE plugin can accelerate remediation, but accountability still sits with the people approving code changes and the teams governing secure development standards. Clear ownership prevents automation from obscuring risk decisions.
👉 Read our full editorial: Beyond the CVE backlog: why AppSec needs exposure management