Consider how to handle updates from CNAs

[zmanion]

Summary

How should CNA updates to CVE Records be handled, specifically updates made after enrichment?

Motivation and context

The current process does not add enriched data (e.g., CVSS, CWE, CPE) if that data is already provided by the CNA. But this sequence could occur:

1. CNA publishes CVE Record, without (for example) CVSS
2. CISA triages and choosed to enrich the Record, adding CVSS
3. CNA updates CVE Record with CVSS

The CISA CVSS (2.) and CNA CVSS (3.) may not agree. Also, consumers may not readily understand the reason for any discrepancy.

Implementation notes

The CVE Record Format timeline element could be used to record events, conveying to consumers that the CNA update happened after enrichment. Another option could be to remove CISA-provided enriched data after the CNA provides it.

[joshbressers]

Please don't remove existing data. If the data provided by CISA suddenly vanishes, consumers of that data have to decide how to handle such an event. I guarantee everyone will handle it differently which creates confusion for the end users of the data

It would make the most sense to add annotations (via timeline probably, I don't see a better way to do that). Annotations let us understand why something may have changed, when, and by who. When data disappears it's hard to know if it's on purpose or a mistake

[zmanion]

Another time-related consideration: The containers have timestamps, so does the SSVC metric. So even without creating a changelog-like timeline, a consumer could determine that the CNA container (potentially containing new CVSS or other enrichment) is newer than the CISA ADP container.

Edit: Noting that CVE Records datePublished and dateUpdated fields, containers have a dateUpdated field, this can also indicate when a CNA updates a container later than CISA updates an ADP container.

[todb-cisa]

Thanks for the input, @joshbressers. First off, great point about preserving history and the reluctance to lose insight.

I am worried about having (accidental, post-facto) conflicting values for things like CWE and CVSS specifically (and to a lesser extent, CPE) persisting forever in the ADP record, because it seems like, as described, this would create confusion along the lines of, "CISA said they're not going to argue with CNA-supplied metrics, why did they in this case?" Yes, people can see the timeline of events, and see that the originating CNA didn't provide these metrics at the time of scoring, but I don't trust that downstream consumers would parse the data in a way that obviously resolved the discrepancy.

We want CNAs to provide this data, and I don't want to accidentally punish them for providing it after the fact by injecting this kind of confusion or apparent disagreement.

The especially industrious could look at this GitHub repo for history if we were to just straight delete the CISA-provided metrics, but that's not a great solution for day-to-day operations, if history is valuable to be preserved.

Incidentally, there's already an expectation that ADPs (and CNAs) can edit (and remove!) their fields, at any time, and that history currently isn't preserved at all. CNAs routinely update descriptions, for example, and it's similarly difficult (but not impossible) to see what the old description was. From that perspective, removing CWE/CVSS/CPE metrics is a pretty normal way to treat these records, rightly or wrongly.

[todb-cisa]

After observing how the CNA ecosystem works today, and the expectations of CISA's ADP program in particular, the CISA ADP will remove enrichment if the originating CNA provides the missing data points. This conforms with expectations around published CVE entries today. We will have the capability of backing out changes, of course, but as far as published CVE entries go, we're going to avoid giving conflicting information.

We expect that turnaround time of such an update to be pretty quick, since updated CVEs will enter back into the queue for analysis as a matter of course.