CVE_Prioritizer: ranking CVEs by EPSS, CVSS and CISA KEV

The problem with a severity score as a work queue

CVE Prioritizer exists because severity alone is a poor ordering of work. A scanner that reports ten thousand findings with CVSS scores is not giving a defender a queue; it is giving them a list that has to be re-reasoned from scratch every cycle.

The project's argument is built on two data sources that say different things. CVSS captures the fundamental properties of a vulnerability, the technical characteristics that make it severe. EPSS supplies data-driven threat information, a prediction of the probability that a vulnerability will be exploited in the wild. The project leans on the correlation between the two, and points out that a scatter of CVEs against both scores shows most vulnerabilities sitting near the bottom, with only a small share above an EPSS score of 0.5.

The finding quoted from the FIRST EPSS User Guide is that this refutes a common assumption, namely that attackers only look for the most severe vulnerabilities. So severity ranking throws away the signal that says which of the severe ones are actually being used.

The tool combines those with CISA's Known Exploited Vulnerabilities catalog and with VulnCheck's community resources, which the project lists as NVD++ and VulnCheck KEV. The stated purpose is insight into the likelihood of exploitation and the potential impact on your information system.

This is a prioritisation tool, and the distinction from a scanner matters. It never asks what is running on your network, what versions you have, or whether a given library is present. It reads public CVE records and tells you which ones deserve attention first.

Five priority levels built from two thresholds and the KEV list

The prioritisation logic is simple enough to describe in full, and that is a strength for anyone who has to justify a patching order.

Two numbers do the work. The CVSS threshold is set to 6.0, described as the weighted average CVSS score from CVE Details, and the EPSS threshold is set to 0.2. The project says these were refined from FIRST's recommendations plus their own experience.

Those thresholds cut the plane into quadrants, and a third input pulls one category further up. A CVE found in CISA's Known Exploited Vulnerabilities catalog becomes Priority 1+, whatever its scores say, on the reasoning that it is already being exploited somewhere. The remaining four bands map onto the quadrants: Priority 1 is the upper right, vulnerabilities both more likely to be exploited and capable of fully compromising the system. Priority 2 is the lower right, severe but less likely to be exploited, and the documentation says these should still be watched in case the pattern of attacks changes. Priority 3 is the upper left, more likely to be exploited but not critically impactful on their own, with the caveat that further research is needed to understand how they might be used in a chained attack. Priority 4 is the lower left, both low probability and low impact, and these are the ones to de-prioritise.

The thresholds are not baked in. The documentation states that you can define your own thresholds when running the tool, so the risk appetite is a parameter rather than a constant. For an organisation that considers a score of 8 on an internet-facing service to be a different event from a score of 8 on an internal tool, that matters more than the default values do.

Installing it, and the API keys that decide how you get data

There are two installation routes and the project gives both. From a clone:

git clone https://github.com/TURROKS/CVE_Prioritizer.git
cd CVE_Prioritizer
pip install -r requirements.txt

Or straight from PyPI:

pip install --user cve_prioritizer

The package name on PyPI writes the two words joined together, while the distribution metadata in the project file separates them with a hyphen, and the console script is registered under both the cve-prioritizer and cve_prioritizer names, so either spelling of the command works.

The more important step comes before any of that. The usage section tells you to request API keys to avoid public rate limits, and it names two: an NVD key from NIST and a VulnCheck key for the faster data path. Keys are stored in a .env file, and the -sa or --set-api option is what writes them there. A .env file is already present in the repository listing, so the project expects this file to exist in your working directory.

The data source selection is the other decision. NIST NVD is the default. For NVD++ you use -vc or --vulncheck, and the documentation also lists VulnCheck as an option. The distinction is throughput, since registering for a VulnCheck key is what makes that path fast, and the project labels the VulnCheck source with the word Fast.

What sits in the repository, and who writes it

The layout is a small Python package with a script-style entry point. There is a cve_prioritizer.py file at the root and a cve_prioritizer/ package beside it, which is a slightly unusual duplication that the setup files explain: the legacy setup.py registers a console script pointing at cve_prioritizer:main, while the modern pyproject.toml registers both script names pointing at cve_prioritizer.cve_prioritizer:main.

The dependencies are ordinary and worth naming because they show the shape of the tool. click provides the command line interface, requests handles the API calls, pandas does the tabular work of joining and sorting the records, jinja2 and the scripts/templates/*.html package data are for HTML report output, termcolor and fade colour the terminal output, and python-dotenv reads the .env file where the API keys live. Python 3.8 or newer is required by the project metadata, though the older setup.py still says 3.6.

There is a tests/ directory and an optional test extra that pulls in pytest, and the package also has a docs/ directory and a scripts/ directory alongside the misc/ folder that holds the images used in the readme.

The author and maintainer are the same person, Mario Rojas, and the licence is BSD-3-Clause, which is the same licence the project file states as BSD 3-Clause. For a tool that a security team runs against its own vulnerability backlog, a permissive licence with no copyleft obligation is the expected and welcome choice.

The release history is regular. Tags run v1.8.3 on 2025-03-06, v1.9.0 on 2025-03-29 and v1.10.1 on 2025-07-20, with the manifest sitting slightly ahead at 1.10.2, and the last push was on 2026-08-23, so the code is moving faster than the published tags.

Where CVE_Prioritizer does not reach

The first limit is the one the tool never claims to solve. It has no inventory awareness. It does not read your SBOM, does not query your container registry and does not know which of the ten thousand CVEs is actually in your estate. It ranks the whole catalogue, and a CVE that scores Priority 1+ because CISA has seen it exploited may be entirely irrelevant to you while a Priority 4 sits inside a service you run. Reading the output as a queue rather than as a shortlist is the mistake this tool invites.

The second is data freshness and coverage. Everything comes from public sources over the network, so the tool is only as good as the API responses it gets, and the NVD path is rate limited without a key. Running it against a large CVE list is a network-bound operation, and a rate-limited or incomplete response would show up as missing or partial data rather than as an error you would notice.

The third is that the scoring is inherited, not original. The EPSS and CVSS scores are other people's numbers, and the mapping into five bands is a threshold choice on top of them. The project is candid that the thresholds were refined from FIRST's recommendations and the author's own experience, which means the output reflects a judgement call by one person. That is fine if you tune the thresholds, and misleading if you take the bands as an industry standard, because no such standard is claimed.

The fourth is the scope of what it outputs. The priority table and the correlation analysis are for deciding where to start. Deciding whether a finding is exploitable in your environment, whether a compensating control exists, or how long a patch will take to arrive is still manual work, and the tool does not attempt to close that gap.

Editorial conclusion

CVE_Prioritizer fits a team that has a large backlog of unpatched CVEs and needs a ranking it can defend to its management, because it turns severity, exploit probability and known exploitation into five named priority levels with thresholds you can set yourself. It is the wrong tool if you need to know whether a CVE applies to your systems, because it works from public records and not from your inventory, and it is wrong if you need a continuously updated feed rather than a one-off report. Before running it, request an NVD API key and a VulnCheck key and store them with the -sa or --set-api option, run it once against a known set of CVEs to see how the thresholds land on your own data, and check the version you install, since the newest release tag is v1.10.1 from 2025-07-20 while the manifest already reads 1.10.2 and the last push was on 2026-08-23.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. README
4. Releases
5. TURROKS/CVE_Prioritizer on GitHub