量化无支持开源软件的真实风险

企业开源中的生命周期盲点

开源技术的广泛采用从根本上重塑了企业软件的交付模式。根据新思科技（Synopsys）发布的《2024年开源安全与风险分析（OSSRA）报告》，96%的受审计代码库中包含开源组件，而且在许多情况下，应用程序中超过70%的代码都是开源的。

‍

然而，人们较少了解的是，这些组件如何随着时间的推移得到维护——以及当上游项目不再提供支持时，由谁来承担责任。尽管开源社区具备创新速度快、协作能力强的优势，但其组织结构并不能提供长期维护保障。个人贡献者和维护者通常没有报酬，他们仅凭有限的资源开展工作，且与依赖其成果的企业之间不存在合同义务。

‍

这导致了根本性的脱节。企业需要软件系统在5至10年内保持稳定和安全。相比之下，开源生态系统采用更快、更灵活的生命周期，且在既定的生命周期结束日期之后，没有义务继续支持旧版本。

‍

理解生命终点：它的真正含义

当一个开源软件（OSS）组件达到其声明的停用期限时，它将进入以下状态：

• 将不再发布任何安全补丁或CVE修复方案
• 不提供任何错误修复或兼容性更新
• 社区参与度、论坛活跃度以及问题跟踪数量急剧下降
• 项目可能会被归档或正式废弃

该组件在技术上可能仍能正常运行，但其运行和安全保障已不复存在。专注于交付的工程团队往往对此视而不见——直到合规审计、安全扫描或漏洞披露迫使他们正视这一问题。

‍

运行已停止维护（EOL）的开源软件所带来的影响绝非仅限于理论层面。新思科技（Synopsys）的 OSSRA 报告指出，在 2024 年分析的应用程序中，有 45% 至少包含一个已不再积极维护的开源组件。这些组件通常深埋在依赖关系树中，若不进行大规模重构，便难以检测和替换。

‍

未受支持的开源软件带来的四类风险

未修复的安全漏洞

不受支持的开源软件无法通过官方渠道进行更新。当在已停止维护的组件中发现新的 CVE 时，上游不会发布修复程序。这意味着这些漏洞将无限期地处于未修复状态。

‍

在2023年的一项关于软件供应链风险的研究中，企业环境中48%的已知漏洞可追溯至未维护或已停止支持（EOL）的开源库。这些漏洞尤其危险，因为它们已被公开披露且易于被利用，但由于迁移过程复杂，往往会在生产环境中存在数月甚至数年之久。

‍

安全团队面临一个艰难的抉择：是手动修补过时的组件并承担工程负担，还是保留该组件并接受由此带来的安全风险。无论选择哪种方式，在规模化部署时都难以持续。

‍

合规与审计失职

现代合规框架（例如 SOC 2、ISO 27001、HIPAA、PCI DSS、NIST 800-53）越来越多地包含相关要求，要求组织证明其使用的是受到积极支持且安全的软件。从定义上讲，已停止维护的组件无法满足这些标准。

‍

在过去18个月里，这一风险变得愈发明显，特别是在受到监管审查的行业中。Linux基金会2023年的一份报告显示，超过70%的联邦机构将无人维护的开源软件（OSS）组件视为对其合规状况构成重大风险的因素³。

‍

独立软件供应商也受到了影响。在接洽大型企业客户或政府客户时，供应商通常会被要求提交软件物料清单（SBOM）文件并核实支持状态。若软件中包含已停产（EOL）组件，可能会导致合同签订延迟或被取消资格。

‍

运营脆弱性

当发生事件时，不受支持的软件组件会延长问题修复时间。随着上游支持和文档的逐渐减少，内部知识孤岛随之出现。工程团队必须投入资源来对补丁进行逆向工程、解决依赖冲突或重写集成代码——这会分散他们对核心开发目标的注意力。

‍

此外，组织使用已达到生命周期终止（EOL）版本的时间越长，未来的升级就越困难。依赖锁定和API契约的分化会使技术栈变得脆弱，从而增加现代化改造过程中发生连锁故障或系统停机的可能性。

‍

战略与业务中断

在高风险场景中——例如并购、尽职调查流程、网络安全保险续保等——运行未获支持的OSS可能会被视为一项重大风险。无法提供证明持续获得支持的文件的组织，往往会面临风险评级上升或合同延迟的情况。

‍

在2023年的一项案例研究中，一家致力于建立企业合作伙伴关系的SaaS公司因使用了AngularJS Lodash 这两者均已达到生命周期终止（EOL）——而未能通过供应商安全审查。尽管相关应用程序运行稳定，但潜在客户的安全团队要求确保这些组件仍享有活跃支持或正式的长期支持（LTS）覆盖。由于缺乏上述任一保障，合作启动被推迟了90天，并导致了大量未预见的整改工作。

‍

传统缓解措施为何会失败

立即升级

从理论上讲，迁移到开源项目（OSS）的最新版本可以消除这一风险。但在实际操作中，这种方法往往行不通——尤其是当不同版本之间存在破坏性变更，或者系统与旧版行为紧密耦合时。

‍

Spring、Angular 和Node.js 等框架在不同版本之间进行了重大的架构变更。这些变更需要数月的规划、质量保证以及员工再培训。在 Gartner 2023 年的一项研究中，超过 65% 的软件现代化项目超出了预算，且超过 40% 的项目未能达到既定目标。

‍

独立软件供应商也受到了影响。在接洽大型企业客户或政府客户时，供应商通常会被要求提交软件物料清单（SBOM）文件并核实支持状态。若软件中包含已停产（EOL）组件，可能会导致合同签订延迟或被取消资格。

‍

内部分叉与维护

有些团队试图对不再受支持的库进行分叉并自行打补丁。虽然这对于短期修复可能足够，但会带来长期负担：

• 工程团队负责跟踪漏洞并编写补丁
• 与外部工具（例如扫描仪、CD 管道）的集成效果下降
• 知识集中在少数几名团队成员手中，从而产生了关键人员风险

分叉还会加剧与社区版本的差异，从而使今后的迁移或重基操作变得更加复杂。

‍

接受风险

第三种（也是最常见）的做法是被动接受。团队继续运行已达到生命周期末期的软件，通常并未充分意识到其影响，直到发生某种触发事件——例如审计未通过、安全漏洞或导致开发停滞的依赖冲突。

‍

这种被动应对的姿态无论在运营层面还是声誉层面都代价高昂。修复已知但未处理的漏洞所产生的财务成本，在事件发生后通常比在计划升级或支持服务期间高出4至6倍。

‍

商业长期支持的作用

商业合作伙伴提供的长期支持（LTS）为这些不尽如人意的方案提供了一种结构化的替代方案。这种方法能够为那些不再由原始作者或基金会维护的开源软件（OSS）组件提供持续的安全保障和风险缓解措施。

‍

在 HeroDevs，我们称之为“永无止境的支持”。

‍

我们的模型提供：

• 针对已停止支持的开源软件版本的、由SLA支持的安全补丁
• 持续的漏洞监测与响应
• 审核级文档，包括补丁历史记录和合规性报告
• 兼容性保留更新，已在您的环境中经过测试
• 针对各版本的支持时间表，便于进行有计划的现代化改造

这使组织能够在保持当前版本的同时，确保合规性、安全完整性和开发速度。

‍

持续支持的战略优势

采用商用 LTS 的组织将获得：

• 减轻了升级压力，使他们能够按照自己的时间表进行现代化改造，而不是遵循社区的时间表
• 提高了审计准备程度，并记录了补丁覆盖范围和SLA参考信息
• 通过主动修复CVE漏洞，降低安全漏洞风险
• 通过消除计划外的升级工作，提高工程效率
• 与跨多个季度的迁移预算相比，财务可预测性

在存在多个应用程序或大量遗留系统的复杂环境中，这些优势最为显著。

‍

产品生命周期结束不仅是一个技术风险，更是一个商业风险

人们对开源软件的广泛依赖，已经超出了大多数组织负责任地维护这些软件的能力。随着开源软件项目达到生命周期终点，正式支持机制的缺失会在安全、合规和运维方面带来隐蔽且不断累积的风险。

‍

HeroDevs 指明了前进的方向。我们的“永不终止的支持”计划可帮助工程、安全和合规团队在官方支持结束后很长一段时间内，继续掌控其开源软件（OSS）环境。

‍

在一个所有系统都依赖开源的世界里，能够扩展对关键组件的支持已不再是一种便利，而是一种战略必需。

‍

关于HeroDevs

HeroDevs 为已停止维护的开源软件提供商业级、附带服务水平协议（SLA）保障的支持服务。我们的“永续支持”服务可帮助各类组织保障其遗留开源软件环境的安全、进行维护并建立文档记录。我们的客户遍布金融、医疗、基础设施和软件等多个行业。

‍

如需了解更多信息，请访问herodevs.com或通过 support@herodevs.com 与我们联系。

‍

参考文献

1. 新思科技。《2024年开源安全与风险分析报告》。
2. Forrester. 《保障软件供应链安全》。2023年。
3. Linux基金会。《政府开源现状报告》。2023年。
4. Gartner。《软件现代化趋势调查》。2023年。