Notifications
Clear all
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.
NHIMG editorial — based on content published by ArmorCode: Application Security Vulnerabilities: Testing, Detection, and Remediation at Scale
By the numbers:
- The 2025 numbers make the imbalance concrete: 48,185 new CVEs were published, a 20.6 percent rise over 2024's record of roughly 40,000.
- ArmorCode says its Context Risk Graph surfaces the 3% of findings that carry roughly 80% of real business risk.
- Only 2-7% of published vulnerabilities are ever observed being exploited in the wild.
Questions worth separating out
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 do lower-severity findings sometimes deserve higher priority than critical ones?
A: Because exploitability depends on context.
Q: What do security teams get wrong about vulnerability remediation automation?
A: They often automate ticket creation but not end-to-end closure.
Practitioner guidance
- Collapse scanner output into one governed backlog Deduplicate SAST, DAST, SCA, secrets, CSPM, and API findings so the same weakness is not tracked as three separate tickets across three teams.
- Prioritise by reachability and asset context Score findings by internet exposure, callable code path, affected data sensitivity, and compensating controls before assigning engineer time.
- Treat identity controls as appsec inputs Review over-broad IAM permissions, exposed service credentials, and unauthenticated endpoints as part of application vulnerability triage, not as a separate cleanup stream.
What's in the full article
ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:
- The article's specific examples of how its Context Risk Graph correlates scanner findings with runtime and asset data.
- The workflow details behind scanner-agnostic ingestion, deduplication, and rules-driven ticket routing.
- The article's explanation of how agentic AI supports remediation workflows and role-aware task execution.
- The practical examples of prioritisation using EPSS, CISA KEV, and reachability signals.
👉 Read ArmorCode's analysis of application vulnerability testing, prioritisation, and remediation →
Application vulnerability backlogs: what teams should prioritise first?
Explore further
18/08/2026 3:04 pm
Scanner sprawl is becoming a governance problem, not a visibility problem. The article shows that modern programmes already know where many flaws are, but cannot convert that knowledge into remediation flow. When five to fifteen tools each create their own backlog, identity and application teams inherit the same issue under different labels. The practical conclusion is that control ownership must move above the scanner layer, with one prioritised queue for the whole estate.
A question worth separating out:
Q: How should security teams automate vulnerability triage without losing governance control?
A: Start by automating enrichment, deduplication, and ownership mapping, then keep humans for ambiguous exceptions and business trade-offs. The goal is not full autonomy, but reducing repetitive decisions so analysts can focus on findings that need interpretation, escalation, or compensating-control review.
👉 Read our full editorial: Application vulnerability prioritisation fails when scanners outpace fixes
