Notifications
Clear all
Topic starter
02/09/2026 1:29 pm
TL;DR: More than 48,000 CVEs were published in 2025 and only 26% of known-exploited vulnerabilities were fully remediated, according to ArmorCode’s analysis of CVE.org and the Verizon 2026 Data Breach Investigations Report. The practical shift is from severity-first queues to context-driven exposure management, where exploitability, asset criticality, reachability, and business impact determine what gets fixed first.
NHIMG editorial — based on content published by ArmorCode: Drowning in Security Findings? A Guide for Vulnerability Prioritization
By the numbers:
- Among known-exploited vulnerabilities, organisations take a median of 43 days to remediate and only 26 percent are fully remediated.
Questions worth separating out
Q: What should security teams do first when every vulnerability is marked critical?
A: Start with exploitability and exposure, not score bands.
Q: When does CVSS scoring fail to reflect actual vulnerability risk?
A: CVSS can understate or overstate risk when the affected asset is not exposed, when controls already reduce attack paths, or when threat actors are actively exploiting a lower scored issue.
Q: What are the signs that a vulnerability prioritization model is failing?
A: The clearest signs are long delays on known exploited vulnerabilities, tickets that lack ownership, duplicate findings across tools, and high-severity work that never maps to real attack paths.
Practitioner guidance
- Rank by exploitability first Create a first-pass queue using confirmed exploitation, public proof-of-concept availability, KEV presence, and EPSS rather than CVSS bands alone.
- Bind findings to asset ownership Attach each finding to the system owner, service owner, and business criticality before assigning an SLA.
- Add reachability checks to dependency triage Use code-path analysis and environment context to separate vulnerable libraries that are actually callable from those that are merely present in the build.
What's in the full article
ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how to rank findings using exploitability, reachability, and asset criticality together.
- The article's full risk-tiering logic for turning backlog noise into defensible remediation SLAs.
- Operational guidance on consolidating scanner output into a deduplicated prioritization workflow.
- The vendor's explanation of how exposure management changes the remediation conversation for engineering teams.
👉 Read ArmorCode's guide to vulnerability prioritization and exposure management →
Vulnerability prioritization: are your controls keeping up?
Explore further
02/09/2026 1:30 pm
Severity-first triage is a governance error when exploitability is measurable. CVSS remains useful, but it cannot answer the question executives actually care about: which flaws can become incidents this week. The control failure is treating a score as a decision. Mature programmes should use severity to describe risk, then use context to decide action, especially when exposed APIs, secrets, or identity-bearing services are involved. The practitioner conclusion is simple: backlog order should be justified by attackability, not by score alone.
A question worth separating out:
Q: How should vulnerability management and exposure management be combined?
A: Use vulnerability management to identify flaws, then use exposure management to decide whether those flaws are reachable, valuable, and actually dangerous. That means combining scanner output with asset inventory, identity context, network exposure, and threat intelligence so the backlog reflects attacker paths rather than raw findings.
👉 Read our full editorial: Vulnerability prioritization fails when severity outruns exploitability
