3.6 全球安全数据库

尽管 CVE 计划得到了广泛采用，但许多人指出该计划存在问题，其方法以及无法跟上动态技术格局。随着云计算的兴起，云安全联盟 (CSA；https://cloudsecurityalliance.org) 等组织已成为现代云驱动 IT 时代指导和研究的知名行业领导者。CSA 的显著努力之一是创建全球安全数据库 (GSD)，它将自己描绘成解决现代问题的现代方法，声称 CVE 是一种过时的方法，没有跟上现代复杂的 IT 格局。这项工作由 Josh Bressers 和 Kurt Seifried 牵头，他们在 Red Hat 都拥有丰富的漏洞识别和治理经验和专业知识，而 Kurt 甚至还在 CVE 董事会任职。

在 CSA 博客文章《我们为何创建全球安全数据库》（https://cloudsecurityalliance.org/blog/2022/02/22/why-we-created-the-global-security-database）中，Kurt 列举了创建 GSD 的几个原因，以及 CVE 等其他计划未能达到预期的原因。该博客追溯了漏洞识别的起源，早于 CVE 的 BugTraq ID 计划，该计划要求相关方订阅并阅读可用的漏洞信息。他描述了 CVE 计划的发展，最初每年只有一千个左右的发现，在 2011 年开始下降之前达到 8,000 个 CVE 的峰值。正如我们之前讨论的那样，本文还展示了 CNA 的增长。然而，尽管 CNA 数量增长，但 Kurt 指出，近 25% 的 CNA 至少一年没有活动。 2017 年，发布和分配的 CVE 数量达到峰值，除了 2020 年的激增外，CVE 分配活动一直保持平稳，如图 3.3 所示。

本文介绍了 Josh 和 Kurt 参与的早期工作，例如分布式弱点归档项目，并讨论了 Linux 内核如何参与这项工作。Linux 项目拒绝与 CVE 计划合作，Greg Kroah-Hartman 在题为“2019 年内核配方 — CVE 已死，CVE 万岁！” (www.youtube.com/watch?app=desktop&v=HeeoTE9jLjM) 的演讲中对此进行了详细讨论。在该视频中，Greg 指出，由于应用和反向移植给用户的修复程序数量众多，CVE 计划与 Linux 内核配合不佳。Greg 解释了 Linux CVE 的平均“修复请求”时间线为 100 天，表明对 Linux 内核 CVE 缺乏关注，从更广泛的层面来看，Linux 项目的进展速度太快，无法适应严格管理的 CVE 流程。

GSD 公告描述了服务如何“吞噬世界”，现代软件和应用程序绝大多数都是以服务形式提供的，鉴于云计算以各种模式激增，这一点很难反驳，但最明显的是软件即服务 (SaaS) 等应用程序。作者解释了 CVE 计划在涵盖即服务应用程序方面缺乏连贯的方法。“吞噬世界”的评论是指之前的口头禅，即软件已经吞噬世界，但现在世界上许多软件都是以服务形式提供的。

在作者和GSD领导引用的其他变化中，还有像Python（20万）或NPM（130万）等软件包的迅猛增长。还有一种观点认为，CVE项目缺乏透明度、社区访问、参与度，并且缺乏与使用OSS软件包的供应商相关的数据，例如Log4j。

如果您有兴趣参与开放且由社区驱动的 GSD 工作，您可以在 GSD 主页 (https://globalsecuritydatabase.org) 或 Slack 或邮件列表 (https://groups.google.com/a/groups.cloudsecurityalliance.org/g/gsd?pli=1) 等通信渠道上了解更多信息。