3月20日，xz-utils 项目被爆植入后门震惊了整个开源社区，2021 年 Apache Log4j 漏洞事件依旧历历在目。倘若该后门未被及时发现，那么将很有可能成为影响最大的软件供应链漏洞之一。近几年爆发的一系列供应链漏洞和风险，使得“加强开源软件（OSS）安全”的呼声越来越高，以维护脆弱的现在数字生态系统。

基于此，OWASP发布了开源软件风险清单TOP 10，旨在解决帮助企业用户更好地解决开源软件组件安全问题，帮助安全从业者更成熟地治理和安全使用OSS。风险清单TOP 10由Endor Labs首创，该公司专注于OSS安全、CI/CD管道和漏洞管理、软件供应链安全等。

传统漏洞管理获取已知漏洞的渠道，CVE漏洞库通常是重点关注来源之一，但越来越多的网安从业者都意识到，已知漏洞是风险的滞后性指标。

为了更好地应对风险，管理开源软件漏洞，网安人必须关注风险的先行指标，以便更快发现特定OSS库、组件和项目之间存在的威胁。

以下OWASP发布10大开源软件风险清单。

1. 已知漏洞

这部分内容涉及已知漏洞的OSS组件，如软件缺陷，这些缺陷通常是软件开发者和维护者无意中引入，然后由社区中的安全研究人员公开披露。

这些漏洞是否可被利用取决于它们在组织和应用程序中的使用环境。虽然这一点可能看起来微不足道，但实际上并非如此——未能为开发者提供这种环境会导致大量辛苦工作、浪费时间、挫败感，以及常常对安全部门产生抱怨。

针对这些风险，美国网络安全与基础设施安全局（CISA）会公布已知被利用漏洞（KEV）目录和漏洞预测评分系统（EPSS）。

组织可以采取措施来减轻已知漏洞OSS组件的风险，例如扫描企业已使用的OSS组件中的漏洞，基于已知利用、利用概率、可达性分析（这可以减少80%的无效发现）等方法来确定优先级。

2. 伪装合法软件包

越来越多的恶意行为者发现，通过伪装成合法维护人员，以看似合法实则恶意的软件包来影响下游企业和用户非常好用。具体来说可以使用多种方法来实现这种攻击途径，例如劫持项目维护者的账户或利用仓库中的漏洞。

他们还可以自愿成为开源社区的维护者，只是为了在将来某个时候发起恶意攻击，最近爆发的XZ Utils事件就是其中的典型例子。攻击者伪装成合法的社区维护人员，利用长达数年的时间在系统中植入了后门。

那么该如何减少上述风险？安全专家建议使用类似微软的（现已捐赠给OpenSSF）安全供应链消费框架（S2C2F）等典型框架。

3. 名称混淆攻击

在名称混淆攻击中，攻击者创建的恶意组件名称与合法的OSS包或组件相似，希望它们会被潜在受害者在无意中下载和使用。这种攻击在CNCF软件供应链攻击目录中也有体现，包括拼写错误、抢注和品牌劫持。当这些恶意的包被带入组织的IT环境时，可能会影响系统和数据的机密性、完整性和可用性（CIA）。

4. 未维护的软件

0SS与常用软件不同，它没有“确定的供应商”，OSS维护者提供的软件是“原样”，这意味着无法保证软件会被维护、更新或持续。Synopsys发布的OSS报告数据显示，85%的代码库超过四年未更新OSS组件，且在两年内没有任何新的开发。

考虑到软件的老化速度极快，新漏洞正在以创纪录的速度出现，许多未能积极更新OSS组件的软件存在极大的不安全性，这点从国家漏洞数据库（NVD）发布的数据中可见一斑。

这也是无法避免的现状。由于OSS主要依靠无偿的志愿者维护，那么其组件不被积极开发、更新、修复缺陷等也在情理之中。即使有一定的维护，可能也存在较大的滞后性，不符合下游企业用户的期望，更不会像供应商那样向下游客户提供漏洞修复的服务级别协议（SLA）。

导致OSS组件未维护的另一个关键因素是，有25%的OSS项目只有一个开发者贡献代码，94%的项目维护者/开发者低于10人。如果一个项目只有一个维护者，风险是显而易见的。考虑到60-80%现代代码库由OSS组成，人们开始意识到当下数字生态系统的相当一部分，甚至我们最关键的系统都运行支持和维护最少的软件上。这也代表潜在的系统风险无比巨大，且很容易被攻击者利用。

处理这种风险的建议包括检查项目的活力和健康状况，如维护者和贡献者的数量、发布频率以及修复漏洞的平均时间（MTTR）。

5. 过时的软件

一个项目正在使用一个过时的组件版本，可能存在低版本的安全风险。据Synopsys发布的报告数据显示，在开源软件领域这种情况是常态，在绝大多数代码库和仓库中都会发生。

另外，许多现代软件应用和项目的依赖关系错综复杂，令人眼花缭乱，并且直接提升了漏洞安全风险。Sonatype和Endor Labs联合发布的《依赖管理现状》指出，95%的漏洞与传递依赖关系有关。

6. 未跟踪的依赖关系

开发者/组织有时未意识到使用了特定的依赖关系或组件的情况，其原因可能是企业没有使用软件组成分析（SCA）等工具来了解他们所使用的OSS软件；或者是没有采用新兴工具如软件物料清单（SBOM）进行检查分析，这些工具为企业提供已使用的软件/组件可见性。

经过SolarWinds和Log4j等事件，网络安全行业深刻意识到，大多数企业的软件资产清单多年来一直是SANS/CIS的关键控制，但仍缺乏全面的软件资产管理，更别提细化到组件/库级别。因此我们更需要SBOM等工具，为企业进一步了解所使用的组件清单，以便打造更安全的软件供应链。

7. 许可和法规风险

许可和法规风险是指组件或项目在实施过程中缺乏相应的授权许可，那么可能会导致下游企业违规使用组件的风险。

OWASP指出，组织需要确保他们对OSS组件的使用符合适用许可条款，不然很有可能因此引发侵犯风险，造成大量财产损失甚至是法律诉讼。这也可能会影响组织的商业目标、并购活动等，因为在其专有产品、服务和产品中可能广泛地使用OSS组件。

组织可以采取措施来减轻这些风险，例如确定他们在软件中使用的组件具有授权，同时当授权许可存在冲突或风险时，需避免使用这类组件，及时规避可能发生的损失。

8. 不成熟的软件

不成熟的软件风险在于并非所有的开源软件都能保持较高的成熟度，这是由开发者和维护者的个人技术能力决定。例如一些OSS项目可能没有应用安全软件开发实践（NIST安全软件开发框架（SSDF）），具体来说可能没有文档、缺乏回归测试、没有审查指南以及其他最佳实践。

另外一个无法回避的现实是很多开发者并不重视安全性，更关注使用性和便捷性。Linux Foundation和哈佛大学的创新科学实验室（LISH）研发后发现，自由和开源软件的开发者投入在代码安全性的比例仅仅只有可伶的2.3%。

企业可以通过一些工具来对开源软件的安全性进行检查，例如OpenSSF发布的Scorecard就可以为Github的OSS组件提供安全性分析，包括安全保护、贡献者的数量、CI测试、模糊测试、维护措施、授权许可等。目前市面上也有其他类似的工具可以实现上述功能。

9. 未经批准的变更

OWASP将未经批准的变更的风险定义为，OSS组件可能发现变化但开发者没有注意到，因此未能及时审查或批准变更的情况。这可能发生在下载链接变化或指向未版本化资源的情况下，甚至是被篡改的不安全数据传输，该风险强调了安全传输的作用。

缓解措施包括使用资源标识符以确保并指向不可变工件，在实际安装和使用组件之前，还可以验证组件的签名和摘要。此外，为了减轻组件在传输中被妥协的风险，组织应使用安全协议来传输和网络流量通信。

10. 依赖关系过小/过大

最后的风险是依赖关系过小/过大，例如开源软件具有很少或大量的功能，而实际上企业只使用了其中的一部分，这通常被称为“软件膨胀”。

在依赖关系过小的例子中，由于代码行数有限，组件变得依赖于上游项目的安全。另一方面，当代码膨胀或代码行数成倍增加时，会引入更多的攻击面和潜在的可利用代码/依赖关系，给企业带来不可知的安全风险，且不符合既定预期。

因此企业应尽可能重新开发内部所需的功能，以此来减轻依赖过小或过大的风险。安全专家也发现，可在云原生容器化环境中利用“安全基础镜像”进行推广，例如Chainguard一直倡导具有有限漏洞甚至没有漏洞的最小加固基础镜像——"安全基础镜像 "。

参考来源：

https://www.csoonline.com/article/2088471/owasp-top-10-risks-list-attempts-to-establish-more-mature-approach-to-open-source-software-consumption.html