Notifications
Clear all
Topic starter
19/08/2026 3:50 pm
TL;DR: Vulnerability discovery is scaling faster than remediation, with public CVE volume rising from roughly 55 per day in 2021 to about 130 per day in 2025, while exploit pressure and enrichment gaps continue to outpace programme capacity, according to ArmorCode. The real constraint is no longer finding issues but turning noisy findings into owned, contextualised, verified fixes, and that changes how teams should prioritise, automate, and govern remediation.
NHIMG editorial — based on content published by ArmorCode: The Reality Shift in Vulnerability Management
By the numbers:
- In 2025, CVE Program yearly totals rose to 48,244, up from 20,161 in 2021.
- NIST says submissions during the first three months of 2026 were nearly one-third higher than the same period last year.
- VulnCheck reports that 884 vulnerabilities had first-time exploitation evidence in 2025.
Questions worth separating out
Q: What breaks when vulnerability discovery outpaces remediation capacity?
A: When discovery moves faster than validation and patching, the backlog becomes the control failure.
Q: Why do severity scores often mislead remediation priorities?
A: Severity scores describe theoretical impact in isolation, not the value of the affected asset or the control environment around it.
Q: How do security teams know whether Teams remediation is working?
A: They should measure dwell time, removal latency, and the percentage of malicious messages removed before any user interaction.
Practitioner guidance
- Enrich every finding before triage Add exploitability, reachability, asset criticality, and owner context before a ticket enters the remediation queue.
- Separate discovery volume from remediation throughput Track how many issues are found, assigned, accepted, fixed, and verified closed as distinct metrics.
- Use runtime controls for slow-fix assets Where patching is delayed by release risk or operational dependency, apply runtime protection, isolation, or selective blocking so exposure does not stay unbounded while the fix is being prepared.
What's in the full article
ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:
- The article's step-by-step remediation workflow for moving findings from triage into verified closure.
- The specific use of risk context, reachability, and enrichment signals to order backlog items.
- The detailed example sequence for gates, prioritisation, and runtime decision points.
- The operational framing for how AI-assisted remediation fits into engineering workflows.
👉 Read ArmorCode's analysis of why vulnerability remediation is becoming the bottleneck →
Vulnerability remediation backlog: what security teams need to change?
Explore further
19/08/2026 4:26 pm
Vulnerability management has become an operational throughput problem, not a discovery problem. The article is correct to frame remediation as the dominant constraint because modern tooling can surface more issues than organisations can review, assign, and fix. That means programme health is now governed by backlog flow, ownership clarity, and closure verification. Teams that still measure success mainly by findings discovered are measuring the wrong part of the pipeline.
A question worth separating out:
Q: Who is accountable when exposure remains open after a vulnerability is disclosed?
A: Accountability should sit with the asset or service owner, but only if ownership records are current and tied to privileged access paths. In practice, that means IAM, infrastructure and security teams need a shared operating model for assigning remediation, approving exceptions and proving closure. Otherwise, gaps linger because no one can act decisively.
👉 Read our full editorial: Vulnerability remediation is becoming the security bottleneck
