再保险(CD): CD建议:SF-LOC(软件缺陷在不同的行代码)

比尔Fithen说:> > * 4)如果P1和P2不固定同样的补丁或补丁,> >之后,他们必须保持分裂。> >我觉得这个规则不适合CVE的目的……供应商>包软件根据其业务规则,不是>根据软件的技术内容……>最下面的这一个重点是>脆弱性的性质和相关的软件工程实践>。这个规则不是。我同意这个规则是比以前更少的精确和可靠的。然而,虽然在过去一年试图应用SF-LOC和SF-EXEC而发展CVE,有* *许多情况下,没有人的软件供应商可以回答这个问题是否有同样的错误。这个问题是加剧了很多软件没有附带的源代码,可以分析和缺乏细节对我们来说是一个重要的瓶颈在创建和评估候选人。因此一些其他规则试图缺乏信息的处理。卡斯珀Dik和大卫·勒布朗已经有效地强化了供应商在真正理解问题的重要性。 See the voting records on CAN-2000-0317 and CAN-1999-0818, for example:http://cve.mitre.org/cgi - bin/cvename.cgi?can - 2000 - 0317http://cve.mitre.org/cgi - bin/cvename.cgi?can - 1999 - 0818例如,报告可以- 1999 - 0818是一个问题在原始kcms_configure以及安全焦点和X-Force漏洞数据库,但卡斯珀表示,这真是一个图书馆的问题。(这不是关键的数据库当然,和描述写的明白这一点,但是他们却忽略的细节可能是有用的”深入分析“需要* *真正理解问题的本质)。我们不能得到这种程度的参与(和诚实?)从每个供应商。自从我开始在CMEX记录供应商承认,几乎一半的活跃的候选人甚至没有任何具体供应商的确认。我们都知道,一些厂商发布非常稀疏的报告没有细节。所以这些规则,而远离看着错误本身,是为了找到“证据”,将帮助我们做出合理解释(和可重复的)决定在没有良好的事实。说,这一事实补丁实现不同可能需要至少一个重新排序的“证据”的规则。——史蒂夫