再保险:CVE托管服务

恐怕条目的描述,问题服务,比如facebook.com,将通常非常模糊,无法核实的。我很恼火现有条目,读起来像“问题X,但不同于cve - 1234 - 5678和cve - 1234 - 7890”。这个问题是什么?从这我们可以从中吸取什么教训?我们教不应该做什么,或者教做得更好吗?不知道。帕斯卡在结婚,2017-02-22在-0500年38,艺术·马尼恩写道:>一些想法基于今天的董事会会议。> >我认为CVE作为识别的主要目的。有很好的进入> >的工作只是做鉴定。信息>共享/出版/编目工作太。 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 >