automation-working-group
automation-working-group copied to clipboard
Do CVE Services write container dateUpdated? Should they?
Looking at CISA Vulnrichment ADP data, I obvserve that the ADP dateUpdated is different in CVE Services compared to the GitHub repository. IIUC CVE Services writes dateUpdated within CNA and ADP containers when the Record is posted. The Vulnrichment dateUpdated is written when analysis is saved, which is logically earlier than posting to CVE Services, although in practices this difference is often minutes or hours (or possibly over a day boundary).
adpOrgID=134c704f-9b21-4f2e-91b3-4a467353bcc0
$ curl -s https://raw.githubusercontent.com/cisagov/vulnrichment/master/2024/22xxx/CVE-2024-22165.json | jq -r ".containers.adp[].providerMetadata | select(.orgId==\"$adpOrgID\") | .dateUpdated"
2024-05-20T19:17:39.823Z
$ curl -s https://cveawg.mitre.org/api/cve/CVE-2024-22165 | jq -r ".containers.adp[].providerMetadata | select(.orgId==\"$adpOrgID\") | .dateUpdated"
2024-06-04T17:52:31.592Z
Not specific to Vulnrichment, should CVE Services be touching dateUpdated inside containers? There may be other CNAs or ADPs who update container information independently of (and logically before) posting to CVE Services. This sort of delay may be explicit/intentional and/or a byproduct of workflow and tooling. It seems to me that CVE Services should (and do) control the Record-level timestamps but should not modify timestamps inside containers.
A downside to this approach is that a CNA or ADP might not update the timestamp when making changes to the container. This could be helped by tooling. Also, the rule could (may already) be that CVE Services updates container timestamps upon submission if the container has changed.
To be clear, this is not a serious problem for Vulnrichment.
There are no material changes between CVE-2024-45744.a.json and CVE-2024-45744.b.json execpt for the timestamps written by CVE Services.
$ jq -r .cveMetadata.dateUpdated CVE-2024-45744.a.json
2025-02-28T20:45:05.623Z
$ jq -r .containers.cna.providerMetadata.dateUpdated CVE-2024-45744.a.json
2025-02-28T20:45:05.623Z
$ jq -r .cveMetadata.dateUpdated CVE-2024-45744.b.json
2025-03-11T17:50:17.447Z
$ jq -r .containers.cna.providerMetadata.dateUpdated CVE-2024-45744.b.json
2025-03-11T17:50:17.447Z
FWIW, for several months, documentation of this has been implemented via https://github.com/CVEProject/cve-services/blob/e779d564a1a437bc6e2db4eae109b96d02dc1e0b/src/controller/cve.controller/index.js#L939 and visible at https://cveawg.mitre.org/api-docs/#/CVE%20Record/cveAdpUpdateSingle "Note: providerMetadata is set by the server. If provided, it will be overwritten."
The behavior is required by text in the schema: https://github.com/CVEProject/cve-schema/blob/a29f28e5d48383cc5e179f9c6655ac49e8ffe1f9/schema/CVE_Record_Format.json#L481-L495
Part of the rationale for CVE Services to "modify timestamps inside containers" is that clients retrieving all CVE Records that have certain container changes (to maintain their own copy) via the API need a guarantee that a dateUpdated field is no earlier than the time of an actual update; otherwise, sequential API calls (with advancing cutoff timestamps) may miss some CVE Records: https://github.com/CVEProject/cve-services/blob/e779d564a1a437bc6e2db4eae109b96d02dc1e0b/src/controller/cve.controller/cve.controller.js#L272