Choose the dataset by the question. KEV answers "was this exploited, according to CISA?" EPSS answers "how likely is exploitation in the next 30 days?" OSV answers "which package versions does an advisory affect?" NVD holds the CVE record itself. Using the wrong one produces a number that sounds right and means something else.
Decision table
| Your question | Fits | What it cannot tell you |
|---|---|---|
| Has this CVE been exploited in the wild? | KEV | Whether unlisted CVEs were exploited |
| How likely is exploitation soon? | EPSS | What will happen on your host |
| Is my package version affected? | OSV | Whether the code path is reachable |
| What does the CVE record say? | NVD | Open source package ranges in detail |
| How fast do entries reach the catalog? | KEV plus CVE dates | Causes of delay |
| How do ecosystems differ in advisory volume? | OSV per-ecosystem exports | Real vulnerability counts |
The EPSS description from FIRST is a probability that a published CVE will be exploited in the wild in the next 30 days. The KEV page describes the catalog as CISA's authoritative source of vulnerabilities exploited in the wild. OSV's documentation describes aggregated advisory records exported by ecosystem. Those are three different statements, and each limits what a study can claim.
Mismatches to avoid
- Using EPSS to claim something was exploited. It is a probability, not an observation.
- Using KEV to estimate how common exploitation is. KEV is a list of known cases, so it understates.
- Using OSV record counts as a count of vulnerabilities. A flaw can have several records. See OSV advisory records versus unique vulnerabilities.
- Using one dataset's fields to fill another's gaps, such as copying severity from a different source without saying so.
Combining datasets
Many good posts join two sources. Do it deliberately:
- Write the single question first.
- Name the key you will join on, usually the CVE ID.
- Decide how to handle rows with no match. See the join post.
- Record each snapshot, since they update on different schedules.
- State which dataset defines the population.
For practitioners rather than researchers
The same split applies to day to day triage. Exploitation evidence, likelihood and reachability are different signals, and none replaces the others. For triage use, see which signal to read first. Safeguard's reachability analysis and dependency scanning address the local question that global datasets cannot, and a free scan is available at gold.safeguard.sh/scan.
A worked example, three questions
Take three plausible research questions and match each to a source.
Question one: "Of the CVEs in a customer's SBOM, which have a record of exploitation?" Use KEV as the primary source, because it lists exploitation CISA has evidence of. Join on the CVE ID. Report unmatched IDs, and say that absence from KEV is not evidence of safety.
Question two: "Which of those are most likely to be attacked next month?" Use EPSS, with the score date and model version. Say that it is a probability across environments, not a prediction for that customer.
Question three: "Which versions of each package are affected?" Use OSV, which records affected versions as ranges or lists per package, and read the introduced and fixed events. Say which field you used.
Each question needs a different source, and a post that uses KEV to answer question two, or EPSS to answer question one, is making a category error.
When one dataset is not enough
| Situation | Add |
|---|---|
| KEV says exploited, but you cannot tell if you are affected | OSV or the vendor advisory for versions |
| OSV says a version is affected, but is it reachable | Reachability analysis on your code |
| EPSS is low, but the product is exposed | Your own asset and exposure data |
| NVD record lacks a score | Another severity source, labeled as such |
No public dataset knows your environment. Global signals narrow the list, and local facts decide the order.
Steps for choosing
- Write the question as a sentence with a verb: "count", "compare", "rank", "explain".
- Identify the unit: CVE, advisory record, package version, entry.
- Pick the dataset whose unit and field match.
- Check the limits of that dataset in its own documentation.
- If you need two datasets, decide the join key and the missing value rule.
- Record snapshots for each.
A caution on NVD
The NVD holds the CVE record and its metadata, including enrichment status that can change after a CVE is published. If your question depends on a score or on configuration data, check whether the record has been analyzed before you rely on it. See why a new CVE shows no severity score for what that gap means.
Wording your claim to match the dataset
Once you have picked the source, check that your sentence only claims what that source supports.
| Weak claim | Claim the data supports |
|---|---|
| Attackers favor this product | CISA lists n entries for this vendor in release 2026.10.16 |
| This CVE will be exploited | EPSS gave this CVE a probability of p on the score date |
| Ecosystem X is less secure | Ecosystem X has fewer or more advisory records in this export |
| This package is vulnerable | This version falls inside an affected range in this record |
Each supported claim names its source and its date, and none of them asserts a cause or a forecast the data cannot carry.
Try it yourself
Click through it at your own pace, or open it full screen. See which signals a single finding carries.
Quick check
Can KEV and EPSS answer the same question?
No. KEV records known exploitation. EPSS estimates likelihood. They are often used together, but they answer different questions.
Is NVD or OSV better for open source packages?
OSV is built around package ecosystems and version ranges. NVD is the CVE record. Many analyses use both and say which supplied what.
Is it acceptable to use only one dataset?
Yes, if the question fits it. State the limits of that dataset in your limitations paragraph.
Sources
- CISA, Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog (fetched 19 October 2026).
- FIRST, EPSS overview, https://www.first.org/epss/ (fetched 19 October 2026).
- OSV data documentation, https://google.github.io/osv.dev/data/ (fetched 19 October 2026).
Last reviewed: 19 October 2026.
