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.
Editorial analysis by NHI Mgmt Group, based on content published by ArmorCode: “The Reality Shift in Vulnerability Management”.
By the numbers:
- In 2021, roughly 55 CVEs were published per day, rising to around 130 per day by 2025.
- VulnCheck reports that 884 vulnerabilities had first-time exploitation evidence in 2025.
- VulnCheck says 28.96% of Known Exploited Vulnerabilities were exploited on or before CVE publication.
Key questions
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: What do security teams get wrong about vulnerability backlogs?
A: They often treat the backlog as a queue of work rather than a warehouse of unresolved risk.
Practitioner guidance
- Prioritise by exploitability and asset context Rank findings using reachability, exposure, asset criticality, and active exploitation signals before assigning engineering time.
- Track remediation throughput as a board-level metric Measure time to triage, time to fix, and time to verified closure so backlog growth is visible as an operational risk.
- Unify CVE and pre-CVE supply-chain handling Route malicious-package alerts and ordinary vulnerability findings through one remediation workflow so non-CVE events do not fall through separate tools.
Bottom line: Discovery is no longer the scarce resource in vulnerability management, because remediation capacity is now the constraint that determines whether risk is reduced or simply catalogued.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:26 pm
Remediation throughput is now the limiting security control: discovery can scale with automation, but ownership, testing, and verified closure still depend on human and workflow capacity. That creates a structural bottleneck that no amount of additional scanning will fix on its own. Security leaders should treat closure velocity as a governed operational metric, not a by-product of vulnerability management.
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 handle non-CVE supply-chain threats alongside ordinary vulnerabilities?
A: They should route both into one governed remediation process. Malicious packages, trojanised releases, and pre-CVE alerts can create the same operational risk as known vulnerabilities, but they are missed when teams separate scanner output from threat-intelligence handling. Unified inventory and closure tracking reduce that blind spot.
👉 Read our full editorial: Vulnerability remediation is becoming the security bottleneck