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

Re: CVE For Services

On 9/26/17 12:26 PM, Kurt Seifried wrote:


1) we for sure let service CNAs self assign (these are the mature ones 
obviously that will play nice in most cases I hope, in theory an evil 
company could become a CNA in order to quash any claims of CVEs in 
their services, but hopefully that doesn't happen)



2) we for sure assign CVEs if the claimant can prove their claim (e.g. "Do 
X/Y/Z and bad thing happens")


Agree with both of these, sufficient evidence of vulnerability exists 
(admission by vendor, PoC).

I'll note that testing live web sites in many jurisdictions, including 
the US, can be legally risky.


3) we consider CVEs where the claimant makes a claim but does not have 
strong evidence, we try to talk to the service provider, we see how 
that goes and depending on the evidence/etc. a CVE may or may not be 
assigned.


#2 is easier for product vulnerabilities.

#3 is a problem for product or service vulnerabilities where neither the vendor nor a third 
party can corroborate the claim.  While there's an argument to be made for "name all 
the things right away and later mark them disputed or rejected," CVE historically has 
taken an approach of "wait for the dust to settle then name whatever is left 
standing."  I don't see it as CVE's role to validate vulnerabilities, that is the job 
of (some) CNAs, vendors, researchers, and others.

I'm in favor of being able to assign CVE IDs to service 
vulnerabilities.  But I'd happily accept a cautious approach, generally 
not assigning for case #3.

There was discussion about a "this is a service vul" flag, is that 
still on the table?

Regards,

 - Art
Page Last Updated or Reviewed: September 29, 2017