Risk-Based Vulnerability Management — Glossary

The longer version

Instead of fixing everything above a score, you ask more questions. Is the flaw being exploited? Is the system reachable from the internet? What data or access does it hold? Is there a mitigation? The answers move some flaws to the top and push others down.

Research consistently shows that only a small share of published flaws are ever exploited in the wild. Sorting by severity alone spends effort on flaws that attackers ignore while leaving the ones they use. Useful signals include the CISA KEV catalog and the EPSS score, published by FIRST, which estimates the probability that a flaw will be exploited.

For example, a flaw with a medium CVSS score that sits on an internet-facing server and is listed in KEV should usually be fixed before a critical flaw on an isolated internal test machine.

Combine severity, exploitation evidence, exposure and asset value, write the rule down so that it is applied the same way each time, and review exceptions.

Where we use “Risk-Based Vulnerability Management”

CybersecurityCISA Adds Exploited GitLab and Cisco Flaws
Two exploited flaws hit CISA's KEV catalog on 29 October, but upgrading GitLab to the 12 October builds still leaves a second CVSS 10.0 flaw open. Here's what to patch, and in what order.
Nov 1, 2026Key term
CybersecurityMicrosoft's Record Patch Tuesday: What More Than 1,400 CVEs Actually Mean
Microsoft's October 2026 Patch Tuesday listed about 1,413 CVEs, roughly eight times the previous monthly record. Here is what the count measures, who found the flaws, and how to turn the list into a patch order.
Nov 1, 2026Key term
CybersecurityPatch by Exploitation, Not CVSS
Sorting a patch queue by CVSS puts actively exploited flaws behind thousands that nobody is using. Four yes-or-no questions adapted from CISA's new directive give a small team a faster order.
Nov 1, 2026Key term

The longer version

Where we use “Risk-Based Vulnerability Management”

Get the Core in your inbox.