摘要：根据最新的 开源安全和风险分析报告 (OSSRA)，所有被扫描的代码库中，有 97% 包含 开源组件，平均每个应用程序包含 900 多个此类组件。此外，近三分之二的组件是传递依赖项。这意味着它们是被间接引入的库，许多团队可能甚至没有意识到他们正在使用它们。

开源组件被广泛使用，但也带来了安全和合规风险。过时的组件和仓促的升级都会造成问题。除了升级之外，还可以考虑扩展支持等其他选择来应对这些挑战。

译自：The Hidden Costs of Rushing Open Source Upgrades

作者：Artem Karasev

根据最新的 开源安全和风险分析报告 (OSSRA)，所有被扫描的代码库中，有 97% 包含 开源组件，平均每个应用程序包含 900 多个此类组件。此外，近三分之二的组件是传递依赖项。这意味着它们是被间接引入的库，许多团队可能甚至没有意识到他们正在使用它们。

这种对开源的广泛依赖，每个开源组件都有其自己的支持策略和时间表，使组织面临超出安全漏洞的潜在风险。如果管理不当，这些风险可能会意外地以意想不到的规模浮出水面。理解这些风险是第一步，但持续有效地控制它们至关重要。

了解开源支持生命周期

与通常带有可预测的多年支持时间表的商业软件不同，开源支持 遵循不同的路径：

社区支持阶段： 大多数项目都始于维护者和贡献者驱动的积极开发。安全修复、新功能和更新会定期发布，但支持时间表的长度和一致性因项目而异。

可选的企业支持扩展： 当社区支持结束时，一些流行的项目会提供具有明确生命周期的付费企业支持扩展。这些可以为未来几年提供安全补丁和稳定性更新，但大多数项目不提供此扩展选项。

生命周期结束 (EOL)： 一旦所有支持结束，无论是小型项目的社区维护结束，还是大型项目的企业支持结束后，都不会再发布任何修复程序。此时，组织面临升级的压力——而且可能是在相当短的时间内。

此模型创建了一个支持时间表的拼凑。在典型的应用程序中，每个组件可能在不同的时钟上，这意味着某些库可能得到完全支持，而另一些库可能已经停止维护。对于注重 安全和合规性 的组织而言，这可能会导致几乎永无止境的麻烦。

过时和易受攻击组件的规模

虽然开源加速了创新，但保持组件的最新状态仍然是一个显而易见但尚未解决的挑战。2025 年 OSSRA 研究表明了这个问题是多么普遍：

86% 的代码库包含易受攻击的开源组件。

91% 使用过时的软件包，其中大多数落后于最新版本 10 个以上版本。

81% 包含高风险或 крити 的漏洞。

这些数字表明了当今问题的系统性程度。组织不仅仅是运行一些过时的库。他们正在运行数百个这样的库，通常没有意识到他们已经偏离最新支持版本有多远。

结果不仅是网络犯罪分子可以利用的安全漏洞，而且还是运营负担，因为团队试图管理堆栈中数百个不同开源组件的支持时间表。

EOL 和合规性风险

当从合规性的角度来看时，保持安全的压力变得更加严重。包括 FedRAMP、PCI DSS、HIPAA 和 ISO 27001 在内的强制性标准要求在严格的时间范围内修复漏洞，对于 критических 缺陷通常只有几天或几周的时间。但是，当组件已经达到其生命周期结束时，无法保证会提供补丁。

即使目前没有已知的漏洞，审核员通常会将 EOL 组件标记为合规性风险，因为它们无法可靠地进行修补。由于 EOL 状态通常在周期的后期才被发现，因此组织经常匆忙升级以避免审计结果或监管处罚，而这种仓促的行动可能会导致其他问题。

这些强制性标准适用于整个依赖链，不区分直接依赖项和传递依赖项。如果 EOL 组件出现在组织的 软件物料清单 (SBOM) 或扫描报告中，审核员通常会标记它们，因为它们代表无法修补的风险。如果供应链中的任何位置存在易受攻击的组件，无论多深，都需要解决。

与此同时，新一轮的法规针对的是不同的受众：设备和电器制造商。诸如 美国网络信任标志 和 欧盟网络弹性法案 等计划要求供应商为其硬件上运行的所有软件组件（包括开源依赖项）在整个产品生命周期内提供安全补丁。

换句话说，传统框架（PCI DSS、HIPAA、ISO 27001、FedRAMP）将责任置于软件运营商身上，而新兴法规（网络信任标志、网络弹性法案）将该责任上移至设备制造商。这是一个重要的新负担。无论哪种方式，不受支持或过时的开源软件包不再仅仅是技术责任；它们也可能成为显著的监管责任。

为什么升级永远不简单

即使仔细计划了升级，它们也很少是直接的。团队通常首先重写应用程序代码，以解决重大更改或更改的行为。从那里，他们必须更新依赖链以解决冲突并确保兼容性。

工具和基础设施通常也需要关注。构建系统、CI/CD 管道、打包、部署脚本甚至容器镜像通常需要调整以与新版本对齐。之后是测试。必须执行回归、集成、安全性和性能测试，以确保升级没有引入意外的副作用。

最后，团队必须处理变更管理流程（即，规划推出、准备回滚策略、更新文档并确保员工接受过新环境的培训）。在实践中，看起来像“只是一个升级”可能会波及代码、依赖项、工具、基础设施和流程，消耗大量时间和资源。

仓促升级的成本

合规性服务级别协议 (SLA) 和新的漏洞披露 经常与不受支持的组件发生冲突，使组织别无选择，只能匆忙升级。这种紧迫性通常会放大风险和成本。

仓促的升级可能会引发一波升级后事件，因为错误和紧急问题会在工程和运营中造成不稳定，使团队无法进行路线图工作并减慢交付速度。在截止日期压力下，团队也可能会偷工减料，而这些捷径通常会固化为持久的技术债务，只会堆积在未来的维护负担之上。

财务影响同样不容忽视。缩短的时间表转化为计划外成本，从加班费到临时基础设施、扩展的测试环境或紧急咨询。与此同时，草率的实施可能会无意中引入新的风险，例如配置错误或新的漏洞，最终会破坏升级旨在恢复的安全性。这真是一个困境。

因此，虽然在最佳情况下升级很困难，但仓促的升级可以将必要的维护活动转变为不稳定、成本和超支的来源。

除升级之外的选择

并非每个应用程序都可以或应该按照合规性截止日期或突然的漏洞披露所决定的时间表进行升级。业务优先级、集成复杂性和中断风险通常使“仅升级”成为不切实际的答案。

多年来，组织的选择有限。有时可以获得扩展支持，但通常仅适用于特定组件。堆栈的其余部分仍然未覆盖，使团队别无选择，只能在社区支持结束后加速升级。

今天，这种情况正在发生变化。新服务为操作系统、运行时、库、开发框架和应用程序中的各种开源组件提供扩展支持。通过提供持续的安全补丁以及兼容性保证、完整的依赖关系树覆盖和来源跟踪，组织可以在官方生命周期结束后很长时间内保持安全。这些功能有助于确保软件保持可审计性，同时还通过跨软件供应链的及时补救来继续保持严格的合规性。

来源：视线科技圈