OWASP OSS 列表提供了旨在绕过 CVE 目录等滞后指标的建议，并为安全从业者提供了安全使用 OSS 组件的指南。
在最近的一些暴露的漏洞和风险之后，对开源软件 （OSS）的安全和使用方式进行批判性审视的呼声越来越高，特别是 XZ Utils（用于压缩和解压缩 XZ 文件） 事件，揭示了一个后门是如何插入到广泛使用的系统中。
如果没有及时发现，XZ Utils 可能是迄今为止影响最大的软件供应链漏洞之一。尽管它最终没有像 Log4j 那样具有广泛的利用潜力，但它再次敲响了警钟，即现代数字生态系统非常脆弱，需要规范它的使用和保护 OSS 的方式。
为了应对这些事件，网络安全从业人员正在开发一些规范和指南，以帮助完善 OSS 的安全治理和使用方式，包括开放 Web 应用程序安全项目 （OWASP） 中开源软件 （OSS） 的 10 大风险。
OWASP Top 10 最初由 Endor Labs 创建，Endor Labs 是一家软件供应链和应用程序安全公司，专注于 OSS、CI/CD 管道的安全使用和漏洞管理。该项目还得到了paloalto、HashiCorp和花旗银行等行业领导者的支持。
虽然传统上漏洞管理通常以常见漏洞和暴露 （CVE） 列表的形式查看已知漏洞，但人们越来越意识到已知漏洞是风险的滞后指标。
为了完善我们使用开源的方式，需要进行范式转变，以查看风险的领先指标，这些指标可能表明存在与特定开源软件库、组件和项目相关的风险，从整体上考虑，可以帮助更安全地使用开源软件，并减轻漏洞利用的潜在风险。
OWASP的十大OSS开源风险
1: 已知漏洞
本节介绍具有已知漏洞（例如软件缺陷）的 OSS 组件，这些漏洞通常由软件开发人员和维护者无意中引入，然后由社区中的安全研究人员公开披露。
梳理在组织和应用程序中使用这些漏洞组件的上下游关系，表明这些漏洞可能会被利用。虽然这一点可能看起来微不足道，但事实并非如此------未能为开发人员提供信息可能会导致大量额外的工作、时间消耗、挫败感和对安全性的不满。
为了应对这一挑战，我们做出了一些努力，例如 CISA 已知利用漏洞 （KEV） 目录和漏洞利用预测评分系统 （EPSS）。
组织可以采取措施来降低具有已知漏洞的 OSS 组件的风险，例如扫描他们使用的所有 OSS 组件中的漏洞，根据已知漏洞利用、利用概率、可访问性分析（最多可减少 80% 的噪声发现）等方法对发现结果进行优先级排序。
2：合法软件包风险
在十大开源软件风险列表中，下一个是合法软件包风险。恶意行为者意识到破坏合法软件包以影响下游消费者的价值，无论是在组织上还是在个人上。
他们可以使用多种方法来追踪这种攻击媒介，例如劫持项目维护者的帐户或包存储库中的漏洞。
他们也可以自愿成为维护者，只是为了追求他们的邪恶意图。这正是最近 XZ Utils 事件中发生的事情，因为在代码中嵌入后门之前，有人在很长一段时间内冒充合法贡献者。
减轻这种风险的建议包括使用新兴的资源和指导，如Microsoft（现在捐赠给OpenSSF）的安全供应链消费框架（S2C2F），现在业内还有其他几个类似的框架。
3：名称混淆攻击
在名称混淆攻击中，攻击者创建名称类似于合法 OSS 软件包或组件的恶意组件，希望它们会被潜在受害者无意中下载和使用。此类攻击也出现在 CNCF 软件供应链攻击目录中，包括域名抢注和品牌劫持。当这些被入侵的软件包被引入组织的 IT 环境时，它们可能会影响系统和数据的机密性、完整性和可用性 （CIA）。
4：未维护的软件
与专有软件不同，开源软件的一个严酷现实是没有"供应商"。这意味着无法保证软件将得到维护、更新或维持。
Synopsys 的 OSS 报告等报告表明，85% 的被评估代码库的 OSS 组件已经过时了四年以上，并且两年内没有任何新的开发。
考虑到软件老化迅速，并且根据年度 NVD 指标，新漏洞正在以创纪录的速度出现，这对于使用未主动更新的 OSS 组件的现代应用程序的安全性来说并不是一个好兆头。
开源软件主要由无偿志愿者提供支持。软件组件可能不会被积极开发或维护，缺陷的修复可能不会发生，或者即使有，也可能不在使用组件的软件消费者所期望的时间表上，也不符合专有供应商关于与下游客户的漏洞修复的 SLA。说到OSS组件，如果你使用它，你就存在这个问题。
另一个导致开源码软件未维护的关键因素是，近25%的开源软件项目只有一个开发人员贡献代码，94%的项目由10个或更少的开发人员维护，正如研究员Chinmayi Sharma在她的出版物 "A Tragedy of the Digital Commons" 中引用的那样，对于那些想要全面了解开源挑战的人来说，这是一本推荐的读物。
这通常也被称为"公交车因素"，本质上是问"如果某某被公交车撞到会有什么影响？如果一个项目只有一个维护者，风险是显而易见的。考虑到 60-80% 的现代代码库是由开源软件组成的，人们开始意识到，我们的数字生态系统的很大一部分，甚至是我们最关键的系统，都在支持和维护不足的软件上运行 --- 这代表了重大的系统性风险，可能被利用。
报告中提到的处理此风险的建议包括检查项目的活跃度和健康状况，例如维护者和贡献者的数量、发布频率和即时修复 （MTTR） 漏洞。
5：过时的软件
在这种情况下，尽管可能存在较新的版本和更新，但项目正在使用组件的过时版本。正如 Synopsys 报告中所引用的，这种情况实际上是常态，发生在绝大多数代码库和存储库中。
当然，由于许多现代软件应用程序和项目所具有的复杂而令人眼花缭乱的依赖项列表，这让管理变得复杂。Sonatype和Endor Labs等团体的报告强调了这个问题，后者发表了"依赖管理状态"，表明95%的漏洞与传递依赖关系有关。
6：未跟踪的依赖项
在这种情况下，开发人员/组织不知道他们使用了特定的依赖项或组件。这可能是由于组织没有使用软件组合分析 （SCA） 等工具来了解其 OSS 使用情况，或者没有采用软件物料清单 （SBOM） 等新兴工具，这些工具提供了组织使用或分发的软件中组件的可见性。
这实际上是更广泛地推动 SBOM 和软件供应链安全的一部分，因为业界通过 SolarWinds 和 Log4j 等事件意识到，尽管软件资产库存多年来一直是 SANS/CIS 的关键控制措施，但大多数组织都缺乏全面的软件资产清单。SBOM 希望通过让组织开始处理其作为企业的组件库存来解决这个问题。
7：许可证和监管风险
这种风险是指组件或项目可能缺乏许可，或者可能具有阻碍下游消费者预期用途的许可的情况。
OWASP指出，组织需要确保其对OSS组件的使用符合这些组件的适用许可条款。如果不这样做，可能会导致许可或版权侵权，甚至法律诉讼。
这可能会影响组织的业务目标、并购活动等，因为组织在其专有产品、服务和产品中更广泛地使用 OSS 组件。
组织可以通过确定他们在软件中使用的组件的适用许可以及他们对组件的预期用途来采取措施来降低这些风险。该报告还建议组织避免使用完全没有许可的组件，此外还要确定组件何时应用了多个或冲突的许可证。
8：软件不成熟
并非所有软件都是同时创建的，当然，就成熟度而言，它们都存在一个范围，其中很大原因是维护者的参与程度不同。
某些 OSS 项目可能没有应用安全软件开发实践（例如 NIST 安全软件开发框架 （SSDF） 中引用的实践）。具体示例可能包括没有文档、缺乏回归测试、没有审查指南和许多其他最佳实践。
还有一个令人不安的现实是，许多开发人员对安全性不感兴趣。Linux基金会和哈佛大学创新科学实验室（LISH）所做的研究发现，自由和开源软件开发人员仅花费2.3%的时间来提高代码的安全性。
也有行业的努力和工具可用，如OpenSSF的记分卡，它为Github中的OSS项目提供了一套强大的检查，如分支保护的存在、贡献者/组织的数量、CI测试、模糊测试、维护、许可等等。另一个类似的工作涉及CISA和OpenSSF，被称为 "包存储库安全原则"。
9：未经批准的更改（可变）
OWASP 将这些定义为组件可能在开发人员未注意到、审查或批准更改的情况下进行更改的情况。这可能发生在下载链接更改或指向未版本控制的资源，甚至是被篡改的不安全数据传输的情况下，这强调了安全传输的作用。
建议的操作和缓解措施包括使用资源标识符进行保证，并指向相同的不可变项目。您还可以在实际安装和使用组件之前验证组件的签名和摘要。此外，为了降低组件在传输过程中受到损害的风险，组织应使用安全协议来传输和通信网络流量。
10：依赖项过小/过大
最后，组件可能提供很少或很多功能，其中只有一部分被实际使用。这通常被称为"软件膨胀"。
在尺寸过小的依赖项示例中，由于代码行有限，组件依赖于上游项目以确保安全性。另一方面，如果你的代码膨胀或代码行数呈指数级增长，你最终会带来增加的攻击面和潜在的可利用代码/依赖关系，尽管这些代码实际上并不需要。
该报告建议，在这些情况下，重新开发内部所需的功能，以降低依赖依赖项不足或过大的风险。我们还看到，在云原生容器化环境中，人们正在推动利用 Chainguard 等领导者所宣传的"安全基础镜像"，这些基础镜像是最小强化的基础镜像，漏洞有限甚至没有漏洞。
来源：csoonline