Repository navigation
container examples incorrectly include providerMetadata #312
Description
cve-schema/schema/docs/cnaContainer-basic-example.json
Lines 3 to 5 in e23bb9e
cve-schema/schema/docs/cnaContainer-rejected-example.json
Lines 3 to 6 in e23bb9e
cve-schema/schema/docs/cnaContainer-advanced-example.json
Lines 3 to 5 in e23bb9e
The providerMetadata property should be deleted from these files because it is not needed when using CVE Services, and introduces a support cost because users do not immediately know whether to send the specific value of
00000000-0000-4000-9000-000000000000 or the UUID of their organization (or either or neither), and thus sometimes ask the CVE program for additional help.
Similarly, examples should not be inconsistent (shortName above is only in the rejected example, not in the other two).
As shown at https://cveawg.mitre.org/api-docs/#/CVE%20Record/cveCnaCreateSingle
Note: providerMetadata is set by the server. If provided, it will be overwritten.
The same note also occurs at https://cveawg.mitre.org/api-docs/#/CVE%20Record/cveCnaUpdateSingle and https://cveawg.mitre.org/api-docs/#/CVE%20Record/cveCnaCreateReject and https://cveawg.mitre.org/api-docs/#/CVE%20Record/cveCnaUpdateReject as well.
With this change, CNAs who study the examples will be ready to submit CVE Records as soon as they are able to compose and send a container. They will not need to guess that the 00000000-0000-4000-9000-000000000000 value is fine, will not need to make other API calls to look up their organization's UUID, and will not need to think about whether it is appropriate to send data that is documented as will be overwritten.
Activity
ccoffin commentedon Dec 30, 2024
If the providerMetadata property is removed from the example, this causes the example to be invalid against the schema since providerMetadata is a required property. If CNAs are creating their CVE Records and validating them using our schema, this would always result in validation errors on their side before submitting to CVE Services. I believe that our only options would be to document that CNAs provide this default value or their actual orgId in providerMetadata, or we could change the schema to NOT require providerMetadata. Seems like the latter option shouldn't matter since CVE Services is automatically adding the needed providerMetadata property and values, but i may be wrong and missing something.
ccoffin commentedon Jan 23, 2025
Discussed in 1/23/2025 QWG. General consensus seems to be that the schema should be considered an input schema for now. If someone wants to use the schema for output purposes, we may want to create a separate output schema at that time.
alilleybrinker commentedon Aug 15, 2025
This actually ties to some other discussions we've been having about how validating against the schema itself isn't enough. With the incoming PURL change (see #407), this will be even more true, but per this issue it's already true.
Further validates the value of providing a validation library that matches the validation CVE Services would do.