再保险:关于CVE作业oss-sec邮件列表

> - - - - - - - - - - - >从原始信息:耶利哥(mailto: jericho@attrition.org]>发送:周一,2015年11月30日下午4:49 >:威廉姆斯,肯< Ken.Williams@ca.com > > Cc: cve-editorial-board-list < cve-editorial-board-list@lists.mitre.org > >主题:RE:关于CVE作业oss-sec邮件列表>重要性:高> > >,2015年11月29日,威廉姆斯,肯写道:> >:[…]>:>如果CVE未能提供IDs在一些问题上,三个月后,我> >:>亲自游说我公司发布报告没有>任务,>:>,让它很清楚,因为CVE选择不>分配。>:>这是不公平的CVE成立协调披露过程>:>请求方和供应商不是必须的情况下自己。>给>:>,我建议CVE扩大CNA的身体,这>似乎>:>充耳不闻,没有理由横切。>:[…]>:>:A disclosure process should never be held up by a pending CVE > : assignment. Just go ahead and disclose and put "pending CVE assignment" > : on the CVE line. > > Except, that is problematic for issues like Apache Commons. CVE's delay in > assigning, or clearly saying how assignments would be handled (e.g. one ID > vs one ID per vendor vs one ID per product) led to serious confusion > already. IBM started using Oracle's assignment in advisories before CVE > finally replied to IBM PSIRT instructing them to use their own. But the > damage is done, even with IBM's own ID, some internal divisions are still > using Oracle's assignment a week later [1]. > > This highlights the importance of timely assignments and/or direction from > CVE to the CNAs. > > .b > > > [1]http://www - 01. ibm.com/support/docview.wss?uid=swg1jr54748不能和你争论,库尔特,帕斯卡,或艺术说。更及时CVE作业和响应是必要的,可行的。也就是说,CVE绝不应该披露的障碍,修补和安全性。我们需要解决方案的一部分,而不是创建新的问题。我非常想看到我们投入更多努力的系统提供了CVE漏洞标识符,而不是限制的范围只是一小部分最受欢迎的和广泛使用的软件。那么我们只需要担心如何扩大CVE客户支持组织应对巨大的积压未CVE标识审查/批准/整合门票。(不知道我开玩笑的对CS扩张)缺乏CVE覆盖第三方组件是一个很大的,每天为我存在的问题,所以我知道这是一个问题对于许多其他人。——千瓦