Frequent Non-Substantive lastModifiedDate Only Commits Clog CVE Record History

[jgamblin]

I've been reviewing the commit history for several CVE records and noticed that a significant number of recent updates appear to be non-substantive, exclusively updating the cve.metadata.lastModifiedDate field without any actual changes to the record's content (such as the description, references, CVSS data, etc.).

---

The Impact

• This large proportion of timestamp-only commits clogs the commit history.
• It makes it difficult for consumers and reviewers to quickly identify and track actual, meaningful updates to the CVE record. Reviewing the list for substantive changes requires diffing nearly every single commit.

---

Specific Example

The commit history for cves/2023/4xxx/CVE-2023-4255.json clearly illustrates this issue, showing many commits where only the timestamp changes: CVE-2023-4255 Commit History

---

Proposed Discussion/Suggestion

Is there a mechanism or policy that could be implemented to prevent timestamp-only updates from creating a new commit?

Possible approaches might include:

• Excluding the lastModifiedDate field from being considered a "change" that warrants a new commit, if no other field has been altered.
• Batching or coalescing these timestamp updates, or only updating the timestamp when other substantive data changes are made.

Any clarification on the automation or process that leads to these frequent, timestamp-only commits would be appreciated.

[M-nj]

If I remember cve-services correctly, that field is set by the cve-services system when a user does an update to the CNA container via https://cveawg.mitre.org/api-docs/#/CVE%20Record/cveUpdateSingle. Its possible the owning CNA has an automated tool that is pushing values that have the same CNA container values (or they are making changes and reverting before the delta gets picked up). For CVE-2023-4255, this is most likely what is happening as RedHat owns many CVEs.

I would personally recommend NOT changing how it works as it brings in additional factors and headaches that need to be included when checking the validity of this repo against the cve-services database.

[darakian]

I would personally recommend NOT changing how it works as it brings in additional factors and headaches that need to be included when checking the validity of this repo against the cve-services database.

Can you say more on that? What headaches would need to be resolved?

[zmanion]

Adapted from a Slack thread:

Whenever the PUT /cve/{id}/cna endpoint is called, it will update the dateUpdated field, even if the submitted cnaContainer is the same as what's already in the Record.

Not sure how difficult it would be but I'm in favor of not touching dates if there are no actual updates. I didn't go read the API docs, would it be necessary to compare field-by-field? Are there cases where someone wants or uses the touch capability?