How to triage a CVE in five minutes
When a new CVE lands in your queue, the fastest path to a correct patch decision is a fixed sequence of checks, not an open-ended investigation. Five steps, in order: identify what you are looking at, check KEV, check EPSS, check CVSS and its exploitability sub-metrics, then check whether the vulnerable code is actually reachable in your environment. Each step either ends the triage early or narrows what the next step needs to answer.
Step 1: Identify what you are actually looking at
Start with the CVE ID itself and confirm it maps to something you run: exact product, exact version range, and the platform or configuration the advisory names. A surprising number of "urgent" tickets turn out to reference a module, plugin, or version your organization never deployed. Pull the vendor advisory and the NVD entry for the CPE match before doing anything else. If the affected version range does not include what is in your inventory, you are done, close the ticket with that note, and move to the next item.
Step 2: Check KEV first
Query the CVE against CISA's Known Exploited Vulnerabilities catalog before you look at either of the other two numbers. A KEV listing means CISA has evidence of real exploitation happening now, not a prediction that it might happen. If the CVE is listed, its priority is already decided: treat it as top of queue regardless of what CVSS or EPSS say, and move straight to Step 5 to confirm it is reachable in your environment before you patch. There is no scenario where a KEV entry waits behind a non-KEV finding with a higher CVSS score.
Step 3: Check EPSS
If the CVE is not in KEV, pull its EPSS score and percentile from FIRST. EPSS estimates the probability of exploitation in the next 30 days, updated daily, so a score checked this morning can shift by tomorrow if new exploitation signals come in. Use the common working thresholds: above roughly 10 percent counts as elevated and worth scheduling ahead of routine patching, above roughly 50 percent counts as high and should move up near KEV-level urgency. A very low score, especially on a CVE that is more than a few weeks old, is a strong signal that real-world attacker interest has not materialized and is unlikely to spike without a new development, such as a public proof-of-concept release.
Step 4: Check CVSS and the exploitability sub-metrics
CVSS now tells you how bad a successful exploit would be, which sets how much urgency to apply once KEV and EPSS have told you whether exploitation is happening or likely. Do not stop at the single base score. Open the vector string and read the sub-metrics that actually determine exploitability in practice: Attack Vector (network versus local versus physical access), Privileges Required, and User Interaction. A 9.1 that requires an authenticated local user to click through a prompt behaves very differently in your risk model than a 9.1 reachable unauthenticated over the network. Those sub-metrics, not the rolled-up number, are what tell you how hard an attacker's job actually is against your deployment.
Step 5: Check whether it is reachable and affects you
This is the step that is specific to your environment and that no public score can answer for you. Ask directly: is the vulnerable component internet-facing or internal only? Is it actually loaded and in use, or installed but dormant, such as a library pulled in as a transitive dependency that the vulnerable function path never calls? Are there compensating controls already in place, a WAF rule, network segmentation, an authentication layer in front of it, that reduce the real exploitability below what the advisory assumes? A KEV-listed, Critical-CVSS CVE in a service that is firewalled off from any network an attacker can reach is still worth fixing, but it is not the same five-alarm emergency as the identical CVE sitting on an internet-facing load balancer.
Deciding patch urgency
Once the five checks are done, the SLA mostly falls out of the combination rather than requiring a fresh judgment call each time.
| Signal combination | Recommended urgency |
|---|---|
| KEV listed, reachable | Emergency, patch or mitigate same day |
| KEV listed, not currently reachable | Patch this week; confirm compensating controls hold until then |
| Not in KEV, EPSS high (>50%), network-exploitable | This week |
| Not in KEV, EPSS elevated (>10%) | This sprint |
| Not in KEV, EPSS low, CVSS High/Critical | Normal patch cycle; do not let the CVSS number alone escalate it |
| Does not affect your inventory (Step 1) | Close, no action |
Doing all five checks by hand means separate visits to NVD, FIRST, and the CISA KEV catalog for every single CVE, which is where the five minutes usually disappears into fifteen. The lookup tool at / returns CVSS, EPSS, and KEV status for a CVE ID in one query, so Steps 2 through 4 collapse into a single lookup and the time budget goes to Steps 1 and 5, the two steps that actually require knowing your own environment.
The sequence matters more than any individual threshold. Checking KEV before EPSS, and EPSS before CVSS, means you never spend your attention on a theoretical severity score before confirming whether the vulnerability is something attackers are already using. Once that ordering is a habit, five minutes per CVE is realistic even under a backlog, because most of the work is a single query rather than an investigation.