​
最近爆发的XZ后门事件，尽管未酿成Log4j那样的灾难性后果，但它再次敲响了警钟：软件供应链严重依赖开源软件，导致现代数字生态系统极其脆弱。面对层出不穷的安全漏洞，我们需要关注开源软件 (OSS)风险 ，改进其保护和使用方式。 

风险1｜存在已知漏洞

这一风险是指存在包含已知漏洞（如软件缺陷）的开源软件组件。这些漏洞通常由软件开发人员和维护人员无意中引入，然后由社区的安全研究人员公开披露。这些漏洞可能会被利用，具体取决于它们在组织和应用中使用的上下文。

应对指南：

OWASP建议组织采取多种措施，来降低包含已知漏洞的开源软件组件风险，例如扫描使用的所有开源软件组件中的漏洞，根据已知利用、利用概率、可达性分析(可将误报率降低80%以上)等方法对发现结果进行优先级排序等。

此外，业界还开发了一系列平台来应对这一挑战，如CISA的已知被利用漏洞(KEV)目录和利用预测评分系统(EPSS)。

风险2｜合法软件包遭植

第二个风险是指攻击者通过破坏合法软件包，将恶意代码注入开源组件，从而影响采用的组织和下游用户。

攻击者可以使用多种方法来追踪这种攻击媒介，例如劫持项目维护者的帐户或利用软件包存储库中的漏洞。

攻击者还可以成为开源项目的志愿维护者，以便日后实现其邪恶意图。最近的 XZ 后门事件正是这种情况：在代码中嵌入后门前，攻击者很长一段时间一直冒充合法的开源贡献者。

应对指南：

目前没有单一的措施可以检测和防止摄入被注入恶意代码的软件包。组织应参考安全供应链消费框架 (S2C2F) 等新兴标准和框架，了解可行的安全措施，并根据安全要求和风险偏好进行选择和优先级排序，可能的措施包括根据软件制品供应链级别框架(SLSA)，验证验证组件来源；从可信来源构建组件，以及手动或自动进行代码审查等。

风险3｜名称混淆攻击

在名称混淆攻击中，攻击者创建的恶意组件，使用与合法开源软件包或组件相似的名称（拼写错误），建议可信的软件作者（品牌劫持），或使用不同软件/生态环境的常见命名模式（组合仿冒），希望潜在受害者会无意中下载和使用。受破坏的软件包进入组织 IT 环境时，可能会影响系统和数据的机密性、完整性和可用性 (CIA) 。

应对指南：

在安装/使用开源软件组件之前，检查代码特征和项目特征以获取主要风险指标。此外，还要验证组件是否带有来自受信任方的签名。

风险4｜组件缺乏维护

这是指开源软件的组件或组件版本开发不再活跃，因此，原始的开源项目可能不及时（或根本不会）提供功能性和非功能性的漏洞补丁。

与专有软件不同，开源软件的一个残酷现实是没有“供应商”。开源软件维护者“按原样”提供软件，这意味着无法保证该软件开源得到及时的维护、更新或持续。

Synopsys 的开源软件报告显示，其所评估的代码库中，85%拥有已过时四年多的开源软件组件，且两年内没有任何新的更新。软件的老化速度很快，新漏洞正以创纪录的速度出现，如果现代软件使用不及时更新开源软件组件，其安全性将面临严峻的挑战。

开源软件主要由志愿者来无偿支持。软件组件可能不会得到及时的开发或维护，修复漏洞也可能不及时或者可能不会按照组件使用者所期望的时间表进行，也不会提供专有供应商那样的漏洞修复服务级别协议（SLA）承诺。

造成开源软件缺乏维护的另一个关键因素是维护人员过少：25%的开源软件项目只有一名开发人员贡献代码；94%的开源项目由10名或更少的开发人员维护，其中隐藏的风险是显而易见的。

60～80% 的现代软件代码库是由开源软件组成的，这意味着我们的数字生态系统的很大一部分，甚至是最关键的系统，都在受到最低限度支持和维护的软件上运行，这代表着重大的系统性风险。

应对指南：

相应的应对建议包括检查开源项目的活跃程度和健康状况，例如维护者和贡献者的数量、发布频率和漏洞修复时间（MTTR）。

风险5｜使用过时组件

这种情况是指尽管可能存在新的组件版本和更新，项目仍使用过时的组件版本。Synopsys 公司在报告中指出，这种状况实际上是一种常态，经常会出现在绝大多数代码库和存储库中。

过于落后最新版本的依赖项，可能会导致紧急情况下难以及时开展更新，如所使用的版本发布漏洞时。旧版本可能也无法获得与最新版本相同级别的安全评估，尤其是否受到漏洞的影响。

现代软件应用和项目之间令人眼花缭乱的依赖关系，令这一问题变得更加错综复杂。Sonatype 和 Endor Labs 等机构发布的报告强调了这个问题，后者所发布的《依赖管理现状报告》显示，95%的安全漏洞与传递依赖相关。

应对指南：OWASP的应对建议包括，（1）将依赖项更新设为重复待办事项。（2）实现发现和建议更新的自动化。（3）利用软件变更影响分析工具，检测是否出现变更或不向下兼容的破坏性变更。

风险6｜未跟踪依赖项

这种情况是指开发人员/组织不知道自己使用了特定的依赖项或组件。发生这种情况的原因可能是组织缺乏软件成分分析 (SCA) 等相关工具，以了解开源软件的使用情况，或者没有采用软件物料清单(SBOM) 等新兴工具。这些工具可以帮助组织清晰了解所使用或发布的软件组件。

这些工具实际上是推动软件物料清单和供应链安全广泛努力的一部分。业界通过SolarWinds和 Log4j 等事件认识到，尽管多年前SANS研究所已将软件资产清单列入CIS关键安全控制清单中，大多数组织仍缺乏深入到软件组件/库层级的全面软件资产清单。

应对指南：

建议评估和比较软件成分分析 (SCA) 工具生成准确的物料清单的能力，包括粗粒度级别和和细粒度级别。

风险7｜许可和监管风险

这种风险是组件或项目可能缺乏许可，或可能拥有阻碍下游使用的许可情况。

OWASP 指出，组织需要确保其对开源软件组件的使用符合相关适用许可条款，否则可能会导致许可或版权侵权，甚至法律诉讼。

随着组织在其专有产品、服务和产品中更广泛地使用开源软件组件，这种风险可能会影响组织的业务目标、并购活动等。

应对指南：

组织可以通过确定其软件所使用及计划使用组件的适用许可，以降低相关风险。除了了解组件是否使用多个许可或冲突的许可之外，组织还应该完全避免使用未经许可的组件。

风险8｜软件不成熟

开源项目可能不采用软件开发的最佳实践，因而在成熟度方面肯定存在差异，部分原因是维护人员的参与程度不同。

某些开源软件项目可能未采用安全软件开发实践【如 NIST 安全软件开发框架 (SSDF) 所提到的】。具体案例可能包括没有开发文档、缺乏回归测试、没有审查指南和许多其他最佳实践。

另一令人不安的现实是很多开发人员对软件安全不感兴趣。Linux 基金会和哈佛大学创新科学实验室 (LISH) 等机构的研究发现，自由和开源软件开发人员只花费 2.3% 的时间来提高软件代码的安全。

对不成熟组件或项目的依赖会带来运营风险。依赖软件可能无法按预期工作并导致运行时可靠性问题，或者其使用可能过于复杂和昂贵。

应对指南：

目前有一些行业推动的措施和工具可应对这一风险，例如OpenSSF 的记分卡，为 Github 的开源软件项目提供强大的检查，例如分支保护的存在与否、贡献者/组织的数量、CI 测试、模糊测试、维护、许可等。另一项降低此风险的工作是 CISA 和 OpenSSF联合发布的“组件存储库安全原则”。

风险9｜未经批准的更改

OASP 将这种风险定义为软件组件可能在开发人员未注意到、未审核或批准的情况下发生更改的情况。当下载链接发生改变、指向未版本化的资源、甚至是被篡改的不安全数据传输时，可能会出现这种风险。这一风险主要强调安全传输的作用。

应对指南：

OWASP建议的操作和缓解措施包括使用资源标识符用于安全保证，以及指向相同的不可变软件工件。此外，还可以在安装和使用开源软件组件之前，验证组件的签名和摘要。为了降低开源软件组件在传输中受到破坏的风险，组织应使用安全协议来开展网络流量的传输和通信。

风险10｜组件过小/过大

最后一种情况是，开源软件组件可能提供很少或很多的功能，但组织实际上只使用其中的一部分。

非常小的组件会遭受与大型组件相同的供应链风险，而且严重依赖上游项目的安全性和开发态势。非常大的组件堆积了许多标准用例中不需要的功能，却因此增加了组件的攻击面和潜在可利用代码/依赖项。

应对指南：

在这些情况下，OWASP建议组织了解未使用的组件功能，评估禁用未使用功能的可能性，或用功能少的小开源组件进行替代。同时，尽可能在内部重新开发所需的功能。