再保险:CVE托管服务

莫尼耶3/3/17 32点,帕斯卡写道:> > >请不要让CVE成一个事件或咨询数据库> > >因为一个ID会很方便。> >正如布赖恩指出的那样,创建另一个C * E项目如果希望> > > >跟踪这些问题在托管解决方案。我没有强烈的反对一个单独的ID。>谢谢。有趣的CVE >是智能识别和确定根源。广泛的问题>源于缺乏安全目标或考虑,如>产品,只需要一个顾问。我觉得使用CVE ID >这个例子是不恰当的,因为CVE意味着>更精细和更精确的工具。这个例子是类似于一个大崩溃>从猖獗的无能;没有详细分析和>无关但得到它在Facebook上愤愤不平。但是我有不同的想法。 CVE may have had a stronger engineering use (defect/root cause identification), but times have changes. An ID -- particularly one that lots of people know and share -- is not only handy, but critical. The ID is separate from the engineering value of the vulnerability, we're in a world now where we still have to be able to talk about the service vulnerability in big_social_media_site, even if the world never hears the engineering details. We even have to be able to talk about the nth lame XSS in some CMS. It's just one more instance of a known class of CWE, but we need to identify *it*. We also have to identify lame vulnerabilities in stupid consumer IoT gear. Because that junk is where computers live these days. "CloudPets left their database exposed publicly to the web without so much as a password to protect it." Now this specific issue, harder to say. It's an insecure configuration, which I don't think is in scope for CVE (product, service, or otherwise). Does "E is for Exposures" come into play here? MongoDB (or memcached) should get CVE IDs for insecure default configurations. - Art PS, I won't be on this week's board call.