深度｜2024依赖性管理状态报告

Endor Labs 最近发布了《 2024 依赖性管理状态报告 》，这是该组织第三次发布年度报告。从之前的情况来看，该报告在开源、漏洞管理和软件供应链安全方面都有独到的见解，本期也不例外。

下面，让我们来看看一些重要发现和启示。

给不熟悉的人科普下：“依赖”通常是指为实现软件功能所使用的外部代码和库，而“依赖性管理”就是对这些依赖进行有效的管理。近年来，随着开源软件的使用量激增，以及针对开源软件生态系统和广泛使用的第三方依赖的软件供应链攻击的广泛存在，这个话题的重要性日益凸显。

报告首先讨论了开源/第三方依赖在现代软件开发中发挥的重要作用——包括其估计可节省 8.8 万亿美元研发成本（数据来源于哈佛大学的报告 ）。

然而，尽管组织广泛采用和使用开源依赖，但大多数组织在识别其使用的依赖、了解与之相关的漏洞，并有效确定漏洞修复优先级时仍然非常稚嫩，以至于让开发人员疲于奔命。

这是个问题，因为软件供应链攻击（包括开源攻击）正在 大规模 兴起。正如Sonatype 在其《软件供应链状况》报告中提到的，具体如下图所示：

我们知道，现代漏洞管理需要上下文。

采取传统方法（如 CVSS 等简单方法）的团队会陷入困境，往往要利用稀缺的时间和资源来修复那些不知道是否会被利用、不太可能被利用以及由于不可达而无法利用的漏洞。

其上下文来自 CISA 已知漏洞 (KEV) 、 漏洞挖掘预测评分系统 (EPSS) 和可达性分析等资源。

这些因素与资产关键性、数据敏感性和互联网暴露面等业务背景相结合，确实有助于明确漏洞管理的钱该花在哪。

报告指出， 少于 9.5% 的漏洞可在函数级别被利用，而将漏洞可达性和 EPSS 结合起来可在漏洞管理方面减少98% 的噪声。

然而，即使获得了这些数据，修复也并非总是那么简单，因为1/4的大版本更新有可能会包含破坏性更改，而小版本更新可能会在94% 的时间里破坏客户端、Patch也可能有75%的中断几率。

应用安全团队面临的另一个挑战是：漏洞数据库生态非常混乱。

我曾在《NVD的死穴》等文章中介绍过这个问题，我在文章中解释了NIST国家漏洞数据库（NVD）在2024年初是如何基本摇摇欲坠的，他们到现在也还没有恢复，这仍是他们要面临的挑战。成千上万的漏洞缺乏对通用平台枚举 (CPE) 等数据的分析与丰富，而这些数据是将 CVE 与特定产品联系起来所必需的。

目前，NVD 在 2024 年 2 月至 9 月期间有超过 18,000 个未丰富的 CVE，而自 2024 年 6 月以来，每月新增 CVE 的数据丰富率不到 50%，甚至在 2024 年 2 月至 5 月期间都没有触及任何一个 CVE。

这个问题也不可能在短期内改变，正如漏洞研究员Jerry Gamblin如下演示的那样，目前NVD 的 CVE 数量2023-2024 年均增长 30%、因此，奋力追赶 也就不足为奇了。

《依赖性管理状态报告》进一步突出了公共漏洞数据库存在的问题。

他们强调，从一个公共可用补丁发布，到公共漏洞数据库（如 NVD）中发布相关的公告，其间大约需要 25 天的时间。

即便如此，也只有 2% 的公告中写明了具体哪个库的哪个函数会导致改漏洞，甚至有25% 的公告中包含了不正确或不完整的数据，这就使漏洞管理工作变得更加复杂。

NVD 等数据库发布安全建议的延迟给企业带来了挑战。

正如我在文章"Vulnerability Exploitation in the Wild（漏洞在野利用）"中所讨论的那样，有时 CVE 在概念验证 (PoC) 发布 22 分钟后就会出现主动漏洞利用尝试。

根据 Endor Labs 报告的记录，69% 安全公告的延迟时间为 25 天，即从安全问题发布到公共漏洞数据库收录平均需要25天。

从漏洞利用可能发生的时间，到安全扫描工具（依赖于公共漏洞数据库）能扫到该漏洞的时间，这就存在时间滞后。加上组织为了解决这些漏洞所需的时间，这又是另一个因素。

事实上，根据近期Cyentia Institute的Wade Baker分享的数据，漏洞修复总体的平均时间为 212 天，在某些情况下甚至更长。

数学不好的人也很容易理解——漏洞利用可能在数分钟内发生，而相应的修复方案却在数月内完成，这其中存在着阻抗失衡 。

这进一步促使人们认识到，需要对漏洞进行有效的优先级排序和修复，尽可能使其在漏洞利用发生前，并将重点放在真正重要的风险上。

即使是 GitHub GHSA（另一个广泛使用的漏洞数据库）也存在报告中提到的问题，例如25% 的漏洞既有 CVE 也有 GHSA，而GHSA通常在 CVE 发布 10 天或更长时间后才发布，这使得组织在试图确定其技术栈的哪些部分受到开源组件中特定漏洞的影响时，存在 CPE 映射的gap。

下图反映了在发现漏洞、提供修补程序、发布安全版本和版本说明，并将其纳入公共建议等方面所面临的时间挑战。

时间拖得越久，受漏洞影响的组织面临的风险就越大，加之上面提到的冗长的修复时间。

Endor Labs的报告还基于以前的研究发现了延迟现象，如下所示：

NVD的另一个挑战是缺乏对PackageURL（PURL）的本地支持，作为CVE中的一个标识符，这样就可以将漏洞与特定的开源包/库联系起来，使分析结果和数据与开源漏洞相关性更高，但报告中并没有提到这一点。在 SBOM 论坛的一篇题为《关于实施漏洞管理的组件识别建议》的文章中，作为 NVD 的一个基本缺陷，对此进行了详细的记录和讨论。

Endor Labs 的报告证实了这一点，该报告在六个不同的生态系统中发现了这一点。47%公共漏洞数据库中的建议根本不包含 任何 代码级漏洞信息、只有51% 包含一个或多个与漏洞修复相关的引用，最后只有2% 包含受影响函数的信息。

这表明，大多数被广泛使用的漏洞数据库的细粒度都有所缺乏，对于漏洞相关的代码级信息往往一笔带过，缺乏现代软件供应链安全所需的细粒度。

尽管 NVD 面临这些挑战，但它仍然是使用最广泛的漏洞数据库。当然，其他数据库的地位也有所提高，如 OSV 或 GitHub 的 GHSA，但它们的使用规模仍不及 NVD。

这就导致客户和组织不得不查询多个不同漏洞数据库，并合理化这些信息输入，因为这些数据库的内容通常会冲突或重复。这些信息还需要与组织特定的漏洞信息（如业务关键性、数据敏感性、互联网暴露面等）以及漏洞情报（如已知利用或利用概率）相结合，才具备可用性。

报告讨论的另一个关键问题——幽灵依赖，即依赖存在于应用程序的代码搜索路径中，但未在特定的清单文件（如Manifest、pom等文件）中声明，从而导致影子依赖风险，容易被应用安全团队忽视。组织可以通过分析代码搜索路径中的直接和传递依赖以及创建依赖图来降低此类风险。

识别漏洞和浏览漏洞数据库只是问题的一部分，真正的工作在于修复那些影响系统和软件的已识别漏洞。

除了常规的带宽挑战以及和开发团队battle漏洞优先级之外，漏洞管理还面临着修复方面的挑战，例如修改和更新可能会影响功能或导致业务中断。

Endor Labs的报告中提到，在将一些最常用的库换成无漏洞的版本时，发生破坏性更改的几率如下：

• 大版本更新 - 100%
• 小版本更新 - 94%
• 补丁 - 75%

这表明，当团队希望换成无漏洞的版本时，更新往往会遇到破坏性的更改。

与此类似，我在题为"Open Source Security Landscape 2024" 的文章中深入研究了 Synopsys 的开源安全和风险分析报告 (OSSRA)，其中发现 96% 的代码库包含开源软件，整个代码库中77% 的代码源自开源软件、84% 代码库中包含易有漏洞的开源组件，参与评估的代码库中的组件91% 落后 10 个版本 甚至更多。

这意味着开源代码不仅普遍存在漏洞和过时的组件，而且在寻求更新这些组件时，大多数组件都可能包含破坏性的更改，正如 Endor Labs 报告中提到的那样。以下是 Endor Labs 报告中的可视化结果，显示最近的非漏洞更新在绝大多数情况下都会包含破坏性更改。

Endor Labs《依赖性管理状态报告》的其余部分继续讨论了 SCA 在依赖性管理方面的作用。SCA 工具并不新鲜，它们主要关注通用漏洞评分系统（CVSS）的严重性评分，这也说得通，这也帮大多数组织确定了漏洞修复的优先级，尤其是 CVSS 的“高危”和“严重”级别漏洞。

从漏洞预测评分系统（EPSS） 来看，只有不到 5% 的 CVE 被在野利用。基于此，组织根据 CVSS 评分来确定优先级会导致滥用本就稀缺资源来修复那些永远不会被利用、实际上并无风险的漏洞。

虽然包括 SCA 在内的扫描工具已开始越来越多地集成更多的漏洞情报，如 CISA KEV、EPSS 等，但有些工具尚未这样做。此外，大多数工具还没有将这些情报与函数级可达性相结合，而仅仅显示哪些组件存在漏洞：

• 已知被利用
• 可能被利用
• 实际可达

Endor Labs的报告强调了这一点：

只有不到 9.5%的漏洞可在函数层面被利用

这意味着，如果不将上述指标结合起来，组织会浪费大量时间来修复几乎不构成实际风险的漏洞。

我觉得他们不会这么做，正如我在 “Sitting on a Haystack of Digital Needles” 等文章中提到，大多数组织的漏洞积压量在数十万到数百万之间。

再加上安全人员用冗长的表格来“殴打”开发人员。这些表格充斥垃圾噪声，几乎没有实际上下文背景，也与降低风险无关——这就是灾难的根源。同时也解释了为什么大多数组织的应用安全都是垃圾堆。

尽管安全行业可以把 "基于安全设计 "的鼓敲得震天响，并试图让企业充分重视安全问题，但现实情况是，我们最好的选择是让企业关注那些真正重要的风险。

事实上，Endor Labs的报告发现将可达性和 EPSS 相结合的组织可将噪声降低98% 。

在这个利益纷争的世界里，企业理所当然地将重点放在了快速面市、功能特性、收入等业务优先事项上，因此不要让开发人员浪费时间，而是专注于那2% 真正能给企业带来风险的漏洞才是关键。

向“漏洞降噪”的转变，为打破安全和开发人员之间长期存在的挑战提供了机会，帮助安全成为真正的业务推动者，但最好优先考虑资源，为数字生态系统的安全性赋能。

强烈建议大家阅读报告全文 。

原文链接：

https://www.resilientcyber.io/p/state-of-dependency-management-2024

https://www.endorlabs.com/learn/announcing-the-2024-dependency-management-report

https://cdn.prod.website-files.com/6574c9e538a34feac8cec013/66e1f1961c537136315c2ffd_2024%20Dependency%20Management%20Report.pdf