Vulnerability prioritization is the practice of deciding which findings to fix first when you cannot fix them all. The short answer: start with vulnerabilities that attackers are exploiting right now, on systems that are reachable, and treat the CVSS score as a tiebreaker rather than the queue. A CVSS 9.8 bug that nobody has weaponized, on a server behind two firewalls, can wait a week. A CVSS 7.2 bug with a public exploit, on a laptop that opens email, cannot. This guide explains why score-first queues fail, what a risk-based vulnerability management process looks like, and how to prove a fix actually landed.
Why sorting by CVSS fails
CVSS was designed to describe the technical severity of a vulnerability in isolation. The specification itself says so: the base score measures intrinsic characteristics and does not change over time or across environments. See the FIRST documentation at https://www.first.org/cvss/specification-document.
That makes it a poor sort key for a work queue, for three reasons.
It ignores whether anyone is exploiting the bug. Most published CVEs never get a working exploit. A small share do, and those are the ones that turn into incidents. A score cannot tell you which group a CVE is in.
It ignores where the bug lives in your network. The same CVE on an internet-facing web server and on an isolated lab machine gets the same base score. The risk is not the same.
It produces too many "criticals." Scanners report thousands of high and critical findings in a mid-sized estate. When everything is critical, the team picks by convenience, not by risk, and the queue stops meaning anything.
What "exploited first" means in practice
Exploitation evidence comes from a few public sources that any team can use today.
| Signal | What it tells you | Where it comes from |
|---|---|---|
| Known exploited | Attackers have used this CVE in real attacks | CISA Known Exploited Vulnerabilities (KEV) catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog |
| Exploit likelihood | Probability of exploitation in the next 30 days | FIRST EPSS, https://www.first.org/epss/ |
| Public exploit code | A working proof of concept exists | Vendor advisories, exploit databases, NVD references at https://nvd.nist.gov/ |
| Vendor emergency advisory | The vendor broke its release cycle to ship a fix | Vendor security pages |
The KEV catalog is the simplest starting point. US federal agencies are required to remediate KEV entries by set deadlines under CISA Binding Operational Directive 22-01 (https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities). The directive applies to agencies, but the logic applies to everyone: these are the bugs with confirmed attacker interest, so they go to the front of the line.
EPSS adds a second dimension. It gives each CVE a probability score based on observed exploitation activity. A CVE with a high EPSS value but no KEV entry yet is a good candidate for the second tier.
A ranking model that fits on one page
A workable risk-based vulnerability management model needs only a few inputs. Keep it simple enough that every engineer can explain why a finding is where it is.
Tier 1: exploited and reachable
The CVE is in KEV, or has a public exploit, and the affected asset is exposed: internet-facing, used by people who open mail and browse, or holds data you would report a breach of. Fix within days. If a fix is not available, apply the vendor mitigation or isolate the asset.
Tier 2: exploited or likely exploited, less exposed
KEV or high EPSS, but on an internal system with limited access. Fix in the next patch cycle. Do not let it slip two cycles.
Tier 3: high score, no exploitation evidence
CVSS high or critical, nothing in KEV, low EPSS. Fix on the normal schedule. Re-check the exploitation signals every week, because this tier is where tomorrow's Tier 1 comes from.
Tier 4: everything else
Medium and low findings with no exploitation evidence. Batch them with routine updates. Track them so the count does not grow silently.
Modifiers that move a finding up
- The asset is a domain controller, a backup server, a hypervisor, or an identity provider.
- The vulnerable component is reachable without authentication.
- Compensating controls are absent: no application control, no network segmentation, standing local admin on the box. If you have not closed those gaps, see application control with default deny and just-in-time admin rights. Each one lowers the impact of a vulnerability you have not fixed yet.
Reachability: the input most teams skip
A vulnerability is only a risk if someone can reach it. Reachability has two parts.
Network reachability. Is the port open, and from where? An unauthenticated RCE in a service that listens only on localhost is a different problem from the same bug on a port open to the internet. Open-port data belongs next to the vulnerability data, ranked by what the port exposes rather than by port number.
Human reachability. Browsers, mail clients, PDF readers and office suites are reached by every phishing email. A vulnerability in one of those on an ordinary laptop is "reachable" even though the laptop has no inbound ports at all. This is why endpoint vulnerabilities on user devices often belong in Tier 1 when the component is exploited in the wild.
External scanning confirms both. Scan your public surface the way an attacker would: enumerate subdomains, check what is listening, check TLS, check for known weaknesses. Anything found there is reachable by definition.
"Fixed" means rescanned
The quietest failure in vulnerability remediation is the ticket closed on the strength of a patch job that reported success.
Patch installers report success and then do nothing on reboot. Updates get installed and then rolled back by a later package. A machine is patched, then re-imaged from an old template.
The only evidence that counts is a rescan showing the vulnerable version is gone. Build that rule into the process:
- A finding stays open until a scan after the fix no longer reports it.
- "Marked fixed by hand" is a separate state, visible in reports, that expires if the rescan does not confirm it.
- Ring-based patching with a rescan at each ring catches the installer-says-yes-but-no case before it reaches everyone. The pattern is described in patch management rings: canary, pilot, everyone.
If your reporting shows remediation percentage, ask what event moves a finding into the "remediated" bucket. If the answer is "the ticket was closed," the number is not evidence.
What good looks like
A mature vulnerability prioritization program has these properties.
- The queue is sorted by exploitation evidence and reachability, and anyone can see why a finding is ranked where it is.
- KEV and EPSS data is refreshed automatically, and a finding moves up the same day its CVE enters KEV.
- Open ports and the external attack surface are in the same view as vulnerabilities, not in a separate tool nobody opens.
- Every finding has an owner and a due date that comes from its tier, not from negotiation.
- "Fixed" is a scan result. Reports show open, mitigated, rescanned-fixed and marked-fixed-unconfirmed as separate numbers.
- Compensating controls are tracked. A vulnerability behind application control and segmentation is noted as mitigated, with the control named.
- Hardening baselines are enforced so that configuration-class weaknesses are not counted as vulnerabilities month after month. See security hardening baselines and drift enforcement.
- The ransomware-relevant subset (initial access vectors, lateral movement, backup servers) is reviewed separately, because those are the vulnerabilities that end in an outage.
Checklist: vulnerability prioritization
- Pull the CISA KEV catalog and match it against your scan results today.
- Add EPSS scores to every finding and sort Tier 3 by EPSS, not CVSS.
- Tag assets by exposure: internet-facing, user endpoint, internal server, isolated.
- Tag crown-jewel assets: domain controllers, identity, backups, hypervisors, data stores.
- Define due dates per tier and publish them.
- Put open-port data next to vulnerability data for every host.
- Run an external scan of your public domains and compare the result with your inventory.
- Require a rescan before any finding is closed; expose hand-marked fixes in reports.
- Patch in rings with a rescan gate between rings.
- Record compensating controls per finding so mitigations are visible, not forgotten.
- Review the ransomware-path subset weekly.
- Re-check exploitation signals weekly for Tier 3 findings.
How Tracemark does it
Tracemark's Exposure Management ranks vulnerabilities with "exploited today" above the highest score, so a finding with confirmed exploitation sits at the top of the queue regardless of its CVSS value. The ranking is shown in the one console, delivered by the one agent on every endpoint.
A fix counts only after a rescan. Marking a finding fixed does not close it; the next scan has to come back clean. Open ports are ranked by risk, so network reachability sits next to the vulnerability data rather than in a separate tool.
The external web scan covers the public surface: subdomains, ports, TLS and known weaknesses, which shows which findings are reachable from the internet. Hardening handles the configuration side: risky settings are fixed in one press and re-fixed when they drift, so they stop appearing as recurring findings.
Two related views sit beside the queue. The ransomware readiness score is built by stage, and an untested backup does not count, so a weak recovery path is visible next to the vulnerabilities on the servers it depends on. Password policy compliance is measured for every account including admins, which shows where a good patch posture is undermined by weak credentials.
The same agent delivers patch management in rings (canary, pilot, everyone) where "installed" counts only after a rescan, and application control with default deny, so the compensating controls that lower a finding's urgency are managed from the same console as the finding itself.
Frequently asked questions
Should we stop using CVSS?
No. Use it as the third input, after exploitation evidence and reachability. Within a tier, CVSS is a reasonable tiebreaker. It is a bad first sort key because it cannot see your network or the attacker's current interest.
What if a KEV vulnerability has no patch yet?
Apply the vendor's published mitigation, restrict network access to the affected service, and add a compensating control such as application control or removing standing admin rights. Record the mitigation against the finding so it shows as mitigated, not as ignored. Re-check for a patch daily.
How often should exploitation data be refreshed?
Daily for KEV, since entries are added as attacks are observed. Weekly is the minimum for re-ranking the queue. The important property is that a CVE already in your estate moves up automatically when it enters KEV, without someone having to notice.
How do we handle thousands of medium findings?
Batch them. Most are fixed by routine cumulative updates and application upgrades. Track the total so it does not grow unnoticed, and watch for any of them entering KEV, which moves them to Tier 1 immediately. Do not spend triage time ranking mediums individually.
Try it
Try Tracemark free for three months. Claim it at tracemark.ca