OWASP 发布十大开源软件风险清单（详解版）

近日，OWASP发文称，尽管软件供应链对开源软件 (OSS) 的依赖程度很高，但业内缺乏一致的用于了解和衡量OSS风险的方法。OSS 风险管理始于许可管理，之后延伸至CVE，但我们仍然缺乏与安全、法律和运营相关的全面的OSS风险管理方式。本文档旨在创建这种全面的OSS风险管理方式。

在过去十年来对OSS的依赖历史中，以CVE编号为载体的已知漏洞成为衡量安全性的关键指标。虽然已知漏洞是一项重要的指标，但它们通常捕获的是由意图良好的开发人员犯的错误。这些错误可被攻击者利用且应当予以修复，但它们几乎无法涵盖依赖OSS所引发的全部风险。运营风险如由过时或未维护软件引发的风险，或者下一代供应链风险如由名称混淆攻击引发的风险，无法由CVE体现。而这些风险同样影响重大。

本清单由20多位首席信息安全官们和首席技术官们评审和贡献，旨在找到开发团队应当做好准备迎接的最严重的运营和安全风险。

这十大OSS风险如下，本文将翻译各风险的含义、示例和应对措施部分，供大家参考。

一 已知漏洞

1、 含义

组件版本中可能包含由开发人员不慎引入的易受攻击的代码。漏洞详情被公开披露，如通过CVE、GitHub 安全公告或其它不太正式的通信渠道公开。利用和布丁可能存在或不存在。此类漏洞在下游软件情境中可能是可利用的，可能导致相关系统或数据的机密性、完整性或可用性遭攻陷，进而允许在目标环境中横向移动或带来其它负面影响。

2、 示例

（1）CVE-2017-5638，位于 Apache Struts 中，触发 Equifax 数据泄露事件。

（2）CVE-2021-44228，位于Apache Log4j中，也被称为 “Log4Shell”。

3、 应对措施

（1）监控应用程序、容器和系统中是否存在含有已知漏洞的（直接和可传递）开源依赖；

（2）基于如下等条件，优先安排分析和缓解：

• 评分和度量，如CVSS和EPSS

• 威胁情报如利用代码的可用性和成熟性，或者在野攻击信息如由CISA必修清单提供的信息；

• DAST和SAST工具，判断易受攻击的代码能否在依赖软件上下文中执行。

二 合法包遭攻陷

1、 含义

攻击者可能攻陷作为现有合法项目或分发基础设施组成部分的资源，在组件中注入恶意代码，如通过劫持合法项目维护人员的账户或利用包仓库中的漏洞实现。恶意代码可能在终端系统上，或在组织机构中负责开发和/或运营依赖软件（如构建系统或开发者工作站）的系统上执行。系统的机密性、一致性和可用性以及处理/存储在系统中的数据面临风险。

2、示例

(1)    Event-stream：对合法组件的攻击，目标是Copay 比特币钱包用户。

(2)    SolarWinds 攻击

3、 应对措施

检测和防御受陷包需要多力协作。组织机构应当通过现有标准和框架如《供应链安全消费框架 (Secure Supply Chain Consumption Framework, S2C2F)》获悉可能的保护措施，且应当基于具体的安全要求和风险偏好进行选择和优先级排序。

相关措施如下：

（1）根据SLSA验证组件来源；

（2）从来源（你自己或可信第三方）构建组件；

（3）手动和/或自动审计代码；

（4）检索来自安全内部商店中的所有组件（如二进制仓库托管自有二进制和镜像外部组件）

三 名称混淆攻击

1、含义

攻击者创建的组件名称与合法开源或系统组件的名称类似 (typo-squatting)，或者给人印象是可信的作者（品牌劫持），或在不同的语言或生态系统中使用常见的命名模式 (combo-squatting)。恶意代码可能在终端系统上，或在组织机构中负责开发和/或运营依赖软件（如构建系统或开发者工作站）的系统上执行。系统的机密性、一致性和可用性以及处理/存储在系统中的数据面临风险。

2、示例

Colourama（PyPI，2018）：对合法Python 包 “colorama” 的typo-squatting 攻击，将比特币转账重定向至受攻击者控制的钱包。

3、应对措施

在安装/使用组件前：

（1）检查代码特征（安装前/后的钩子、编码的payload等）和项目特征（源代码仓库、维护人员账户、发布频率、下游用户的数量等）中是否存在风险指标线索。需要注意的是，某些元数据并未获得包仓库的验证，因此可被攻击者轻易伪造。

（2） 验证组件的签名源自可信方（适用于支持/要求签名的生态系统）。

四 未维护的软件

1、含义

组件或组件版本可能不再得到活跃开发或支持，如不再开发针对新功能或安全漏洞的补丁。因此，补丁可能由经验和知识更少的下游开发人员开发，从而导致投入加大、修复时间更长。在此期间，系统和功能访问可能受限制，以避免持续被暴露的风险。

2、 示例

（1）core-js (npm, 2020)

（2）Gorilla Web Toolkit (Go, 2022)

（3）minimist (npm, 2022)

3、 应对措施

（1）检查项目活跃度和健康度指标

不过需要注意的是，活跃度较低也可能是成熟的表现。特性完整和成熟的项目要比正在开发的项目的活跃度低，不过在出现问题时仍然可获得及时的补丁。

指标如下：

• 最近的issue和commit活动说明项目是活跃的。

• 外部贡献者打开issue的高比率说明该项目是活跃的。

• 企业相关账户的活动表明该项目可获得稳定可靠的支持。

• 声誉良好的账户的活动表明该仓库维护良好。

• 仓库有最新发布，说明对维护和支持代码库的贡献。

（2）查找项目维护或支持的战略信息，如是否存在长期支持版本及其日期。如 Spring 项目就是记录支持时间轴的绝佳例子。

（3）查看项目页面是否被归档，或者是否存在关于该项目维护状态的明确声明。

五 过时的软件

1、含义

项目可能使用老旧、过时的组件版本（尽管更新版本已经存在）。使用距离最新依赖发布太远的版本，可能导致在紧急情况（如所使用的版本中漏洞的披露）下难以做到及时更新。老旧发布可能也不会收到与最近版本同等程度的安全评估，尤其是对于是否受漏洞影响的评估。如果新版本与当前所用版本在句法或语义上不兼容，那么应用程序的开发人员可能要通过重大更新/迁移来解决这一不兼容问题。

2、示例

（1） Spring Boot 支持时间轴

（2） 影响Apache Tomcat的漏洞“未被检查是否影响分支8.0.x，且不会被修复”。

3、应对措施

（1）使依赖更新成为常规的积压项目进行处理；

（2）自动化发现和推荐更新，如通过合并/拉取请求进行；

（3）通过变更影响分析工具来检测引入变更或重大变更的情况。

六 未被追踪的依赖

1、含义

项目开发人员可能根本没有发现组件中的依赖，原因可能是该依赖并非上游组件SBOM的组成部分、SCA工具未运行或未检测到、或者依赖并非通过包管理器设立。因此，相关组件无法被检查或监控是否存在其它缺陷。

2、示例

（1）上游软件收到或SCA工具生成不完整的SBOM。

（2）在管理（追踪）依赖中包括第三方代码，如：

• 代码片段

• 源代码文件（按原状复制到依赖的源中，也被称作“按厂商的”）

• 编译代码（例如适用于平台的二进制或Java 归档/class文件，也称作“重新绑定”）

（3）依赖未通过保管理器的表示文件如 PIP 或 Maven 创建，如手动安装或通过brew 或 apt-get 脚本安装。

（4）IDE插件、构建脚本、测试依赖或其它开发者工具，尽管未包含在依赖软件本身，但仍然带来安全和运营风险。

3、应对措施

在粗颗粒度（如在包管理工具如 Maven 或 npm 等帮助下声明的依赖）和细颗粒度（如“带外”包含的工件如单个文件，即未使用包管理器）层面，评估和对比SCA工具。

七 许可和合规风险

1、含义

组件或项目可能并不具备许可，许可与下游客户的预期使用不兼容，或下游用户无法满足许可要求。组件可能还违反了独立于下游使用的许可条款，如许可协议为GPL但包含的文件受原始的BSD许可证约束。组件也可与法律法规要求冲突，如与FedRAMP认证或出口管控相关的要求。按照许可条款合规使用组件非常重要。缺少许可或不合规应用可能侵犯版权或许可条款，而版权方有权提起诉讼。违反法律法规要求能够限制或损害某些垂直行业或市场。

2、示例

Free Software Foundation 诉讼思科公司未经许可分发版权软件(2008)

3、应对措施

（1） 为正在开发的软件，找到按预期使用组件所需的可接受许可。例如，应该考虑该组件如何连接、软件的部署模型（云、本地/设备）以及既定的分发计划。

（2）遵守开源许可中所提到的要求。

（3）避免使用没有许可的组件。

（4）审计组件文件中是否存在多个和/或不兼容的许可。

八 不成熟的软件

1、含义

开源项目可能未应用开发最佳实践，如未使用标准的版本控制计划、不具备回归测试套件、没有开发或审计指南或文档。因此，组件可能无法可靠地或安全地运作（安全弱点导致可利用的漏洞层面）。对不成熟组件或项目的依赖带来运营风险。依赖软件可能无法按预期运作，因此导致运行时可靠性问题，或者对于依赖软件开发组织机构而言，它的使用过于复杂和昂贵。例如，组件或项目可能缺乏文档，可能无法按照已有版本控制计划合规使用（可能在组件更新过程中导致突发变更），或者不具备测试套件来发现通过拉取/合并请求引入的回归。这类情况增加了依赖于这些组件的开发投入。

2、示例

无。

3、应对措施

（1） 检查质量指标以及项目是否遵循开发最佳实践。

指标包括：

• 项目包括测试代码。

• 展示代码覆盖率徽章意味着该仓库在开发流程中使用了代码覆盖率工具。

• 该仓库中包含文档，使其更容易理解和使用。

• 该仓库使用CI和提交，通过CI检查，说明代码质量良好。

• 当仓库中包含二进制文件时，更难以分析和评估其功能和风险。

（2） 检查项目成熟度的代理可能也是下游依赖的数量。

九 未经批准的变更（组件可变）

1、含义

组件可能会在开发人员无法注意到、审计或批准此类变更的情况下进行变更，原因可能是下载链接指向无版本编号的资源，有版本编号的资源已被修改或篡改，或数据传输不安全等。使用在不同时间点下载的无法保证版本一致的组件是一种安全风险。如针对Codecov Bash Uploader 的攻击，说明了在未事先检查其完整性的情况下，将所下载脚本直接pip到bash 中的风险。可变组件也威胁软件构建的稳定性和可复现性。

2、示例

（1）在CI/CD管道中应用无版本编号的 shell 脚本；

• 如Codecov bash uploader事件 (2021)

（2）在没有commit 标识符的情况下引用 Git 仓库；

（3）包注册表的HTTP链接不安全。

• CVE-2021-26291：位于Apache Maven中（2022）

3、应变措施

（1）使用提供保证的资源标识符（或者至少某种程度的保障），总是指向同一个、无法变更的工件。

（2）组件下载后以及安装/使用前，验证数字或签名；

（3）使用安全协议进行连接/分发，避免中间人攻击。

十  过小/过大的依赖

1、含义

组件可能提供非常少（如 npm 微包）或者很多（仅使用了少部分）的功能。非常小的组件（如仅包括几行代码的组件）和规模更大的组件（如账户接管、恶意拉取请求或CI/CD漏洞）引发的供应链风险一样大，而使用这些组件的目的是为了获得相对小的功能。换句话说，为了使用区区几行代码，客户的安全就取决于上游项目的安全和开发态势。非常庞大的组件已经累积了很多但在标准用例中并务必要的特性，然而但却构成了该组件的攻击面。另外，此类未使用的特性可能会引入更多的、未使用的依赖（膨胀依赖）。

2、示例

(1)   Apache Log4j

包含从远程服务器下载和执行任意Java类的功能，最终导致Log4Shell。

(2)   Left-pad (npm, 2016)

该模块通过11行代码填充字符串。从npm中删除它破坏了无数下游客户的构建。

3、应对措施

（1）发现未使用的组件能力，尤其是如果他们使用了关键的（安全敏感）API，以此构建网络连接。评估禁用未使用能力的可能性，或者使用能力更少、规模更小的开源组件。

（2）发现微型包，并考虑在内部重新开发它们的功能。