Not without checking. Treat a chatbot's KEV, EPSS or OSV figure as a lead, not a fact. Ask for the source and the snapshot date, then recompute the number from the primary file. If the chatbot cannot name both, do not quote the number.
Why the number may be wrong
Vulnerability datasets change daily, and a model answers from whatever it learned or retrieved, which may be out of date. The KEV feed's top line shows a catalogVersion and a count, and on 19 October 2026 it read 2026.10.16 and 1,748. A figure from a model with older knowledge would describe an older release. Even a model with search can pull a number from a blog post that itself used a different snapshot or a different bucketing rule.
Models can also state a figure confidently with no source at all. Reading fluency is not evidence.
A five step check
- Ask for the source URL and the snapshot or date. No source, no use.
- Open the primary source. For KEV, the CISA catalog and its JSON feed. For EPSS, the FIRST data downloads. For OSV, the documented export bucket.
- Recompute the number yourself, with a few lines of code.
- Compare. If they differ, find out why before you pick a side: snapshot date, counting unit or filter.
- Cite the primary source and your snapshot, not the chatbot.
Where the usual mismatches come from
| Symptom | Likely cause |
|---|---|
| Count slightly off | Different catalog release |
| Year totals differ | dateAdded versus CVE ID year |
| Percentage off | Different denominator |
| Score differs | Different EPSS date or model |
| Advisory counts differ | Withdrawn records included or not |
Several of these are covered in why two KEV posts disagree and show the denominator.
Using a chatbot well
Chatbots are useful for writing the script, explaining a field, or suggesting what to check. Ask it to write code that reads your frozen file and prints the count, then run that code yourself. That uses the model for what it does well and keeps the number tied to data you can inspect.
Do not paste an unverified figure into a report, ticket or customer answer. If you must use a number before you can verify it, label it as unverified and give the date.
What this means for teams
Set a rule: any statistic that leaves the team needs a source, a snapshot and an owner who reran it. That applies equally to numbers from vendors, blogs and models. If you want a view of your own dependencies rather than a global number, Safeguard offers SBOM and dependency scanning, and a free scan is available at gold.safeguard.sh/scan.
A worked example of a bad answer and how to catch it
Imagine you ask an assistant "How many entries are in the CISA KEV catalog?" and it answers with a round number and no date. Here is how you would check it using the data from 19 October 2026.
- Ask for the source and the date. If it gives a page but no date, you still do not know the release.
- Download the JSON feed and read the top. The catalogVersion was 2026.10.16 and the count was 1,748.
- Count the array. It held 1,748 objects.
- Compare. If the assistant said something else, the likely reasons are an older release, a different counting unit or a number copied from a blog post.
- Write down the verified number, with its version.
That whole check takes about five minutes, and it turns an unverifiable claim into a cited one.
Questions that are easy to get wrong
| Question | Why a model may get it wrong |
|---|---|
| How many KEV entries were added in a year | Bucketing rule, release date |
| What is the EPSS score of a CVE | Scores change daily |
| How many advisories does an ecosystem have | Records versus unique vulnerabilities, withdrawn records |
| Which vendor has the most KEV entries | Vendor name normalization |
| How old are KEV entries | CVE ID year versus publication date |
For several of these, a model has no way to know the answer without reading the current file, and the right behavior is to say so or to fetch it.
Prompts that help
Ask the assistant to show its work as code that reads your saved file, to print intermediate counts, and to list assumptions. Then run it. If it quotes a number from memory, ask for the file and snapshot it came from. If it cannot name them, treat the number as unverified.
You can also ask it to find the weakest part of its own answer. That does not replace checking, but it often reveals the counting unit or date it assumed.
Policy for teams
Write a one page rule: statistics that leave the team need a primary source, a snapshot, a method and an owner. Apply the same standard to vendor reports and to model output. See reading between the lines of vendor research reports for questions to ask of any report. When a model produces CVSS or severity text, remember that a generated rating is not a risk assessment; see why an LLM CVSS score is not a risk score.
Try it yourself
Click through it at your own pace, or open it full screen. Compare the numbers shown with the evidence behind them.
Quick check
Is a chatbot with web search reliable for these numbers?
It is better than one without, but it may quote a secondary page. Still verify against the primary file.
What is the fastest way to verify a KEV count?
Download the JSON feed, read the count field, and compare it with the length of the vulnerabilities array.
Is it fine to use a chatbot to explain a field in the data?
Yes, for explanation. Then confirm the definition in the source's own documentation before you rely on it.
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).
- CISA, Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog (fetched 19 October 2026).
Last reviewed: 19 October 2026.
