Why sorting by CVSS fails
The CVSS score describes how severe a flaw is in theory: how it is reached and what an attacker would gain. It does not say whether anyone is exploiting it. Large estates carry thousands of open CVEs, and a good share of the highest scores are on flaws that are hard to reach or that nobody has weaponised.
A team that works top-down by CVSS spends its time on theoretical risk while a lower-scored flaw that attackers use every day waits in the queue. You need two more questions: is it being exploited, and how likely is it to be?
Signal 1: is it known to be exploited? (CISA KEV)
The CISA Known Exploited Vulnerabilities catalog lists CVEs for which there is evidence of exploitation in the wild. US federal agencies must fix entries by a due date, but the list is useful to everyone: if a CVE is on it, someone is already using it.
Treat a KEV entry as urgent on any asset where the vulnerable software is present, and give it a short deadline. The catalog is public and small compared with the full CVE list, so it is a manageable first pass.
Signal 2: how likely is exploitation? (EPSS)
The Exploit Prediction Scoring System, published by FIRST, gives the probability that a CVE will be exploited in the next 30 days, as a number between 0 and 1, updated daily. It covers the large set of CVEs that are not yet on KEV.
EPSS answers a different question from CVSS: not how bad it would be, but how likely it is. A flaw with a modest CVSS and a high EPSS deserves attention before a high-CVSS flaw with a very low EPSS.
A practical order of work
- KEV entries on any asset: fix first, with a short deadline.
- Exposed assets (reachable from the Internet) with a high EPSS score.
- Assets that matter most to the client (domain controllers, production databases, VPN and edge devices) with a high EPSS score.
- Everything else, ordered by CVSS and asset criticality.
Pick an EPSS threshold that gives your team a list it can finish, then revisit it. The right number depends on how many people you have, not on a universal rule.
Add what you know about your own estate
Public scores know nothing about your network. Three facts from your own environment change the order:
- Exposure: is the vulnerable service reachable from the Internet, or only from inside?
- Evidence of attack: did the firewall or an agent log an exploit attempt against this flaw, and was it blocked?
- Asset criticality: what breaks, and for whom, if this host is compromised?
What to do when there is no fix
Some CVEs have no vendor fix yet, or the product is end of life. Do not let these bury the list. Give them their own line, apply a mitigation (disable the feature, restrict access, add a firewall rule or a virtual patch), set a date to review, and keep them out of the “fix this week” queue unless they are on KEV.
Set deadlines and prove the fix
A ranked list is only useful if it ends in closed items. Give each priority a deadline, record who owns it, and confirm the fix from data (the next scan or agent report no longer shows it), not from a ticket status. Re-rank every day or week: KEV and EPSS change, and so does your estate.
Where Cronzy Watch fits
Cronzy Watch does this ranking for you. It reads the findings your sources already produce, such as Wazuh and AWS Inspector, marks KEV entries, adds EPSS and what your firewall saw, and gives each CVE a remediation plan. See vulnerability prioritisation for how it looks in practice.