At the 2023-12-14 TWG meeting, the discussion suggested that, during testing of the 5.1.0 schema, any CVE Record that validated even though the record format was not "intended" would be considered a "loophole."
It might not be intended that CVE Records use source.discovery in a different way than Vulnogram.
Vulnogram, by default, inserts "source": { "discovery": "UNKNOWN" } into a CVE Record.
minimal/plausible test case (the CNA chooses to specify a language for the word "UNKNOWN")
{"dataType":"CVE_RECORD","dataVersion":"5.1","cveMetadata":{"cveId":"CVE-2025-0001",
"assignerOrgId":"b3476cb9-2e3d-41a6-98d0-0f47421a65b6","state":"PUBLISHED"},
"containers":{"cna":{"providerMetadata":{"orgId":"b3476cb9-2e3d-41a6-98d0-0f47421a65b6"},
"affected":[{"vendor":"v","product":"p",
"versions":[{"version":"1","status":"affected"}],
"defaultStatus":"affected"}],
"source":{"discovery":{"lang":"en","value":"UNKNOWN"}},
"descriptions":[{"lang":"en","value":"d"}],"references":[{"url":"https://a.ai"}]}}}
This is similar to #212 but does not require an x_ field. A possible solution is to require source.discovery to have a string value (not allow an object), so that all CVE Records are structurally consistent with how Vulnogram uses the source.discovery field.
At the 2023-12-14 TWG meeting, the discussion suggested that, during testing of the 5.1.0 schema, any CVE Record that validated even though the record format was not "intended" would be considered a "loophole."
It might not be intended that CVE Records use source.discovery in a different way than Vulnogram.
Vulnogram, by default, inserts
"source": { "discovery": "UNKNOWN" }into a CVE Record.minimal/plausible test case (the CNA chooses to specify a language for the word "UNKNOWN")
This is similar to #212 but does not require an x_ field. A possible solution is to require source.discovery to have a string value (not allow an object), so that all CVE Records are structurally consistent with how Vulnogram uses the source.discovery field.