A methodology section for a vulnerability statistics post should state the question, the source and snapshot, the filters, the counting unit, the denominator, and the tools used. Six short lines are enough if each can be checked. If a reader cannot rebuild a number from your section, add the missing line.
Why it earns links
Other writers cite posts they can verify. A methodology section turns a claim into a reproducible one, and it protects you when a reader's count differs from yours. It also stops you from drawing a conclusion the data cannot support, because writing the filters down exposes them.
The template
Copy this and fill it in before you write the prose.
| Line | What to write | Example |
|---|---|---|
| Question | One sentence | How many KEV entries were added per year? |
| Source | Dataset and URL | CISA KEV JSON feed |
| Snapshot | Version, release date, fetch date, hash | 2026.10.16, fetched 19 October 2026 |
| Filters | What you kept or dropped, with counts | None, 1,748 of 1,748 kept |
| Unit and denominator | What one row is, and the total | Entries, 1,748 |
| Tooling | Language and script link | Python 3, script in appendix |
Add two optional lines if they apply: how you handled missing values, and how you assigned categories you created yourself.
Write each line as a checkable statement
Bad: "We analyzed recent KEV data."
Good: "We analyzed the KEV JSON feed, catalogVersion 2026.10.16, fetched 19 October 2026, and counted entries by dateAdded year."
The second sentence can be reproduced by a stranger. The first cannot. For the snapshot details, see how to cite a KEV number and how to cite an OSV snapshot.
Steps for the author
- Write the question before you open the data. Changing it afterward is allowed, but note that you did.
- Record the snapshot at download time, not later from memory.
- Log every filter with before and after counts.
- Run the script from scratch on the saved file and confirm the numbers match your draft.
- Put the script and the hash where readers can reach them.
- Have someone else try to reproduce one table.
What a methodology section is not
It is not a place to defend conclusions. Keep it descriptive. Put the cautions in a separate limitations paragraph, covered in writing a limitations paragraph for KEV, EPSS and OSV analyses.
It also should not hide choices. If you grouped 46 free text values into four categories, say so and publish your rules.
A filled in example
Here is a complete methodology section for the question "how are KEV entries distributed across CWE counts?" It shows how little text you need.
Question. How many CWE labels does a KEV entry carry?
Source. CISA KEV JSON feed, catalogVersion 2026.10.16, released 2026-10-16T17:15:48Z, fetched 19 October 2026, SHA-256 recorded in the appendix.
Filters. None. All 1,748 entries were kept.
Unit and denominator. One row is one entry. The denominator is 1,748.
Missing values. 175 entries have no CWE. They are shown as their own row.
Tooling. Python 3 script, linked below.
The result a reader can rebuild from that section: 175 entries with none, 1,465 with one, 101 with two, six with three and one with four. If their numbers differ, they know exactly which line to check first.
Common gaps in real methodology sections
| Gap | Why readers care |
|---|---|
| No snapshot date | Numbers cannot be reproduced |
| No denominator | Percentages cannot be checked |
| Filters described in prose only | Counts before and after are unknown |
| Categories invented without rules | Others cannot apply the same grouping |
| Tool and version missing | Parsing differences go unexplained |
If you only fix one, fix the snapshot date. Everything else is checkable once the input is fixed.
Order of work
Many authors write the methodology last. It works better as a log kept while you work. Open a text file at the start, and every time you make a choice, add a line: what the choice was, why, and the counts before and after. At the end, the methodology section is a tidy copy of that log. This also catches a common problem, where a filter added late changes numbers you wrote earlier.
Proportion
Keep the section short. If you find yourself writing more than a screen, move detail into an appendix and keep the six lines in the post. Readers who want more will follow the link, and the rest will still see that the work is checkable. For snapshot specifics see how to cite a KEV number, and for what to do with a missing value see Unknown is not No.
A short review checklist
Before you publish, read your methodology section as a stranger would.
- Could I download the same file? Is the URL and version there?
- Could I get the same row count? Are the filters and their counts there?
- Could I get the same percentages? Is the denominator named?
- Could I tell what was left out? Are missing values counted?
- Could I run the code? Is the language, version and script linked?
If you answer no to any of these, add the missing line. A reader will make the same test, and an answer engine summarizing your post will rely on whichever of these lines it can find.
Try it yourself
Click through it at your own pace, or open it full screen. Filter the findings and notice how every count depends on the filter you chose, which is why the filter list belongs in your methodology.
Quick check
How long should a methodology section be?
As long as it takes to list the six lines. Often five to ten sentences, plus a table.
Do I need the methodology if I only quote another report?
Quote their methodology instead, and link it. If they give none, say that you could not verify the figure.
Where should it go in the post?
After the headline finding, before the detail. Readers who care will look for it, and the rest will not be slowed down.
Sources
- CISA, Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog (fetched 19 October 2026; snapshot values from the JSON feed).
Last reviewed: 19 October 2026.
