No. An Unknown, blank or missing value in vulnerability data means the source did not record an answer, not that the answer is no. Keep missing values as their own category, report how many there are, and never fold them into "false" or "low" without saying so.
Three datasets, three ways to be missing
Missing data looks different in each public source, and each one is easy to misread.
KEV: the knownRansomwareCampaignUse field. In release 2026.10.16 (1,748 entries, fetched 19 October 2026) the author found 361 entries marked Known and 1,387 marked Unknown. A chart titled "ransomware use: yes or no" would be wrong; the honest reading is "361 entries with a recorded link, 1,387 with none recorded". Unknown is 79.4 percent of rows, so how you label it decides the headline.
KEV also has a forensicTriage field with 87 Yes and 1,661 No in this snapshot. Here the values are Yes and No, so you can use them as written, but check the field in any other snapshot before assuming it exists.
OSV: severity is optional. In the PyPI export fetched the same day, 11,336 of 26,383 records (43.0 percent) carried a severity entry. A record without one is not a low severity advisory. It is an advisory where no rating was published in that record. See which OSV advisories carry a rating.
EPSS: every CVE in the daily file has a score, but a CVE that is not in the file has no score at all. In the 19 October fetch, one KEV entry (CVE-2026-21589) had no row in the file. That is "no value", not "zero probability".
Rules that keep your statistics honest
- Count missing values explicitly. Add a row to every table: "Not recorded: n".
- Do not average over missing values. A mean of the rows that have a value describes those rows only.
- Say what the denominator is, with and without missing rows.
- Never recode Unknown to No to make a clean pie chart.
- If you must collapse categories, show the unflattened table beside it.
A small worked example
Suppose you want the share of KEV entries linked to ransomware. Three honest sentences are available:
- "361 of 1,748 entries (20.7 percent) are marked Known."
- "1,387 entries are marked Unknown, meaning no link is recorded."
- "The Known share is a floor, not an estimate of true ransomware use."
The last sentence is the important one. A recorded link can only appear if someone observed and documented it, so the true figure is at least as high as the recorded one. You cannot say how much higher from this data.
Why this is a link-worthy habit
Posts that state their missing counts get cited, because other writers can reuse the table without redoing the checking. Posts that quietly drop or recode them get corrected. For a deeper look at KEV ransomware flags, see which KEV entries carry the ransomware flag.
A worked example with three fields
Build one small summary table for a post and watch where the missing values go.
| Dataset and field | Present | Missing or Unknown | Honest sentence |
|---|---|---|---|
| KEV knownRansomwareCampaignUse | 361 Known | 1,387 Unknown | 361 entries have a recorded link |
| OSV PyPI severity | 11,336 records | 15,047 without | 43.0 percent carry a severity entry |
| EPSS for KEV entries | 1,747 matched | 1 no row | One entry had no EPSS row on this date |
The PyPI figure of 15,047 is simply 26,383 minus 11,336. Every row in the table can be rebuilt from the files named in the sources.
Notice what the table does not do. It never converts a missing value into a statement about the underlying risk. A reader can see the size of the gap and decide how much weight the present values deserve.
Why analysts convert Unknown to No, and why that fails
The temptation is understandable. A yes or no chart is easier to read, and a model or a spreadsheet often wants a clean binary column. The cost is that you assert something you did not observe. If you later learn that half of the Unknown entries were in fact linked to ransomware, every figure derived from your binary column is wrong, and so are the posts that cited you.
A better pattern is to carry a three state value: yes, no, not recorded. Keep it through every step. At the end, decide whether to show three bars or two, and if two, which way you folded the third and why.
Steps to audit your own tables
- List every field you use and its allowed values.
- Count each value, including blank and Unknown.
- For each field, write one sentence saying what a missing value means in that source.
- Search your draft for words like "no", "none" and "zero" that came from folding.
- Add the missing count next to every share, or footnote it.
- Recompute the shares with and without the missing rows and see if the story changes.
Step six is the most valuable. If the story is the same either way, say so; readers will trust the finding more. If it changes, the missing values matter, and you should lead with that.
Missing values in other places
The same rule applies beyond these three datasets. A scanner that reports no findings for a package may mean no advisory exists, or that the package was not recognized. A blank severity in a report may mean no one rated it. When you read a vendor report that makes claims from such fields, ask what the missing category was and how it was treated. For reading severity sources, see who rated this finding.
Try it yourself
Click through it at your own pace, or open it full screen. Notice that "no exploit evidence" and "not exploitable" are different statements.
Quick check
Can I replace Unknown with No for a quick chart?
Only if the chart title says so and a footnote gives the Unknown count. Otherwise keep it as a third bar.
Does a missing EPSS score mean low risk?
No. It means the CVE had no row in that day's file. Look up why before treating it as anything.
What if I need a binary column for a model?
Keep a separate indicator column for "not recorded" so the model can learn from the gap, or exclude those rows and say so. Do not silently set them to No.
Sources
- CISA KEV JSON feed, catalogVersion 2026.10.16, https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (fetched 19 October 2026; counts computed by the author).
- EPSS daily scores file, https://epss.empiricalsecurity.com/epss_scores-current.csv.gz (fetched 19 October 2026; computed by the author).
- OSV PyPI export, https://osv-vulnerabilities.storage.googleapis.com/PyPI/all.zip (fetched 19 October 2026; computed by the author).
- OpenSSF OSV schema, https://ossf.github.io/osv-schema/ (fetched 19 October 2026).
Last reviewed: 19 October 2026.
