Risk-based vulnerability management

Why severity scores alone fail

Most programs sort findings by CVSS, the Common Vulnerability Scoring System. The CVSS base score, which is what most scanners report, is a good measure of how bad a flaw could be. It does not tell you whether anyone is exploiting it, or whether the machine it sits on matters. CVSS v4.0 added threat metrics that can reflect exploitation, but they are rarely filled in.

The gap is enormous. Hundreds of thousands of vulnerabilities have been published. Only a small fraction appear on CISA's catalog of vulnerabilities confirmed exploited in real attacks, and only a small share have a better than even chance of being exploited in the next 30 days. Our daily threat forecast tracks the current figures every morning.

Meanwhile, many published vulnerabilities are rated High or Critical. A team that patches every High and Critical spends most of its effort on flaws nobody is using, while the handful that attackers are using wait in the same queue.

The three questions that decide priority

Risk-based programs answer three questions for every finding, then combine them.

1. Is it being exploited? CISA's Known Exploited Vulnerabilities catalog (KEV) is the most widely used public list of flaws confirmed exploited in the wild. It is deliberately conservative, so treat it as a floor, not a complete list. Federal civilian agencies are required to fix them by set deadlines under Binding Operational Directive 22-01, and CISA strongly recommends every organization make them a priority.
2. Is it likely to be exploited soon? The Exploit Prediction Scoring System (EPSS), maintained by FIRST, estimates the probability that a published vulnerability will be exploited in the next 30 days. It updates daily, so it catches flaws that are heating up before they reach the KEV catalog.
3. Does the asset matter? The same flaw on a domain controller and on a kiosk are not the same risk. Asset role, exposure to the internet, the data it holds and what it can reach all change the answer.

KEV tells you what is happening now. EPSS tells you what is likely next. Asset context tells you what it would cost you. Each one alone misleads; together they produce a ranked list a team can actually finish.

Building the program

• Know what you own. Scoring is only as good as the asset inventory. Every asset you can scan should report on schedule, and anything that has gone silent for 30 days or more should be investigated, not ignored.
• Score every finding on likelihood and impact. Combine KEV status, EPSS probability and the threat behind the flaw (ransomware, remote code execution, privilege escalation) with the asset's role.
• Rank fixes by how much risk they remove, not by count. One patch that closes a remote code execution flaw across 90 servers is worth more than 50 low-risk fixes.
• Verify, do not assume. A ticket marked done is a claim. A clean rescan is proof. Only a scan should lower the score.
• Keep configuration separate. Hardening against benchmarks such as CIS or DISA STIG matters, but folding it into the same number hides which problem you are fixing.
• Report one trend. Leadership needs one number over time and what moved it, not a count of open findings.

How to measure whether it is working

Track the risk score over time, the time to remediate KEV-listed findings, the share of your most critical assets carrying a known exploited flaw, and the number of assets that have stopped reporting. If the risk score falls while the open-finding count barely moves, the program is working: you are fixing what matters first.

Where Cycurion Panoptic fits

Cycurion Panoptic scores every scanned asset on what it is, what is wrong with it and how likely that flaw is to be used, then puts the fixes in order. Each asset is weighted by its role, so a flaw on a domain controller outranks the same flaw on a workstation, and every finding carries its CISA KEV status and EPSS likelihood. The result rolls up into one Risk Index from 0 to 100 with a fix plan ranked by how much each fix lowers the score. Only a scan lowers the score, configuration findings against CIS and DISA STIG benchmarks are kept beside the index rather than folded into it, and an executive PDF report is generated from the same data.

Frequently asked questions

What is the difference between vulnerability management and risk-based vulnerability management? Traditional vulnerability management finds and lists flaws, usually ranked by severity. Risk-based vulnerability management ranks them by likelihood of exploitation and business impact, so the riskiest fixes happen first.

Should we stop using CVSS? No. CVSS still describes how severe a flaw is. Use it alongside KEV, EPSS and asset context, not instead of them.

How often should vulnerabilities be rescored? Daily. EPSS changes every day and the KEV catalog grows most weeks, so a monthly ranking goes stale quickly.

What is the KEV catalog? CISA's list of vulnerabilities confirmed to be exploited in real attacks. If a finding is on it, it belongs at the top of the queue.