再保险:指望cf

我的理解这个线程,肯特提出了三个主要的观点:-计数设置成员的CVE (count CVE)的人-技术限制的CVE名称(名称空间边界)-操作CVE计数过程中的资源的数量和质量(CVE进来如何)问题的关键在我看来是这样的:如果CVE的欲望是主要为每个漏洞和权威的参考在全球范围内,它肯定不是这样的资源和运营资源真正成功这一目标是未知的。除非有人可以辩称,否则,增长限制CVE数量多年来更多的与过程能力计算而不是扩张的计算。如果这种说法是正确的,我们至少有两个选择:选择一个地址操作所需的资源去解决市场计算这些项。总是会有一些宽容,因为这可能永远不会是完美的。一旦确定,一些商业模式必须到位来维持增长和质量。或选择B -创建一个更本体论模型,认为CVE不是主或者根而是另一块的元数据使用使具体化一些其他断言。作为一个供应商,我只能控制我所能控制,那是我自己的内部ID是组织上关闭自己的数据完整性。ncircle - id - 667 -has-CVE-ID - > CVE-xxxx-xxxx ncircle - id - 667 -has-CVE-v2-ID - > CVE-xxxx-xxxx-withextension-yyyy-for-future-format ncircle - id - 667 -has-Secunia-ID - > Unique-Secunia-ID ncircle - id - 667 -has-OSVDB-ID - > Unique-OSVDB-ID(对于那些认识我,我宁愿做一个标准的本体模型,任何供应商无论如何解决互操作或主标识符。互操作性的目标应该是计算句法或语义等价)叫我务实但这是我所做的一个例子,不要求别人。只是需要一个例子,CVE不是主要但inverse-functional-properties之一,可用于说这是一样的(计算等效)叫我老和疲惫,但我只是不明白为什么CVE运营团队获得成功所需的资源时没有人能支付的质量或数量他们的努力。 I mean this with the utmost respect for that team since I know most of the members personally and know the tireless hours they put in. "NOW GET OFF MY LAWN!" :-) --tk -----Original Message----- From: owner-cve-editorial-board-list@LISTS.MITRE.ORG [mailto: owner-cve-editorial-board-list@LISTS.MITRE.ORG马尼恩的艺术代表发送:周四,08年3月,2012年2:56点:博伊尔,斯蒂芬·v . Cc: cve-editorial-board-list主题:Re:指望2012-03-08 11:52 cf,博伊尔,斯蒂芬诉写道:>这可能听起来有点小题大作,但是“漏洞”>数很可能进入。我不是声称CVE保持> -肯特和其他人都有正确说明原因和历史>,适用,是的,人只是看着别人的生>数字(或其他无论是CVE)是要问困难的问题,>尤其是资金困难。> >已经说过,值得一提的,通过设计,总有cf >要少于有“漏洞”——它有点>的一个关键特性。JThere也是玩家在空间>超过几年前,每一个都有多个激励>发布比其他人更漏洞。> >,我并不是说没有问题,我们必须能够>回答诚实问题如肯特转发。但是我们也有注意>什么是真实的,什么计数问题存在于所有>脆弱性报告来源,并为CVE意味着什么。问题仍然是国际海事组织:1。适合CVE的抽象级别是什么?2。适合CVE完整性级别是什么? How narrowly do we define "vulnerability," the thing to name/count? Is there desire/need for an accurate count of vulnerabilities? OSVDB either abstracts a little more narrowly than CVE and/or collects more vulnerabilities, so OSVDB has higher numbers. If CVE or any other database were to try to name and count all publicly disclosed vulnerabilities, it would be important to be able to distinguish between a vulnerability that is one of a dozen XSS bugs in a PHP web app and a vulnerability that is a straight up stack buffer overflow in httpd. Sure, count them all, but be able to say that out of 20K vulnerabilities named this year, 61% were XSS or SQLi in web apps with low distribution. I'm guessing at some numbers in the above example, but this is a big reason IMO that CVE numbers have declined. Vulnerabilities "worth tracking with a CVE" have declined, not the total number of vulnerabilities. Another way to look at it might be that thee criteria for "worth tracking with a CVE" has changed. And we're not even talking about threat or asset values (both of which have changed over time, and are different depending on your site/assets), which influence risk. So a decrease in CVE IDs has little directly to do with internet risk overall. - Art