data suggests that new datePublic enforcement may have incompatibilities

[ElectricNroff]

It appears that multiple CNAs use the datePublic field for their own planned publication date, and schedule their use of CVE Services so that this is a close estimate of (but sometimes slightly later than) when the vulnerability was first entered into the CVE Services database. This may have occurred for hundreds of CVE Records, from dozens of CNAs, during 2023. However, because of the #1097 change, their CVE Services API calls will now fail. This may be disruptive to their business processes, and may be unexpected because it is not a backwards compatible change even though it is being introduced before CVE Services 3.0.0.

For example, CVE-2023-1298, a CVE Record from a vendor CNA about its own product, has:

"datePublished":"2023-07-06T17:13:27.552Z"
"datePublic":"2023-07-06T17:15:00.000Z"

This would not be accepted by the server now because it was submitted 92 seconds earlier than the datePublic value. From the perspective of a CNA, 2023-07-06T17:15:00.000Z may be the most correct of any possible date/time, because:

• the publishing process for their website made their vulnerability announcement public at 17:15:00
• at 17:15:00, a customer could become aware of the announcement because it showed up on a list of recent announcements, and the customer may also have been alerted by email at that time
• the vendor specifically wants the CVE Record to be available through the CVE website at 17:15:00, because their announcement links to the CVE Record URL on the CVE website, and they don't want this to be a broken link for their customers
• before 17:15:00, a customer could not see the vulnerability announcement on the vendor's website
• before 17:15:00, it is very unlikely that anyone would have seen the vulnerability announcement on the CVE website (the CVE Program doesn't have any push technology to immediately notify anyone about new CVE Records, and it's usually much more than 92 seconds before anyone would notice, through a GitHub update, that a new CVE Record was available through bulk download)

It is unclear how a CNA, who wishes to use the datePublic field, is supposed to work around this. Is the CNA supposed to notice the datePublic cannot be a future date error message and immediately revise their business process so that it lies about when a vulnerability became public?

For example, if they plan to publish the CVE Record at about 17:13, should they set datePublic to an arbitrary (but false) earlier value, such as 17:12 or even 17:00, to ensure that the API call succeeds? (They have no way to predict the exact time that the CVE Record will be stored in the CVE Services database and, depending on how their client works, may not exactly know the second or even the minute of when the API call occurs.) Are they instead supposed to leave datePublic as 17:15:00, and make their CVE Services API call after 17:15:00 (which means that their advisory will have a broken link to the CVE website, from the perspective of the customers who look earliest)?

The CVE program doesn't have any documentation describing how the affected CNAs are supposed to proactively prepare, when they want their own security advisory to be published at essentially the same time as the CVE Record. There are no examples of what timings succeed and what timings fail. Similarly, there is no documentation about what a CNA should do retroactively if they encounter the datePublic cannot be a future date error message.

For the CVE-2023-* CVE Records, there are 435 cases from 59 different CNAs in which the CNA-provided datePublic value is later than the datePublished value (which generally indicates when the CVE Record was received by the server). Some of these are artifacts of CNAs publishing through the GitHub pilot, but many are for CNAs publishing directly through the CVE Services API.

Some CNAs, when publishing a series of CVE Records, increment the datePublic value so that it it is accurate within minutes of the actual publication date, e.g.,

CVE ID|datePublic|datePublished|CNA
CVE-2023-41786|2023-11-23T14:30:00.000Z|2023-11-23T14:27:33.933Z|PandoraFMS
CVE-2023-41788|2023-11-23T14:35:00.000Z|2023-11-23T14:33:44.933Z|PandoraFMS
CVE-2023-41789|2023-11-23T14:40:00.000Z|2023-11-23T14:36:55.047Z|PandoraFMS
CVE-2023-41790|2023-11-23T14:40:00.000Z|2023-11-23T14:38:45.504Z|PandoraFMS
CVE-2023-41791|2023-11-23T14:45:00.000Z|2023-11-23T14:41:46.802Z|PandoraFMS
CVE-2023-41806|2023-11-23T14:50:00.000Z|2023-11-23T14:47:54.186Z|PandoraFMS
CVE-2023-41807|2023-11-23T14:50:00.000Z|2023-11-23T14:49:41.335Z|PandoraFMS
CVE-2023-41808|2023-11-23T14:55:00.000Z|2023-11-23T14:51:17.223Z|PandoraFMS
CVE-2023-41810|2023-11-23T15:00:00.000Z|2023-11-23T14:52:59.306Z|PandoraFMS
CVE-2023-41811|2023-11-23T15:00:00.000Z|2023-11-23T14:54:41.510Z|PandoraFMS
CVE-2023-41812|2023-11-23T15:00:00.000Z|2023-11-23T14:58:44.103Z|PandoraFMS
CVE-2023-4677|2023-11-23T14:30:00.000Z|2023-11-23T14:22:01.559Z|PandoraFMS

In any case, if the #1097 change is deployed to production, there may be as many as 50 CNAs who suddenly no longer have a complete working process for publishing CVE Records. This may lead to substantial frustration among CNAs and their constituents, cause important CVE Records to remain unpublished for a while as each CNA tries to debug the issue, and create a support burden for the Secretariat and others.

Possible alternatives include:

• ask developers of supported clients to warn about datePublic anomalies, and let the user elect to proceed or not
• choose the server behavior after asking CNAs what they prefer (e.g., if a planned publication date was 17:15:00, would any CNA's management actually care if their staff published 92 seconds early?)
• allow a time window in which datePublic can be later than when the CVE Record is submitted (e.g., one or more hours)
• tell CNAs that they are, in effect, required to initially publish their security advisories with a broken link
• have separate API endpoints for "strict datePublic processing" and "lenient dataPublic processing" - and announce that the latter will be discontinued according to a deprecation schedule
• publish a News article on the CVE website explaining that timing is now being enforced, and offering at least one recommended solution for affected CNAs
• have a presentation about the timing changes at VulnCon 2024
• directly contact every CNA who has ever submitted a CVE Record with a now-disallowed datePublic timing
• provide a way for a client to indicate that it wants the server to fill in the datePublic field (in effect, the CNA would be asserting that it was a prompt CVE Record publication; there was no realistic way to find out about the vulnerability before the CVE Record existed)
• release the update as CVE Services 3.0.0, in case that motivates more CNAs to test against the new server behavior

[jdaigneau5]

Dev Note: Need to determine appropriate grace period for datePublic time and actual publication time

[jdaigneau5]

AWG 4/30/24: Agreed on a 24hr grace period