Topic starter
18/08/2026 2:12 pm
TL;DR: Application security programs now face 48,185 new CVEs in a single year and, per ArmorCode, remediation still depends on consolidating scanner noise, ranking findings by real exposure, and automating handoff. CVSS alone cannot separate theoretical severity from exploitable risk, so vulnerability management has become a context and workflow problem, not a scanning problem.
Editorial analysis by NHI Mgmt Group, based on content published by ArmorCode: “Application Security Vulnerabilities: Testing, Detection, and Remediation at Scale”.
By the numbers:
- Only 2-7% of published vulnerabilities are ever observed being exploited in the wild.
- CISA’s Known Exploited Vulnerabilities catalog covers only about 0.5% of all CVEs.
Key questions
Q: What breaks when application vulnerability teams rely on scanner output alone?
A: Teams end up with duplicate tickets, inconsistent severity labels, and no reliable way to separate theoretical flaws from exploitable risk.
Q: Why should teams use reachability instead of raw CVSS alone?
A: Raw CVSS measures theoretical severity, not whether the vulnerable code can actually be invoked in your application.
Q: What are the signs that vulnerability triage is becoming a security bottleneck?
A: Common signs include engineers spending most of their week validating noisy submissions, a backlog of unreviewed reports, frequent duplicate closures, and slow handling of truly critical findings.
Practitioner guidance
- Consolidate duplicate findings into one remediation queue Map SAST, DAST, SCA, API, and cloud findings into a single backlog so one flaw is not managed as multiple tickets with conflicting severities.
- Weight vulnerabilities by reachability and exposure Add runtime evidence, asset criticality, and compensating controls to the ranking model so internet-facing and actually callable paths rise above theoretical severity.
- Route fixes with owner and code context attached Push deduped findings into engineering workflows with the affected file, component, service owner, and exploit context already included.
Bottom line: Application vulnerability programmes break down when scanner output grows faster than teams can reconcile and fix it.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:04 pm
Scanner proliferation has become a governance problem, not a tooling problem. The central failure is not the absence of findings but the absence of a decision layer that can reconcile them. When SAST, DAST, SCA, and cloud controls all generate separate queues, the programme loses its ability to express business risk in operational terms. Practitioners should treat deduplication and contextual scoring as core governance functions, not administrative cleanup.
A few things that frame the scale:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How should teams govern application vulnerability response across security and engineering?
A: They need a shared operating model that combines deduplication, contextual scoring, and automated routing. Security should decide what matters using exposure and business context, while engineering should receive one clear issue per flaw with enough detail to act without manual translation.
👉 Read our full editorial: Application vulnerability prioritisation fails when scanners outpace fixes