最近，有关软件漏洞对风险的影响的讨论一直在不断发展。听取了许多声音后，我对红帽多年以来的观点更加坚定：并非所有的软件漏洞都是重要的，也并非所有的漏洞都是平等的。安全领域的许多行业领袖一直在说这个问题，并且这些声音变得越来越响亮，越来越难以忽视。更重要的是，当我与客户交谈时，这个信息开始产生共鸣。原因很简单：

鉴于每年发现的漏洞数量，传统的漏洞管理已经无法满足需求。

去年我曾经提到这个问题：是否所有漏洞都同等重要？通过数据和证据，观察2021年产品安全风险报告，可以很明显地看出，并非所有漏洞都会被利用。同样的趋势在最近发布的2022年产品安全风险报告中也得到了证实。根据Kenna安全公司的“数字：2022年CVE数据回顾”，虽然CVE数量从2021年到2022年同比增长了25%，但仅有略超过4%的已发布漏洞对组织构成真正风险。这个数据与我们自己的数据一致。2022年产品安全风险报告显示，所有发现的漏洞中，只有0.4%的漏洞被利用，这比2021年有了显著下降。实际上，在1086个中等严重性漏洞中，只有2个被利用。

尽管讨论仍在持续，漏洞风险的这种看法并非新出现的。事实上，20年前在我未加入红帽公司时，一些Linux发行版就发表了一份关于GNU/Linux安全的联合声明，该声明有着相似的主题。

CVE，即通用漏洞枚举，是一种漏洞命名约定。它是一个出色的系统，可以让用户、供应商和研究人员使用相同的名称引用相同的缺陷。但这就是它的全部——一种命名和跟踪漏洞的机制。CVE本身并不是风险指标。

同时，CVSS（通用漏洞评分系统）是一种用于优先处理漏洞的评估方法。CVSS基于三个度量标准：基本度量、临时度量和环境度量。它就像三条腿的凳子一样，需要所有三个度量标准才能发挥作用。大多数供应商只提供基本度量，这是漏洞不可变特征的客观视图。这里所说的“不可变”是指受影响的软件是如何构建的，不同供应商的软件构建是不同的。

接下来，我将更详细地介绍这个问题。临时度量可以通过良好的威胁情报程序或提供的信息源来提供，因为它描述了漏洞的当前利用情况。环境度量实际上只能由软件部署者提供，因为它取决于部署的环境。供应商无法知道您是在生产环境、开发环境还是测试环境中使用他们的软件。在不同的环境中，漏洞的风险可能存在差异。此外，数字或实体产品中使用的软件组件也可能不同。一个组件在一个产品中包含的功能可能与在另一个产品中不同。因此，像红帽这样的供应商将根据每个产品的不同用途对其进行评分。

在漏洞的不可变特性方面，我们必须认识到不同供应商构建软件的方式是不同的，尤其是在开源领域。例如，一家供应商可能使用C编译器（例如gcc）并启用堆栈保护或位置无关可执行文件（PIE），而另一家供应商可能不会这样做。如果您在启用堆栈保护的软件中发现缓冲区溢出漏洞，则原本可能导致任意代码执行的漏洞可能会变成拒绝服务漏洞。尽管仍然是漏洞，但根据软件的功能，其影响可能会非常严重。但是，它的影响只在于服务是否可用，而不是攻击者是否可以提权、窃取信息或进一步侵入网络。换句话说，通过启用编译器特性的简单差异，漏洞的特性可能会发生改变。

实际上，这意味着任何供应商提供的CVSS基础指标都应该优先考虑，而非CVE聚合器。比如美国NIST运营的漏洞数据库（NVD），虽然很棒，但它的实用性有限，因为它只考虑广泛适用和最坏情况下的CVE。这也意味着，即使启用了堆栈保护，NVD也会像未启用一样表示CVE，这可能不适用于您正在运行的软件。如果讨论的软件供应商没有提供CVSS基础指标，那么可以使用NVD提供的指标。但将NVD的CVSS分数优先于供应商提供的相同指标是不合理的，就像在申报税款时更喜欢数学老师的税务建议而不是会计师的建议一样。另外，值得一提的是，流行的curl开源工具的作者Daniel Stenberg最近严厉批评了NVD对CVSS的使用。

为了提供更精确的漏洞度量标准，红帽多年来一直在我们的CVE页面上公布CVSS Base指标。我们理解NVD面对的挑战，必须提供关于使用多个操作系统、以不同方式构建、在多个场景下使用的软件的数据。相比之下，作为软件的构建者，红帽了解软件的构建方式、设计用途，有时甚至精准地预测其可能的使用方式。基于我们对软件的认识，我们能够提供更准确的漏洞度量标准，以便在处理漏洞时给予优先考虑。当然，最终用户有责任提供时间和环境度量标准，以获得真实的分数，这是CVSS的使用方式。

这些基础知识告诉您漏洞存在的事实，影响评级以及最终用户安全团队可以使用的CVSS度量标准来辅助风险计算。但是更大的问题是风险本身 - 如果不能修复某些问题，那么将面临什么样的风险？尽管许多组织和机构正在努力降低行业风险，但实现这些效益仍需要很长时间。其中一部分原因在于产品生命周期 - 在许多情况下，今天发布的软件可预期将在未来5到10年内使用，尤其是针对企业设计的软件。即使明天创造出新的软件，也可能要数年后才能部署。

企业用户今天可以采用哪些策略来弥补风险？首先，需要了解软件漏洞。这意味着了解什么是CVE，什么不是CVE，如何使用CVSS，如何不应该使用CVSS，并且了解CVE聚合器的局限性。

这是一个了解供应商及其可信程度的过程。从实用角度来看，如果你信任供应商提供的用于运营业务的软件，那么你应该相信他们对漏洞的评估，并将其与他们的记录相匹配。举个例子，如果供应商一直告诉你他们很“安全”，但他们的软件仍然存在无法解决的漏洞，那么供应商的可信度就不确定了。相反地，如果供应商诚实地评估软件，根据新信息进行调整，积极预防高概率被利用的漏洞，并快速解决低概率但目前正在被利用的漏洞，那么这个供应商也许就赢得了信任。

顺便提一下，几年前有一家供应商的邮件系统被攻击了。他们迅速、清晰、透明地指出了问题，并迅速解决了它。我记得与一位同事的对话，他想抛弃这家供应商，因为安全问题很严重（确实如此），尽管他们已经透明并快速解决了问题。我的回应是，不，这正是我们想要看到的供应商行为！透明和快速响应事件正是建立信任的关键。也许我是安全悲观主义者，但我不确定是否应该相信那些声称自己的软件从未发生过安全事件或漏洞的供应商。对我来说，供应商如何应对安全事件是其可信程度的一个关键指标。

将所有这些部分综合起来，可以让安全团队构建方案来应对风险，但这只是个开始。最近发表的一篇文章《并非所有CVE漏洞都相等》（All CVEs Are Not Created Equal）指出，不同行业中相同的漏洞也可能产生不同的风险。安全团队在评估风险时应考虑这些差异。云服务中的漏洞与内部部署的漏洞不同，就像桌面端的漏洞与车辆中的漏洞不同一样。考虑风险时，环境绝对会对其产生影响。

更进一步让问题变得复杂的是，开源软件可能是应用程序中的任何数量依赖项之一，但是存在于这些依赖项中的漏洞可能不会暴露给应用程序，正如Contrast Security在2021年应用程序安全可观测性报告中所强调的那样。漏洞可能存在，但完全不可达，因此合法用户或恶意攻击者利用漏洞的风险几乎不存在。这意味着在补丁方面花费的任何努力都是毫无意义和浪费的。因此，在评估漏洞时，我们必须考虑特定组件在包含它的任何应用程序中的使用方式。

总的来说，风险是人、过程和技术的综合问题，但大多数人往往只关注技术方面，而对人和过程关注不够。使用终止生命周期的产品并不是技术问题，而是过程问题。每个季度应用补丁的选择是一个过程问题。渴望修复所有已知漏洞，即使只有4%会带来风险，实际上是一个非常昂贵的人的问题。顺便说一下，这也是一个有缺陷的愿望，对开源产生了不成比例的影响，因为在没有访问源代码的专有软件提供的幕后的掩盖漏洞时，开源的透明性被强调得不够。然而，开源在漏洞管理方面最好而又鲜为人知的好处之一是，你可以减轻你所知道的但没有修复方案的漏洞。

最终，风险的讨论和随后的决策必须由每个消费者自己评估。没有一种适用于所有人的方法，而且由于存在大量漏洞，修复所有漏洞是不切实际的。这是一种非常昂贵的消除风险的方式，这个代价由供应商和消费者共同承担。作为人类，我们一直在做出适当的风险评估——选择在新餐馆用餐、在杂货店购买牛奶，甚至决定开车去那家杂货店。

这些简单行动所带来的好处，每个行动都包括多次风险计算，超过了待在家里（或者吃无味食物）的安全感。我们每天都毫不犹豫地采取这些行动。管理软件漏洞也是如此。每个漏洞都必须被考虑，通常最低风险的做法是不去管它——虽然我们没有深入讨论这一点，但值得注意的是，每次更新新软件包或更改软件时都存在风险。

补丁带来的意外影响风险是否值得冒险？升级到更高版本可能会引入尚未知晓的新漏洞的风险又如何？尽管红帽通过后移技术（backporting）尽可能减小这种风险，但并未完全消除。修补一千个中度未被利用的漏洞，承担多少风险是很少被考虑的。

归根结底，我们都在平衡风险的同时创造价值，因为风险永远无法完全消除。