A limitations paragraph says what your data cannot show, in specific terms, right after your findings. For KEV, EPSS and OSV, the core cautions are: KEV lists known exploitation, not all exploitation; EPSS is a probability, not a prediction for your host; OSV completeness varies by ecosystem. Write each as a plain sentence.
Why it builds trust
Readers and answer engines both quote posts that know their own limits. A limitations paragraph also protects you from being cited for a claim you never made. It should be short, specific and tied to the dataset you used, not a generic disclaimer.
What to say for each source
| Dataset | Limitation | Sentence you can adapt |
|---|---|---|
| KEV | A list of vulnerabilities CISA has evidence were exploited. Absence is not safety | "KEV is a floor on known exploitation, not a count of all exploited flaws." |
| KEV | Single snapshot | "We used release 2026.10.16; later releases will differ." |
| EPSS | A daily global probability for a CVE | "EPSS estimates exploitation in the next 30 days across all environments, not for a specific system." |
| EPSS | Scores change daily and by model | "Scores are from 18 October 2026 and model v2026.06.15." |
| OSV | Optional fields vary by source | "Summary, alias and credit fields are filled unevenly across ecosystems." |
| OSV | Withdrawn records exist | "Counts exclude withdrawn records" or "include", as you chose. |
The EPSS wording follows FIRST's description of the model: a probability that a published CVE will be exploited in the wild in the next 30 days.
Limits that apply to all three
- You looked at a snapshot, and the data keeps changing.
- Counts depend on your counting unit. State it.
- You did not verify each record against its original source, unless you did.
- Correlation between datasets does not mean one caused the other. For example, a high EPSS for KEV entries does not show the model "caused" anything. See what the spread of EPSS among KEV entries shows.
- Free text fields were grouped by rules you wrote, and a different rule would give different counts.
Steps
- Reread your findings and for each, ask "what would make this false?"
- Write one sentence per answer.
- Remove sentences that apply to no finding in your post.
- Place the paragraph under the findings, not in a footer.
- Keep it under 150 words.
What not to write
Avoid "results may vary" and "this is not exhaustive". They say nothing. Avoid claiming the analysis is "comprehensive" or "definitive". If you are not sure of a fact, say it should be checked rather than hiding it. For the companion section on how you counted, see the methodology template.
A worked example paragraph
Here is a limitations paragraph for a post that joined KEV and EPSS, under 150 words:
"KEV lists vulnerabilities that CISA has evidence were exploited, so it understates exploitation we cannot see. We used release 2026.10.16, and later releases will differ. EPSS is a daily probability for a CVE across all environments, not a forecast for any one host, and we used scores from 18 October 2026. One KEV entry had no EPSS row and is excluded from score statistics. We grouped free text values by rules we wrote, and a different rule would give different counts. We did not verify each entry against its vendor advisory."
Every sentence ties to a choice made in the analysis, and every sentence can be checked. Compare that to "results may vary", which tells the reader nothing.
Match each limitation to a finding
| Finding in the post | Limitation to pair with it |
|---|---|
| A share of KEV entries with some property | KEV is a list of known cases, so the share describes the list |
| High EPSS among KEV entries | EPSS and KEV are different evidence, so this is not validation |
| A count of OSV advisories | Records are not unique vulnerabilities, and withdrawn records exist |
| A comparison across ecosystems | Field completeness varies by source |
| A trend across dates | Snapshots, model versions and release timing differ |
Common limits that authors forget
- Survivorship. A dataset of listed items cannot tell you about unlisted ones.
- Time. A one day snapshot says nothing about stability.
- Definitions. Your category rules are a choice.
- Joins. Unmatched rows are excluded from statistics.
- Sampling. If you used five ecosystems out of many, you sampled, and the sample is not random.
Steps to write yours
- List your findings.
- For each, write what would make it false.
- Convert each answer into a plain sentence.
- Delete anything that does not apply.
- Put the paragraph after the findings.
- Have a colleague read it and say what they now would not claim.
The last step is the useful one. If a reader leaves with a narrower claim than you intended, the paragraph is doing its job.
Tone
Be direct and calm. The goal is accuracy, not self protection. A limitation that you state is a boundary on your claim, and a boundary makes the claim stronger. For the section that describes how you counted, see the methodology template.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how evidence of exploitation and exploitability change a finding, then compare that with what a global list can and cannot say about your own systems.
Quick check
Does a limitations paragraph weaken my post?
No. It tells readers exactly how far they can trust each number, which is why other writers cite posts that include one.
Should limitations come before the findings?
After is better. Readers want the result first and the cautions next to it.
Should the limitations paragraph mention that the data may change?
Yes, and give the snapshot date. It tells readers which version your claims apply to.
Sources
- FIRST, EPSS overview, https://www.first.org/epss/ (fetched 19 October 2026).
- CISA, Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog (fetched 19 October 2026).
- OSV data documentation, https://google.github.io/osv.dev/data/ (fetched 19 October 2026).
Last reviewed: 19 October 2026.
