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