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

Re: CVE for hosted services

On 2017-02-22 16:19, jericho wrote:
> On Wed, 22 Feb 2017, Pascal Meunier wrote:
> 
> : I'm afraid that the description of the entries, for issues on 
> services 
> : like facebook.com, would be typically very vague and unverifiable.  
> I'm 
> : rather annoyed by existing entries that read like "a problem in X, 
> but 
> : different from CVE-1234-5678 and CVE-1234-7890".  What is the 
> issue? 
> : What lessons could be learned from this?  What should we teach not 
> to 
> : do, or teach to do better?  No idea.
> 
> Good point.
> 
> Also consider that such descriptions would almost never carry version 
> information and be based more on *approximate* dates. We often hear 
> Facebook "fixed a vuln" but days or weeks after it really happened. 
> Since 
> versions are a huge tool for determining potential duplicate issues, 
> without that would be painful.

Agreed, there's likely pain for cataloging purposes (de-duplication) and
low value for engineering purposes.  But the overriding factor for me is
*identification* (and yes, for ID to work, it has to be possible to
distinguish different vulnerabilities).

CVE throws light on vulnerabilities.  Probably weekly, without looking,
I come across issues that don't have CVE IDs assigned and therefore
aren't noticed by people who might benefit from knowing.  I make a note
to send in a minimum viable entry, but haven't yet.

Oh, services have CVEs?  Airplanes?  Dentist office software?  Oh, large
services freely admit they have vulnerabilities, and fix them?
Users/customers actually like such transparency?

Vulnerabilities are common and everywhere and aren't terribly special
individually.  Name them and go about your choice of defensive
activities, probably including vulnerability management.

 - Art
Page Last Updated or Reviewed: February 23, 2017