CWE Validation Library - timestamp

[ccoffin]

Purpose:

This will be one of multiple discussions to query the QWG and others on how best to use the upcoming CVE Services Validation Library for performing additional or more accurate CVE Record Format JSON schema validation during record ingest. The Validation Library will allow the CVE Program to perform programmatic validations beyond what the current JSON schema validation can provide. A simple example might be where we want to validate that a provided CWE ID actually exists by referencing the current CWE List. This is not possible using JSON schema validation, but would be possible with the Validation Library.

Discussion:

The timestamp definition is used by multiple properties within the CVE Record Format JSON schema and includes a pattern match to validate proper timestamp syntax. The properties that use the timestamp definition are:

• cveMetadata/datePublished (published and rejected records)
• cveMetadata/dateUpdated (published and rejected records)
• cveMetadata/dateReserved (published and rejected records)
• cveMetadata/dateRejected (only rejected records)
• providerMetadata/dateUpdated (cna and adp)
• dateAssigned (only cna)
• datePublic (cna and adp)
• timeline/time (cna and adp)

The timestamp pattern match allows for a timestamp with or without a time zone offset, and with or without fractions of a second. The following examples are valid timestamps based on the current pattern match.

• 2026-01-02T15:31:10
• 2026-03-04T15:31:10Z
• 2026-05-06T15:31:10+10:00
• 2026-07-08T15:31:10-06:00
• 2026-09-10T15:31:10.1
• 2026-09-10T15:31:10.20
• 2026-09-10T15:31:10.300
• 2026-05-06T15:31:10.400+10:00
• 2026-05-06T15:31:10.500Z (CVE Services format)
• 2026-03-25T20:06:40.255817Z

Note that on ingest CVE Services converts all timestamps to UTC based on the time zone provided. If a time zone is not provided, UTC is assumed. CVE Services also adds milliseconds if they were not provided. An example of the format used by CVE Services is captured in the second-to-last example above.

Schema Location(s):

https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L91
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L429
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L438
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L442
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L480
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L484
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L488
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L498
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L517
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L613
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L617
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L729
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L1105

Question(s):

• Can we use the Validation Library to improve the quality and accuracy of the data provided by CNAs within the properties that use the timestamp definition?
• Can the proposed validation be implemented using only the Validation library, or could it also be accomplished using the JSON schema?
• Should the rather large pattern match be moved out of the JSON schema and into the Validation library?
• Should we remain flexible with time zone and allow with or without, and assume UTC if not provided?
• Should we remain flexible with subseconds and not require it?
• Could the validation library be used to identify non-schema defined timestamps and validate syntax? For example, timestamps provided by CNAs or ADPs in objects that allow additional properties.
• Should we limit time zone offset values to the current maximum world range, i.e., UTC−12:00 to UTC+14:00?
• Should we limit time zone offset values to 23:00 or less (schema currently allows 99:00, CVE Services allows up to 23:00)?

Examples:

• Fail when datePublic is a date in the future (Validation Library only) (previously validated by CVE Services)
• Fail when dateAssigned is a date in the future (Validation Library only)
• Warn when dateAssigned is a later date than datePublic. There may be legitimate cases, but this could be something to warn about. (Validation Library only)
• Fail (or Warn) when the dateAssigned date does not fall somewhere between the dateReserved date and datePublished date. (Validation Library only)
• Warn when any timestamp uses a time zone offset beyond the current maximum world range, i.e., UTC−12:00 to UTC+14:00. (Validation Library only)

[ccoffin]

An earlier RFD was defined in #475.