软件供应链管理公司Sonatype发布的一份最新报告显示，涉及恶意第三方组件的供应链攻击数量在过去一年增加了633%，目前已知的案例超过8.8万起。与此同时，软件组件从其自己的依赖项继承而来的传递性漏洞实例也达到了前所未有的水平，并影响着三分之二的开源库。
Sonatype在其最新发布的《软件供应链现状报告》中表示，“依赖项的网络性质突出了了解和可视化这些复杂供应链的重要性。这些依赖项会影响我们的软件，因此了解它们的来源对于漏洞响应至关重要。然而，许多企业并不具备必要的可视性流程，因此一直深受供应链攻击的影响，如Log4Shell事件等。”
Log4Shell是2021年11月在Log4j中发现的一个关键漏洞。Log4j是一个广泛流行的开源Java库，用于记录日志，并被捆绑在数百万企业应用程序和软件产品中，通常作为间接依赖项。Sonatype的监测数据显示，截至2022年8月，固定版本Log4j的采用率约为65%。更糟糕的是，这甚至还没有考虑另一个事实，即Log4Shell漏洞起源于一个名为JndiManager的Java类，它是Log4j-core的一部分，但也被783个其他项目借用，目前已在超过19000个软件组件中被发现。
可以说，Log4Shell事件是一个分水岭，它强调了开源软件生态系统——这是现代软件开发的核心——中存在的固有风险，以及正确管理这些风险的必要性。它还推动了由私人组织、软件存储库管理人员、Linux基金会和政府机构发起的多项软件供应链保护倡议。然而，事实证明，在开源供应链管理方面，大多数企业还远远没有达到他们需要实现的水平。
开源消费持续增长
从顶级组件存储库——Maven Central(Java)、npm(JavaScript)、PyPi(Python)和NuGet (. net)——下载的包的平均年增长率为33%。随着这一数字明显低于前几年，例如2021年73%的增长，但所有存储库的组件下载数量已经超过2021年的数字，总计超过3万亿。仅npm存储库今年提供的下载量，就超过了所有四个存储库在2021年提供的下载量。
开源消费速度的放缓是正常的，这并不一定是因为用户实施了更严格的开源采购和管理政策，而是考虑到不同编程语言的生态系统已经达到的规模，以及它们增加新项目和发布的速度。
Sonatype总结道，“尽管开源消费增长速度正在放缓，但增长的绝对规模仍在前一年的基础上继续增加。开源应用的步伐在短时间内没有任何放缓的迹象。”
供应链攻击的类型多样化
截至去年年底，Sonatype追踪了大约1.2万起已知的恶意供应链攻击事件，现在这一数字已超过8.8万起，同比增长633%。该公司还发现了97334个以各种不同方式分发的恶意软件包。
恶意软件包增长的主要原因之一是一种名为依赖项混淆(dependency confusion)的攻击技术，该技术于2021年2月由安全研究人员公开披露，自那以来便得到了广泛应用。该技术利用大多数软件包管理客户端的行为，配置为在公共社区存储库和内部存储库中搜索包。
当两个位置都存在包名时，客户端将拉入版本号较高的包名。这导致了一个问题，因为许多企业使用内部开发的软件包，这些包只存在于他们的内部存储库中，从来不打算公开发布。但是，如果攻击者从清单文件中找到了这些包的名称，他们就可以在公共存储库中发布带有这些名称的恶意包，并使用更高的版本号来欺骗软件构建客户端。
很难说是否所有依赖项混淆攻击的实例本质上都是恶意的，因为该技术在渗透测试人员中也很流行。但是，企业可以通过在公共存储库中注册私有包的名称或为所有包使用前缀来保护自己，然后可以将这些前缀注册为公共存储库中的名称空间或作用域，这意味着攻击者应该不再能够发布带有这些前缀的包。
另一种众所周知的大规模攻击是typosquatting(通过输入错误触发攻击，如误植域名等)和品牌劫持(brandjacking)。typosquatting指的是攻击者注册恶意包，其名称与一些流行和广泛使用的包的名称相似。这是一种被动攻击，依赖于开发人员在构建脚本或命令中输入包名时犯的拼写错误。
品牌劫持与此类似，但针对的是其他软件包维护者，希望他们在自己的组件中包含一个被劫持的或拼写错误的包作为依赖项。当合法包的维护者将所有权转让给其他人时，或者当他们停止开发该包并删除它，旧的名称变为可用时，也会发生这种情况。
恶意代码注入是另一种更具针对性的技术，它涉及攻击者破坏开发人员的系统或代码存储库，并在开发人员不知情的情况下将恶意代码注入到他们的包中。当软件包维护人员向多方提供对其代码存储库的访问权限，而这些方要么怀有恶意，要么遭到攻击时，也会发生这种情况。
另一种类似于恶意代码注入，但由合法开发人员实施的攻击类型称为“抗议软件”(protestware)。它指的是开发人员将恶意代码添加到他们自己之前干净的包中作为抗议的标志。
选择具有良好安全实践的组件
构建和维护跨所有内部软件开发工作使用的组件清单，并跟踪其中发现的漏洞，这是降低安全风险的一个关键步骤。但是，围绕组件来源制定明确的策略同样重要。选择自己代码中漏洞发生率低的组件或库并非一个好主意，因为其中许多组件或库可以从自己的依赖项继承漏洞，因此它们响应此类漏洞和更新自己的依赖项所需的时间非常关键。
Sonatype分析了一组超过12000个在企业应用程序中常用的库，发现其中只有10%的库在其代码中直接存在漏洞。然而，当包括从依赖项继承的传递性漏洞以及这些依赖项的依赖项时，漏洞发生率就上升至62%。平均而言，每个库有5.7个依赖项。
另外，从长远来看，基于低漏洞率选择组件并不一定会转化为更好的安全结果，因为研究人员在选择他们想要仔细检查的项目时存在很大的偏见。换句话说，受欢迎的项目可能有更多的漏洞被发现，因为有更多的人关注它。
Sonatype的研究人员表示，“由于大多数漏洞来自于传递性依赖项，因此最明确的建议是仔细考虑您使用的每个库。此外，偏爱依赖树较小的软件;寻找那些在其依赖项的新版本发布时能够快速更新的项目(即较低MTTU-平均更新时间)。最小化依赖项的总数，以及为自己的项目依赖项保持较低的更新时间，是降低传递性漏洞风险的两个关键因素。”
目前，有多种度量标准可以用来判断开源项目的安全实践。其中之一是由开源安全基金会(OpenSSF)开发的安全记分卡系统。该系统执行一系列自动审查，以检查开源项目是否有未修复的漏洞、是否使用工具帮助更新其依赖项、是否运行CI测试、是否运行自动代码模糊化、是否使用静态代码分析工具、是否避免危险的编码实践、是否在合并新代码前执行代码检查等等。
Sonatype使用它自己的数据来评估这些实践对降低项目漏洞几率的影响，并发现影响最大的操作是代码审查、避免危险的编码实践(分支保护)以及审查代码提交等等。
企业对他们的开源实践表现得过于自信
Sonatype对662名企业工程专业人员进行了调查，询问了他们使用开源组件、依赖项管理、治理、批准流程和工具的40个问题。根据Sonatype的评估，大多数反馈都表明供应链管理水平低于产生高质量结果的要求。
调查显示，得分最高的是补救和应用程序清单类别。例如，68%的受访者表示，他们确信其应用程序没有使用已知的易受攻击的库，84%的人称他们会仔细检查自己使用的开源组件的安全历史。然而，这与Sonatype在实践中的发现并不一致，Sonatype对随机选择的55000个企业应用程序的扫描显示，其中68%的应用程序存在已知的漏洞。
研究人员介绍称，“我们利用了调查期间收集的人口统计数据，并按职位划分了结果。研究结果很有启发性。人们总是倾向于从更好的角度看待事物，与其他角色相比，管理者报告的成熟阶段更高。在整个调查范围内，当比较IT管理者和从事信息安全工作的人员时，这种差异在统计上是非常显著的。”
