OWASP提出了十大开源软件风险

已知漏洞通常是由软件开发人员和维护人员在无意中引入的，然后再由社区中的安全研究人员公开披露。

组织可以采取行动来降低“具有已知漏洞的OSS组件”的风险，例如扫描他们所有OSS组件中的漏洞，根据已知利用率、利用概率、可达性分析等方法对发现结果进行优先排序。

恶意行为者发现，从合法包上下手，可以影响到下游消费者的价值，其无论是对组织，还是对个人都能造成极大的影响。恶意行为者可以使用多种方法来完成此类攻击，例如劫持项目维护人员的帐户或利用存储库中的漏洞。

当然，恶意行为者也可以自愿变成维护者，一如XZ Utils事件中所发生的情况，即有人在很长一段时间内冒充合法贡献者，然后在不被他人怀疑的情况下，这些不法者从代码中嵌入了后门。

那该如何预防呢？我们可以使用新兴的资源和指导，比如使用微软的安全供应链消费框架（S2C2F）等。

攻击者会创建名称和合法OSS包一样的恶意组件，而这些组件会在无意中被受害者下载。此类攻击也出现在了CNCF软件供应链攻击目录中，包括打字错误和品牌劫持。当这些“做过手脚”的软件包被带到组织的IT环境中，它们可能会影响系统和数据的机密性、完整性和可用性（CIA）。

与专有软件不同，开放源码软件通常没有“供应商”，因此OSS维护人员按原样提供软件，这意味着不能保证软件会得到维护、更新或持续使用。

Synopsys的OSS报告等报告表明，85%代码库中的OSS组件已经过时四年多，而且两年内没有任何新的迭代。而根据年度NVD指标，考虑到软件老化迅速，新的漏洞正在不断冒出，这对使用“不常更新OSS组件的现代应用程序”来说不是好兆头。

OSS主要由无偿志愿者所提供，因此软件组件可能没有被积极开发或维护，以至于缺陷修复等环节是相对缺失的。此外，造成OSS无法维护的另一个关键因素是，几乎25%的OSS项目只有一个开发者贡献代码，94%的项目由10个或更少的开发者在维护。

显然，如果一个项目只有一个维护人员，风险是显而易见的。考虑到60-80%的现代代码库是由OSS组成的，因此可以说，我们最关键的系统，都是在维护程度最低的软件上运行，这意味着我们随时可能面临重大的系统风险。

应对该风险的建议包括检查项目的活跃性和健康状况，如维护者和贡献者的数量、发布频率，以及补救（MTTR）漏洞的时间等。

许多软件可能正在使用过时的组件。正如Synopsys报告中所引用的那样，这种情况发生在绝大多数代码库和存储库中。

当然，许多现代软件应用程序那令人眼花缭乱的依赖关系使这一问题变得更为复杂了。Sonatype和Endor Labs等组织的报告强调了这一点，后者发表了《依赖性管理状态》，显示95%的漏洞与可传递的依赖性有关。

很多时候，开发人员或组织没有意识到他们使用了特定的依赖项或组件。这可能是因为组织没有使用软件组成分析（SCA）等工具，来了解其OSS的使用情况，或者没有采用软件物料清单（SBOM）等新兴工具，而这些工具可以提供软件组织使用或分发组件的可见性。

这种风险是指组件可能缺乏许可证，或者可能拥有阻碍下游消费者预期使用的许可证。OWASP指出，组织需要确保“他们对OSS组件的使用”，能符合这些组件的适用许可条款，如果不这样做，可能会导致许可证或版权侵权，甚至法律诉讼。

当然，组织可以采取措施，通过确定其软件中使用组件的适用许可，以及组件的预期用途来减轻这些风险。OWASP还建议，各组织除了确定组件何时应用了多个或冲突的许可证外，还应避免使用完全没有许可证的组件。

一些开放源码软件项目可能没有应用安全软件开发实践（如NIST安全软件开发框架（SSDF）中所引用的实践）。其源于许多开发人员对安全性没有兴趣。Linux基金会和哈佛大学创新科学实验室（LISH）的研究发现，开源软件的开发人员只会花2.3%的时间来提高代码的安全性。

幸好有些安全工具可以使用，比如OpenSSF的Scorecard，其为Github中的OSS项目提供了一套强大的检查，如分支保护的存在、贡献者/组织的数量、CI测试、模糊化、维护、许可等。

OWASP将此风险定义为：组件可能在开发人员没有注意到、没有审查或没有批准更改的情况下，发生了更改。推荐的行动和缓解措施包括使用资源标识符来确保指向的是相同的不可变组件。在实际安装和使用组件之前，还可以验证它们的签名和摘要。此外，为了减轻组件在传输过程中被篡改的风险，组织应使用安全的协议进行网络流量的传输和通信。

最后一种情况是组件可能提供的功能非常少或非常多，但其中只有一部分是实际使用的。这通常被称为“软件膨胀”。

在依赖项过小的例子中，由于代码行数有限，组件变得过于依赖上游项目以确保安全。相反，当存在代码膨胀或代码行数呈指数级增长时，组织会引入更大的攻击面和可能被利用的代码/依赖项。

OWASP建议，在这些情况下，应尽可能重新开发所需的功能，以减轻依赖过小或过大组件的风险。同时，我们也看到在云原生容器化环境中，越来越多的人推崇使用“安全基础镜像”，比如Chainguard所倡导的，这些镜像是经过强化的最小基础镜像，几乎没有漏洞。