Check six things in order: the CISA KEV catalog, the current EPSS score and 30 day trend, public exploit sources, the vendor advisory, whether the component is present, and whether it is reachable. Write down the date and what you found. Ten minutes is enough for a first answer.
Step 1: KEV (about one minute)
Search the CISA Known Exploited Vulnerabilities catalog for the CVE ID. A match means CISA has reliable evidence of active exploitation and a remediation action. CISA strongly recommends that all organizations prioritize listed vulnerabilities. If it is listed and you run the product, stop here and go to your emergency process.
Step 2: EPSS now and the trend (two minutes)
Query the FIRST EPSS API for the CVE. Add the time-series scope to get the last 30 days of score and percentile.
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2021-40438&scope=time-series&pretty=true"
Read the probability, the percentile and the direction. A recent climb means new inputs arrived, such as exploit code or discussion. FIRST says daily score changes come from changed inputs, and that a recent attack does not directly move the score. Remember the model version dates if the chart is long. See why a score history jumps.
Step 3: public exploit sources (two minutes)
Search a public exploit archive such as the Exploit Database by CVE, and check whether a packaged module or a scanner template exists. Note what you find and its kind. A packaged module or template lowers the skill needed, as discussed in PoC, module or template. Do not run any code.
Step 4: the vendor advisory (one minute)
Open the vendor's notice. Look for fixed versions, workarounds and any statement that exploitation has been observed. If the wording is vague, see what actively exploited means in a notice.
Step 5: presence (two minutes)
Search your inventory, SBOMs and image contents for the affected product and version range. If you have no current inventory, this step takes the longest, which is itself a finding.
Step 6: reachability (two minutes)
For a service, can anyone from outside reach it? For a library, does your code call the vulnerable function? Note the answer and the evidence.
The record template
Copy this into the ticket.
| Field | Value |
|---|---|
| CVE and date checked | |
| On KEV | yes or no |
| EPSS probability, percentile, 30 day direction | |
| Public exploit material | none, proof of concept, module or template |
| Vendor says exploited | yes, no or unclear |
| Present in our estate | yes or no, how checked |
| Reachable | yes or no, how checked |
| Decision, owner, re-check date |
Reading the result
If KEV is yes and it is present, move now. If KEV is no but a packaged exploit exists, EPSS is climbing and the service is exposed, treat it as high. If it is not present or not reachable, close with the evidence and set a re-check date. The re-check matters: new exploit code can appear after you close.
Safeguard's reachability analysis, asset discovery and SBOM and dependency scanning speed up steps five and six. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Run through the check once and compare the order of questions to the six steps above.
Quick check
Which source should I check first?
KEV, because a listing means CISA has reliable evidence of exploitation and a fix or mitigation to apply. Then EPSS, exploit sources, vendor notice and your own exposure.
Is ten minutes realistic?
For a first answer, yes, if your inventory is current. Without one, finding presence takes longer than the other five steps together.
Sources
- KEV catalog and criteria (CISA)
- EPSS API documentation (FIRST)
- EPSS Frequently Asked Questions (FIRST)
- About the Exploit Database (OffSec)
Last reviewed: 19 October 2026.
