Remove the description from the required information for an entry submission

[EvansJonathan]

GOAL: Streamline the CVE Entry creation process.
CHANGE: Should "Description" be excluded from the required fields in Appendix B?
OUTCOME: CNAs and requesters will be able to assign CVE IDs with the least necessary effort.

[kurtseifried]

description should not be required if the requester has all the info (name/version/vuln type, impact, etc.) but it's also "nice to have" as there is often weird info that can be included but does not lend itself to a structured format (e.g. "this affects systems only on leap years").

[EvansJonathan]

@kurtseifried are you saying that you are okay with not requiring a description if the submitter supplies the minimum required information (currently product, version, and problem type), or do they have to provide more information?

[EvansJonathan]

Several of the formats we publish the CVE List in require a description (http://cve.mitre.org/data/downloads/index.html). We will have to figure out what to do with them if we are no longer requiring a description.

So for example if the submitter supplies all the data that would be needed to automatically generate a description, e.g. in the JSON format if they provide:

Vendor, product, affected version, fixed version, impact, vuln type, affected component

or like many of my open source cases they provide a code patch that fixes the issue which can be very obvious (e.g. adding htmlspecialchars() wrapper in a php program).

[chandanbn]

Currently JSON and CPE do not have a way to drill down further down into components such as a modules, affected function calls, features, affected hardware platforms, serial numbers etc., Until JSON is fixed to allow inclusion of such information, truthful descriptions can not be automatically generated from data else where in JSON.

Even if we can automatically generate descriptions, I would suggest to keep it as a required field.
Otherwise every consumer of JSON who needs a summary description of a CVE would have to implement a description generator. Generated text can diverge between different implementations, which can be confusing to readers.

Yes and no. You can add a description container today to have all that and more info. We can also add containers easily, e.g. we have:

Affected
Vendor
Product

And we can easily add something like

Component

I suspect features is already covered by the configuration container I had proposed a long time ago, serial numbers would go in affected under product simply.

[dadinolfi]

From Art Manion:
Require DESCRIPTION. I don't think the other fields are (yet) careful enough about capturing "all" the necessary information.
Make IMPACT optional, it is very dependent on context and can be optionally covered in DESCRIPTION.

We can't do that until we update the JSON standard, and then ideally shift it to "include the data, from which a description is created 99% of the time".