CVE records for several CVEs that were transferred from one CNA to another are not up-to-date

[mprpic]

Note the discrepancy in the following example:

main!cvelistV5/cves/2024 > date
Fri Nov 22 02:16:28 PM EST 2024
main!cvelistV5/cves/2024 > git pull --rebase
Already up to date.
main!cvelistV5/cves/2024 > cat $(fd CVE-2024-48901) | jq .cveMetadata.assignerShortName
"redhat"
main!cvelistV5/cves/2024 > cve show CVE-2024-48901  # Uses cvelib to query CVE Services API
CVE-2024-48901
├─ State:	PUBLISHED
├─ Owning CNA:	fedora
└─ Updated on:	Mon Nov 18 16:01:21 2024 +0000

I did this shortly after a new snapshot was created in this repo (in Releases) so I feel like the transfer to a new CNA is somehow not being picked up by the automation here.

[M-nj]

I believe this is actually a symptom of cve-services and not an issue with the bulk download util code. The only way to get the current owning CNA is to hit the /cve-id endpoint (for CVE-2024-48901). The current bulk download util capabilities only communicates with the /cve endpoint (for CVE-2024-48901). To include the current owning CNA in the bulk download capability some new requirements will need to be put together.

[mprpic]

Mmm, right you are! @M-nj, would you mind transferring this issue to the cve-services repo then?

[jdaigneau5]

@mprpic So I don't think this is a bug, the changes are being picked, but as @M-nj mentioned, we don't show the owning_cna field in full CVE records, since it isn't part of the schema. We only show it when returning CVE-IDs. assignerShortName refers to who originally created the record, so that won't change. If you'd like, you could open a different ticket in the cve-services repo requesting owning_cna be added to the returned CVE record object. It at least warrants an AWG discussion.