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

Re: CVE for hosted services



Some thoughts based on today's board meeting.

I consider CVE's primary purpose as identification.  There's a good bit
of work that goes into just doing identification.  Information
sharing/publishing/cataloging takes work too.  Identification/naming is
infrastructural and enables many additional functions.

"Vulnerability" is often abstract and subjective.

Software and tech change quickly.  The definition/boundary of what "we"
"collectively" call vulnerabilities evolves.  The current discussion (1)
started around the idea of assigning CVE IDs to web/service
vulnerabilities, which I consider natural evolution.

Lots of discussion around the definition/boundary of "vulnerability."

Also a separable discussion (2) about the use of CVE IDs for
internal-only, non-public issue tracking.  Could an organization use CVE
to track vulnerabilities with no expectation of publishing or sharing?
Does an organization want to?

To try to narrow down the services discussion (1), I'll suggest:

It should be permitted to assign CVE IDs to common web application
vulnerabilities in specific sites/services (e.g., facebook.com the site,
not WordPress the product).  "Common web application vulnerabilities"
means things in OWASP/CWE like XSS, SQLi, CSRF.  Consider this a use 
case.

There is no requirement for any provider, vendor, or CNA to try to be
comprehensive.

Regards,

 - Art


Page Last Updated or Reviewed: February 22, 2017