RE: clarification / statement on recent CVE abstraction policy changes and more

[jericho <jericho@attrition.org>]

On Mon, 6 Mar 2017, Coffin, Chris wrote:

: changes were previously discussed with the CVE Board. Also note that 
: these examples include a description that was written by the 
requester 
: and submitted via the CVE web form. Using requester-provided 
: descriptions is one part of our overall strategy to scale the CVE 
: program.

I think the CVE entry should have a way to flag it as such, so that 
consumers know this was not written by MITRE and may not meet MITRE's 
historical standards. That would be a simple addition to the process, a 
check box essentially, and way to visually flag it.

: > The first issue is just odd, and seems like someone was in a hurry, 
: > but this is problematic to sites using CVE data to generate stats, 
as 
: > the product names potentially don't match prior entries
: 
: While these examples are generally not the norm, MITRE has not 
attempted 
: to normalize product names. We have always expected those who build 
on 

And yet, MITRE has done a good job normalizing products in descriptions 
historically. =)

: > I also noticed that whoever made these recent entries didn't 
include the obvious fixing commits that were referenced in the bug 
tickets. 
: 
: MITRE's policy does not require including the fixing commits, even 
: though we have done so in previous cases. Also, if another reference 
can 
: be easily found via one already included then we may skip the former.

Policy maybe not, but given the excessively detailed replies to some 
issues on oss-sec in the past, and digging into the commit to the tune 
of 
30 minutes of coding/vuln analysis becomes quite the contrast to 
"didn't 
link the fixing commit that was in the bug entry linked".

: > An apparent change in abstraction rule where five IDs were assigned 
: > for XSS issues that previously would have received one ID (e.g.
: > CVE-2017-6487, CVE-2017-6488, CVE-2017-6489, CVE-2017-6490, and
: > CVE-2017-6491)
: 
: In this case the requester provided separate reports that appeared to 
be 
: independently fixable. The change to split by independently fixable 
: vulnerabilities rather than vulnerability type was enacted with the 
new 
: CNA Rules.

Interesting, thanks.

.b