Use datePublished for "when the CVE List first showed it", datePublic for "when it was disclosed", and dateUpdated for "when the record last changed". Do not use dateReserved to say when a flaw was found. The CVE schema itself warns that the reserved date does not necessarily indicate discovery or disclosure.
The dates in a record
The CVE Record Format defines each one:
| Field | What the schema says | Use it for |
|---|---|---|
| dateReserved | When the ID was reserved in the CVE services system | Counting IDs, not finding dates |
| dateAssigned | When a CNA associated the ID with a vulnerability | Process timing |
| datePublic | If known, when the vulnerability was disclosed publicly | Exposure window, SLA clock |
| datePublished | When the record was first published in the CVE List | "Appeared in the list" |
| dateUpdated | When the record was last updated | Change detection |
| dateRejected | When the ID was rejected | Retire a finding |
The schema describes datePublic as optional ("if known"), so some records have no value. When it is missing, datePublished is the next best marker, with the caveat that it can be later than real disclosure.
Why it matters
Three different questions use three different dates.
- How long was this publicly known before we acted? Start from datePublic, or datePublished if that is absent.
- When did the list change? Use dateUpdated.
- How old is the ID? The year in a CVE ID reflects the ID process, not necessarily the year of discovery, so avoid reporting it as "found in 2026".
If a leadership report says "average time to fix, by CVE year", it measures ID age. Our post on advisory counts by publication year shows how such counts mislead.
Known data issues
The CVE Program's cvelistV5 repository documents past clean-ups. In September 2024 it corrected about 27,000 records published before 2023 that had incorrect reserved, published or updated dates. It also notes date discrepancies for about 515 records published by the MITRE CNA-LR between 8 May and 7 June 2024. A date normalization process ran from 16 to 28 February 2026. If you build metrics on dates, read the repository's known issues first and re-pull after clean-ups.
A rule you can put in a policy
- SLA clocks start at the vendor's patch or advisory date if you hold that evidence, otherwise at datePublic, otherwise at datePublished.
- Reports always name the date field used.
- Alerts on "updated" compare dateUpdated with the last seen value.
- Findings tied to a rejected ID are closed with the rejection date recorded.
This keeps two analysts from reporting different ages for the same finding.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning with policies and gates, so you can set a gate by severity or KEV status and record the date used for evidence. Run a free scan at gold.safeguard.sh/scan to see findings for your own project.
Quick check
Is the year in a CVE ID the year it was discovered?
Not reliably. The schema notes the reserved date does not necessarily show when the flaw was discovered or disclosed.
Which date shows public disclosure?
datePublic, when the CNA provided it.
What if datePublic is missing?
Fall back to datePublished and say so in your report.
Sources
- CVE Record Format JSON schema, fetched 19 October 2026.
- CVE Program, cvelistV5 repository README, fetched 19 October 2026.
Last reviewed: 19 October 2026.
