再保险:CVE托管服务

我承诺在服务调用来描述一个用例。这里有一些分支:一个受欢迎的服务/网站有漏洞一段时间。这个漏洞创造了一个接触为用户/消费者服务的网站。用户/消费者想回去确定他们已经因为这个暴露的影响。为了做到这一点,他们需要一个日期范围的描述问题(即服务的哪一部分是脆弱),潜在影响他们(用户)和潜在的(或实际的)。虽然有利于如果服务提供者有所有这些信息,他们可能不会,现在需要有一个长期存在的标识符来协调不同利益相关者之间的讨论(我也认为只是服务提供者和客户之间的沟通是足够的标识符的原因)。我同意收集这些信息并不容易,但我不认为这并不意味着是不可取的。最低限度,我认为这个用例演示了一个标识符的必要性。或许一旦证明这些信息是重要的,那么它会被更为常规的被跟踪和可用。希望我不要太遥远。 -----Original Message----- From: owner-cve-editorial-board-list@lists.mitre.org [mailto: owner-cve-editorial-board-list@lists.mitre.org马尼恩的艺术代表发送:周三,2月22日,2017年4:39点:耶利哥< jericho@attrition.org >;帕默< pmeunier@cerias.purdue.edu > Cc: cve-editorial-board-list < cve-editorial-board-list@LISTS.MITRE。ORG >主题:Re: CVE托管服务2017-02-22 16:19,耶利哥写道:结婚>,2017年2月22日,帕斯卡贝写道:> >:恐怕条目的描述,对问题> >服务:像facebook.com,将通常非常模糊,无法核实的。>我>:对现有条目,读起来像“问题X > >:不同于cve - 1234 - 5678和cve - 1234 - 7890”。>问题是什么?>:这可以从中学习到什么?我们不教> >:应该做些什么,或者教做得更好吗?不知道。> >好点。> >还认为,这样的描述几乎从不携带>版本信息,基于*近似*日期。 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