containers.cna.source.defect has multiple data types

[jayjacobs]

The data in the field "containers.cna.source.defect" is stored in multiple different data types.

I will include a list of data types (with CVE counts): and a few samples here:

• list of str (2606): CVE-2019-0040, CVE-2020-1666, CVE-2021-31998, CVE-2022-42786, CVE-2023-24502
• list of list (2179): CVE-2021-1300, CVE-2020-3362, CVE-2018-0453, CVE-2019-12624, CVE-2020-3236
• list of length 0 (2): CVE-2021-32692, CVE-2022-3569
• str (17): CVE-2023-41705, CVE-2023-41703, CVE-2024-23187, CVE-2024-23191, CVE-2023-29052

I would suggest that we fix the data as it is stored and see if we can't add something in the schema to more strictly validate this field.

[sei-vsarvepalli]

Related to #339

The "source" section has no schema definitions at all. It is open-ended object perhaps? I am not sure if JSON schema actually is valid with an object that has no "properties" at all defined.

[ccoffin]

Looks like the "list of str" is most common and also what Vulnogram appears to define. The "list of list" seems like a mistake and is interesting given how many times you counted it. The examples you provided are all Cisco CVE Records. Do you recall or can you still check the data to see if it's only their records? Are they still provided in this way?

[jayjacobs]

Just to be clear, this is specifically about the "defect" value under the "source" distinction.

The CVE record should not have any "put whatever" data section in it because it's incredibly unfriendly to machine interpretation. To that end, it's probably best to define the whole "source" object, which would clean this up as well.

[jayjacobs]

and related to issue #48