[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Required information for CVE entry submissions

CNA can assign CVE internally and would only submit the required 
information after it's been made public. 
The intention is not to provide all these details ahead of your public 


Beverly M Finch, PMP
PSIRT Program Manager
Product Security Office

7001 Development Drive
Office 3N-C1
Morrisville, NC  27560

+1 919 294 5873

Twitter | Facebook | Instagram | Blogs | Forums

-----Original Message-----
From: owner-cve-editorial-board-list@lists.mitre.org 
[mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of 
Pascal Meunier
Sent: Wednesday, September 20, 2017 11:29 AM
To: Adinolfi, Daniel R; cve-editorial-board-list
Subject: Re: Required information for CVE entry submissions

In ref to REFERENCES, URLs, this is problematic because we'd like CVEs 
to be used in all public information.  Or at least, it's my position 
that this would be the ideal case.  That requires creating a CVE before 
it's made public.  Requiring public information to create a CVE makes 
this impossible.

Likewise, PUBLICATION DATE is problematic because we'd like to be able 
to assign CVEs before publication.  If it's not known for sure then 
you'd have to accept an estimate, which may be incorrect and never get 
corrected.  If a future date is estimated it should be identified as 
such, e.g., by containing something like (ETP, Estimated Time of

Likewise, Issue #26 "The CVE List cannot be the first point of 
publication for any information" should be rejected as long as 
provenance is identified.  Referencing a CVE in a publication is not as 
useful if the matching CVE record isn't available.  Alternatively, 
enforcing that rule by doing simultaneous publication would require 
close coordination for little benefit, all around this rule seems more 
trouble than it's worth.

For DESCRIPTION I vehemently disagree with the assertion that "all the 
same information would be available in the required fields".  The 
required information is insufficient to distinguish separate instances 
of similar flaws in different sections of the code, which could result 
in a bunch of CVEs "similar to CVE-wxyz but different", especially if 
discovered at different times -- there would be no basis on which to 
differentiate between the CVEs, and to identify the actual code flaws. 
 Please keep DESCRIPTION required.

I would like to suggest an additional optional but strongly desired 
fields that would identify source code location areas that enable the 
flaw, or commit IDs for any bug fixes. 


On Wed, 2017-09-13 at 15:15 +0000, Adinolfi, Daniel R wrote:
> Folks,
> I wanted to summarize the proposed changes to the CNA Rules that 
> affect what information will be required when submitting a request to 
> populate a CVE entry in the CVE List. In other words, what should the 
> required minimal CVE entry request look like? I want to make sure the 
> community finds these useful and minimally sufficient.
> None of these are set in stone, yet, so any feedback is appreciated.
> Currently, the CNA Rules require:
> PRODUCT, including vendor/project
> VERSION, describing what versions are and are not affected 
> PROBLEMTYPE, a free-form bit of data, though some use CWEs here 
> REFERENCES, URLs pointing to public information about the 
> vulnerability that includes all the information that may be in the 
> CVE 
> entry DESCRIPTION, a human-readable description of the vulnerability
> The related JSON minimum schema is here:
> <https://github.com/CVEProject/automation-working-group/blob/master/c
> ve_json_schema/CVE_JSON_4.0_min.schema>
> and it has a few extra bits of meta-information for those using JSON.
> To summarize the proposed changes, the following information would be 
> required under the proposals:
> PUBLICATION DATE (of the vulnerability information becoming public; 
> or 
> a timeline of specific events related to the vulnerability being made 
> public) ASSIGNING CNA (or chain of assigning CNAs if there is a 
> Sub-CNA under a Root doing the assignment) IMPACT
> There is also a proposal to remove REFERENCES from required 
> information if all the required information can be included in the 
> description. There is a related discussion as to whether the CVE List 
> can include vulnerability information not found anywhere else, acting 
> as a first publication point. <https://github.com/CVEProject/docs/iss
> ues/26>
> DESCRIPTION would also become optional, the argument being that all 
> the same information would be available in the required fields.
> We do not currently have a proposed categorization or taxonomy of 
> Note, as one can see in the full JSON v4 description <https://github.
> com/CVEProject/automation-working-
> group/blob/master/cve_json_schema/DRAFT-JSON-file-format-v4.md>,
> there is a lot more information that one can submit to CVE, and that 
> information can be submitted whether or not it is included in a 
> required field, so this minimum does not limit what can be included 
> optionally. Also, individual CNAs can choose to make additional 
> fields 
> required if they wish. But if a CVE request is submitted with only 
> the 
> required fields, it will be accepted and considered "complete".
> We are working on the CNA Rules revision for another two and a half 
> weeks. I hope to have this key set of changes finalized by then.
> Please take a moment to consider these and let us know if you believe 
> it will work or not. Though it would be useful, you don't need to 
> discuss the formatting or content of these fields. Right now, I want 
> to focus on only if the information is required or not.
> Thanks.
> -Dan
> _________________________
> Daniel Adinolfi, CISSP
> Lead Cybersecurity Engineer, The MITRE Corporation CVE Numbering 
> Authority (CNA) Coordinator
> Email: <dadinolfi@mitre.org>  Phone: 781-271-5774

Page Last Updated or Reviewed: September 20, 2017