开源悖论：剖析风险、公平性与接受度

开源领域向来充满矛盾：它由满怀热忱的开发人员倾力打造，其软件免费提供给大众使用，但却由全球一些大型企业将其商业化运作并提供资金支持。它曾被视为“行业毒瘤”，饱受质疑，如今却成为一股推动创新与技术进步的强大动力，其影响力前所未有。在开源的世界里，悖论将始终存在，而在对安全漏洞的理解上，这种悖论体现得尤为明显。

25 年前，为规范软件缺陷的命名与追踪工作，通用漏洞披露（CVE）计划应运而生。在那个常常难以明确识别特定漏洞的时代，sendmail 之类的常用软件存在诸多问题却难以厘清，而 CVE 的出现为这一领域带来了清晰性与条理性。虽然 Security Focus 和 Bugtraq 等早期平台已开展相关工作，但 MITRE 推出的 CVE 提供了一个亟需的全球性体系。1999 年，即 CVE 计划实施的第一年，便有 894 个漏洞编入目录，这一数据即便在如今看来数量相对较少，却足以凸显出早期对漏洞进行统一识别的迫切需求。了解这一历史背景，对于理解我们当下在 CVE 方面面临的挑战至关重要。

在此期间，软件漏洞的格局发生了翻天覆地的变化。在实施该计划的前六年里，随着采用范围的扩大，分配的 CVE 编号数量激增了 450% 以上。此后，这一增长态势呈指数级攀升，到 2017 年，CVE 编号数量已近 15,000 个，在短短两年间增幅达 125%。到 2023 年，这一数字再度跃升 50%，突破 29,000 个。这一爆发式增长凸显了三个关键趋势：软件复杂性持续攀升、软件可用性不断提高，以及采用 CVE 体系的供应商数量与日俱增。

漏洞态势持续急剧演变，规模不断扩大。2024 年，已分配的 CVE 编号数量激增 39%，突破 40,000 个，这在一定程度上得益于 Linux 内核获得了 CVE 编号机构（CNA）的资质。如果移动应用开发或游戏开发等其他软件领域也开始正式追踪 CVE，这一增长趋势或将大幅加快。如此庞大的漏洞数量，迫使我们必须对当前的漏洞管理策略进行深刻反思与重新评估。

“修补所有漏洞”的策略难以为继

我们始终认为，长期以来奉行的“修补所有漏洞”原则在环境相对简单的时代或许尚能应对，但在当今复杂的环境中却难以为继，且缺乏战略合理性。这种做法缺乏真正的风险评估。并非所有漏洞都需要立即投入大量资源进行修复。漏洞的可利用性和潜在影响等因素至关重要。对发现的每个漏洞采取无差别修补，就如同对良性肿瘤和恶性肿瘤都建议采用激进的手术治疗，这既忽视了实际的威胁程度，也忽略了修复措施本身所固有的风险。

确定修复优先顺序的关键指标是漏洞的实际利用情况。基于网络安全和基础设施安全局（CISA）的 “已知被利用漏洞（KEV）目录” 等信息来源进行数据分析后发现，漏洞的被利用率一直极低，从历史数据来看，每年被利用率远低于 0.5%。这意味着大约每 200 个漏洞中仅有 1 个会被积极利用并转化为攻击手段。了解到这一点，我们应当专注于更务实、以风险为导向的方法。

我们的关注重点必须转向最有可能被利用且可能引发重大损害的漏洞，通常是允许远程进行未经身份验证的访问，并具备高权限提升能力的“严重”或“重要”级别漏洞。通过将修复工作集中于这些高风险/高影响的漏洞，我们能够利用现有资源最大限度地降低风险。这必然意味着，要战略性地接受那些不太可能被利用、或者即便被利用也不会造成实质性影响的漏洞所带来的较低残余风险，这类漏洞大多属于“低”或“中等”严重级别的问题。 

有效的风险管理并非要消除所有漏洞，而是要优先处理确实构成威胁的漏洞，并审慎接受可控范围内的其他风险。

这与开源有什么关系？

对未修复漏洞的担忧往往集中在开源领域，这主要源于其透明特性。开源代码及其 CVE 均公开可见。相比之下，专有供应商通常不会披露他们认为不值得修复的低影响漏洞，这就形成了一个风险盲区。在开源软件中，一个微小漏洞会生成公开的 CVE，而在专有软件中，类似问题可能不予报告、得不到修复，或者被悄悄修补。

这种可见性差异催生了双重标准。要求“无已知漏洞”的策略本质上是针对开源软件的透明性，而非其必然存在更高风险。至关重要的是，您的企业组织已经默许日常使用的专有软件中存在未披露的轻微漏洞的风险。真正的风险管理需要正视这一事实。我们必须对所有软件进行一致、明确的风险评估，重点关注漏洞被利用的可能性和影响程度，而非因开源软件固有的透明性而对其加以苛责。

要实现漏洞管理领域的真正公平，我们需要认识到开源软件的独特之处：其设计本身具备极高的透明性（这无疑是件好事！），而这也会让它看起来存在更多漏洞。对于开源软件，我们需要明确接纳在使用专有软件时已默认承受的风险。

有一些有趣的数据可以佐证这一点。将红帽以及我们 2024 年风险报告中的数据，与一家知名大型专有软件供应商的数据进行对比，能得出一些非常有意思的见解，这些见解也证实了上述假设。除非该专有软件供应商仅具有重大影响的漏洞（即：容易被利用），否则我们本应看到“严重”和“重要”级别问题与“中”和“低”级别问题的分布情况大致相似。换句话说，除非他们造成的安全漏洞总是后果严重、危害极大且性质恶劣，否则我们本应会看到更多影响较小的安全漏洞。但数据显示，低严重级别问题的数量几乎可以忽略不计。值得一提的是，该供应商采用与红帽相同的四级严重性等级。

漏洞报告指标可能会呈现出一幅具有误导性的图景。开源项目以透明方式报告的低严重程度 CVE 数量较多（2024 年，红帽报告的漏洞中，92% 为中低严重程度），而这家专有软件供应商报告的这一数量较少（2024 年，仅有 5.5% 的漏洞被评为中低严重程度），这并不能真实反映相对风险，而是主要体现了两者截然不同的漏洞披露理念。

与其纠结于漏洞数量或严重等级，不如聚焦于关键因素：实际被利用情况。2024 年，在影响红帽软件的 4200 多个开源漏洞中，已知在现实环境中被任何平台利用过的仅占 0.26%（即 11 个）。若仅依据漏洞数量来划分优先级，会导致大量资源耗费在几乎不构成实际威胁的问题上。

无论是专有软件供应商还是开源软件供应商，本质上都会优先修复最为关键的问题。关键区别往往在于对未修复的低影响漏洞的透明度。既然我们早已默许闭源软件带来的这种残余风险，现在也应当将这种务实、以风险为导向的方法明确应用于所有软件，包括开源软件。从理念上讲，我们的目标是一致的：修复重要的问题，降低无关紧要问题的优先级。

作为安全领域的领导者，我们认为应当引导安全计划摆脱单纯统计漏洞数量的模式；倡导一种以可利用性情报和潜在业务影响为核心的策略；实施一套严谨的流程，优先处理最有可能被恶意利用的威胁，并营造一种理解并理性接受可控残余风险的企业文化。将资源集中用于缓解那些真正危及企业组织安全的威胁。

如果您想更深入地探讨这一议题，可以观看我去年在 OpenSSF 的 SOSS/Fusion 大会上围绕该主题发表的演讲，当时使用的是 2023 年的数据；而在本次 2025 年 VulnCon 2025 大会上，我又结合 2024 年的数据更新了演讲内容。