按产品查看CVE 报告的数量，我很想将其用作哪些程序最安全的指标，并相应地选择我安装的程序。
但我想知道这些数字是否具有误导性。例如，Linux 内核排在第二位，甚至没有提到 Windows 10。我想这部分是因为 Linux 的开源特性，这使得发现和修复缺陷变得更容易和更快，增加了 CVE 的数量。
我发现有趣的另一件事是，虽然 Chrome 在 2016 年列出的漏洞比 Firefox 多，但 Firefox 中的代码执行缺陷要多得多，而 Chrome 的很大一部分缺陷是 DoS 攻击，这些攻击不那么严重。
基于这些软件拥有的 CVE 数量，我们可以说一个软件比另一个“更安全”吗？
根据这些软件拥有的 CVE 数量，我们可以说一个软件比另一个“更安全”吗？
不可以。CVE条目不是根据“整体安全性”对产品进行排名的好来源。
CVE系统背后的主要思想是为软件漏洞创建唯一标识符。它并非旨在成为任何产品中所有已知漏洞的完整且经过验证的数据库。也就是说，供应商或研究人员可以简单地决定不为给定的缺陷请求 CVE 编号。此外，条目有时会在一个 ID 下组合相关的错误，或者不披露确切的影响，从而使简单的“错误计数”成为一个毫无意义的安全标准。此外，对于排名，您必须找到合理的指标来比较不同的严重性。（有多少 DoS 错误等于远程代码执行......？）
也就是说，CVE 确实可以让您了解在产品中发现了什么样的漏洞，并且它们是研究的良好起点。但数量很大程度上取决于软件的使用年限以及通过安全审计获得的关注程度。如果大量 CVE 分配意味着软件编写不佳，或者它实际上意味着它特别安全，因为显然很多漏洞正在得到修复，你无法真正推理。如果旧产品的修补漏洞记录非常短，我个人倾向于认为这是可疑的，因为这可能表明它没有经过彻底的审计。
因此，您应该将 CVE 视为一本字典，而不是一个简单地为漏洞分配句柄以便您可以更轻松地引用它们的数据库——不要将其用作比较安全性的工具。
以下是安全产品的一些更好的指标：
作为一个自愿系统，CVE 与它跟踪的软件产品一样容易被滥用，并且通常具有高度主观性。用于跟踪严重性的评分机制（通常是 CVSSv2）在某种程度上使情况更加复杂。
在理想情况下，当在产品中发现漏洞时，开发人员将注册一个 CVE，然后将其与他们为产品生成的任何修复程序一起发布。
然而，正如其他人所指出的那样，有时 CVE 只是没有创建，或者开发人员会利用一堆漏洞，削减一个修复所有漏洞的版本并在随附的 CVE 上创建。
如果我对使用某个软件产品感兴趣并且对它的安全性有所保留，我更有可能看看他们如何处理安全问题、接收报告等，而不是专门查看他们的 CVE 数据库。
上述的一个例外是使用其他组件的软件产品，在这些情况下，看看一个产品需要多长时间才能赶上针对其组成产品/服务发布的 CVE 可能会很有启发性。重新打包开源组件的商业软件通常会在安全修复方面滞后数月。这可能是我利用 CVE 数据库做的最有用的事情。
CVE 仅代表人们正在积极尝试利用的应用程序中的错误。虽然开源可能会或可能不会受到更多或更少的 CVE 的影响，但可以合理地假设它并不意味着任何应用程序或多或少容易受到利用。考虑到许多漏洞利用/漏洞通常在被视为 CVE 条目之前作为 0day 出售。还要考虑到开源社区中的许多人更倾向于合理的披露而不是利润。在任何情况下，我都会根据几个指标来衡量两个应用程序的漏洞：
CVE 的数量：正如您所暗示的，更多的 CVE 可能意味着应用程序被安全研究更频繁地审计。
开源：我个人认为开源“通常”更安全。自己查看源代码，看看编码风格。也许你可以自己找到一个漏洞。
可能有一点点，但是计数和质量之间的关系是复杂的，如果有意义的话。关于 CVE 计数及其对软件安全/质量的影响的有用问题是：
它是否有任何 CVE？如果不是，那可能意味着没有人足够关心寻找其中的安全漏洞（即相关性低，质量不高）。
它是否年复一年地为相同类型的错误重复 CVE？如果是这样，这意味着开发人员/维护人员可能最多只做修复特定错误所需的最低限度的工作，而不是修复他们的整个代码库并修复导致错误的过程。
发现的 CVE 是否与同一年份的其他类似项目的 CVE 相当，它们在发现的年份是否合理？例如，对于用于 Web 应用程序的大多数语言，任何 SQL 注入错误的存在都表明正在使用完全错误/向后的 API/框架（即没有准备好的语句的旧 API/框架）。对于 C 程序，虽然这很难判断；CVE 摘要不太可能告诉您错误是微妙的（因此“合理”地出现）还是来自做一些愚蠢的事情并且与现代做法相反。
等等。这些问题中的大多数不仅仅取决于简单的计数（尽管有些问题可能被建模为“各种类中的计数”），所以我怀疑计数是否有很大的价值。