Safeguard
Industry Analysis•

How do you cite a CISA KEV number so others can check it?

To cite a KEV figure, record catalogVersion, dateReleased and count from the JSON feed, plus your fetch date and a file hash so readers can reproduce it.

Safeguard Security Team
6 min read

To cite a CISA KEV number, quote four things from the JSON feed itself: the catalogVersion, the dateReleased timestamp, the count field, and the date you fetched the file. Add a SHA-256 hash of the file you used. Without those, a KEV figure cannot be checked a week later.

Why a bare KEV number is hard to verify

The Known Exploited Vulnerabilities catalog grows. CISA describes it as the authoritative source of vulnerabilities exploited in the wild and asks organizations to use it as an input to prioritization. A sentence such as "KEV has about 1,700 entries" is true on one day and stale on another, and it gives a reader nothing to compare against.

The feed already carries the metadata you need. On 19 October 2026 the top of the JSON file read:

{
  "title": "CISA Catalog of Known Exploited Vulnerabilities",
  "catalogVersion": "2026.10.16",
  "dateReleased": "2026-10-16T17:15:48.8752Z",
  "count": 1748,
  "vulnerabilities": [ ... ]
}

The four fields to record

FieldWhere it comes fromWhy it matters
catalogVersionTop of the JSON feedNames the release you analyzed
dateReleasedTop of the JSON feed, UTCShows how fresh the release was
countTop of the JSON feedA quick sanity check against your own row count
Fetch dateYour own logShows when you downloaded it, which can differ from the release date

On the fetch date above, the release was three days old. That is normal, since the catalog only changes when CISA publishes an update. Recording both dates avoids the impression that the data is current to the hour.

Check the count against your own parse

Your parser should confirm that the count field equals the number of objects in the vulnerabilities array, and that the CVE IDs are unique. In the 2026.10.16 release, the count field said 1,748, the array held 1,748 objects, and 1,748 distinct CVE IDs appeared. If those three numbers ever disagree, say so in your write-up, because it means a parsing or feed problem rather than a finding.

A citation line you can copy

Put this near the figure, not buried in an appendix:

Source: CISA Known Exploited Vulnerabilities catalog, JSON feed, catalogVersion 2026.10.16, released 2026-10-16T17:15:48Z, 1,748 entries, fetched 19 October 2026, SHA-256 b6e27975f663...d357d.

Link the catalog page itself so readers can find the current version and compare. For hashing and storing the file, see how to freeze a vulnerability dataset.

What a citation does not do

A catalog version tells readers which data you used. It does not tell them whether KEV is the right dataset for your question. KEV lists vulnerabilities that CISA has evidence were exploited; absence from the list is not evidence of safety. For that caveat, read what KEV, EPSS and exploit databases cannot tell you.

A worked example, start to finish

Suppose you want to write "KEV holds 1,748 entries". Here is the full chain you should be able to show.

  1. Download the JSON feed and note the time in UTC.
  2. Read the top level fields: catalogVersion 2026.10.16, dateReleased 2026-10-16T17:15:48Z, count 1748.
  3. Parse the vulnerabilities array and take its length. It was 1,748.
  4. Collect the cveID values into a set. It also had 1,748 members, so each entry is a distinct CVE ID.
  5. Hash the file and store the hash with the file.
  6. Write the sentence with the version, the release date and your fetch date.

Only after step 6 is the number ready to quote. Each earlier step is a cheap check that catches a different mistake: a truncated download, a parser that skips rows, or a duplicated entry.

What to do when your number moves

If you rerun the script a week later against the live URL, the count will probably be higher and the catalogVersion will be new. That is not an error. It means the catalog has been updated. Keep the old snapshot, publish the old figure with its version, and describe the new one as a separate data point. Writing "KEV grew from 1,748 to N" is only valid if both numbers carry their own versions.

A common trap is editing a post's number in place and leaving the old citation line. Readers then see a figure that does not match the stated version. Change both together, and add a dated note, as described in keeping a corrections log.

Where the citation belongs

PlaceWhat to include
Chart captionVersion, release date, fetch date
Table footnoteVersion and counting unit
Methodology sectionFull detail plus the hash
Social or summary textVersion in a short form, such as "KEV 2026.10.16"

The shorter the format, the more important the version string, because it is the one piece that lets a reader find the exact release. See the methodology template for how this fits into a full write-up.

Common mistakes

  • Quoting the count from the catalog web page and the percentages from your own parse of a different download.
  • Citing the page URL only. The page changes with every release.
  • Leaving out the fetch date because "the release date is enough".
  • Rounding the count in prose and then showing the exact number in a table, which makes the two disagree.

Try it yourself

Click through it at your own pace, or open it full screen. Watch how findings change between scans, which is the same reason a dated snapshot matters for any statistic.

Quick check

Is the fetch date different from the release date?

Yes. dateReleased is when CISA published that version. The fetch date is when you downloaded it. Record both.

Do I need the hash if I record the version?

The version names the release. The hash proves the file you analyzed is the one you describe, which helps if a copy is later edited or truncated.

Does a KEV count tell me how many vulnerabilities are exploited?

No. It tells you how many entries CISA has listed in that release. Exploited vulnerabilities that are not listed do not appear.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.