Notifications
Clear all
Topic starter
18/08/2026 2:41 pm
TL;DR: Only 2-7% of published vulnerabilities are ever seen exploited in the wild, according to ArmorCode's analysis, which argues that CVSS-only queues push teams toward volume over real exposure. Risk-based remediation becomes defensible when severity, likelihood, business context, and reachability are combined into one ranked decision model.
NHIMG editorial — based on content published by ArmorCode: How to Prioritize Vulnerability Remediation with Risk, Not Just CVSS Blog July 24, 2026
By the numbers:
- Only 2-7% of published vulnerabilities are ever seen exploited in the wild.
Questions worth separating out
Q: How should security teams prioritise vulnerabilities when remediation capacity is limited?
A: Prioritise by exposure, business criticality, and the identities attached to the affected asset.
Q: Why do critical vulnerabilities sometimes deserve lower priority than medium ones?
A: Because severity is not the same as exposure.
Q: How can teams tell whether vulnerability management is reducing real risk?
A: Look for faster exposure confirmation, shorter exploit-to-containment intervals, and measurable blast-radius reduction across production systems.
Practitioner guidance
- Build a multi-signal remediation score Combine CVSS, EPSS, asset criticality, data classification, and reachability into one ranked queue so analysts work the most exposed issues first.
- Separate reachable from theoretical findings Use code-to-runtime checks to remove dependencies and libraries from the top of the queue when the vulnerable path cannot be triggered in your environment.
- Tie remediation priority to business exposure Escalate lower-severity issues on customer-facing or revenue systems ahead of higher-severity issues on isolated test assets when the business impact is greater.
What's in the full article
ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:
- How the dynamic risk score combines scanner data, exploit likelihood, business context, and reachability into one prioritisation model
- Examples of how ArmorCode applies exposure ranking across more than 375 integrations without requiring teams to rebuild their existing scanner stack
- The article's full explanation of how to interpret EPSS, CVSS, and business context when the queue contains tens of thousands of findings
- The remediation-tracking angle that shows how to measure risk retired rather than tickets closed
👉 Read ArmorCode's analysis of vulnerability remediation prioritisation by risk →
Vulnerability remediation by risk: is your queue actually reducing exposure?
Explore further
18/08/2026 3:25 pm
Severity-only remediation is an operational blindfold. CVSS is useful for describing worst-case impact, but it cannot rank actual enterprise exposure on its own. Once teams equate technical severity with priority, they create queues that look rigorous while remaining disconnected from attacker behaviour. The practical result is a control programme that measures ticket closure instead of risk retirement.
A question worth separating out:
Q: What should teams do when a flaw is severe but not reachable in their environment?
A: Do not treat it as an immediate priority unless other context changes the picture. Validate the runtime path, confirm whether the affected code is executed, and check for compensating controls before assigning scarce remediation effort. If the flaw cannot be reached, it belongs lower in the queue.
👉 Read our full editorial: Vulnerability remediation prioritization needs risk, not CVSS alone
