开源开发生态系统中的恶意软件组件显著增加，这使得企业高度警惕软件供应链攻击。

　　据软件供应链管理公司Sonatype发布的一份新报告显示，恶意软件正以惊人的速度渗透进开源软件开发生态系统。自2023年11月以来，该公司已在流行的Java、JavaScript、Python和.NET软件包注册中心追踪到超过50万个新的恶意软件包。

　　自2019年Sonatype首次在年度《软件供应链现状报告》中纳入这一统计数据以来，公司已追踪到约70万个恶意软件包，其中新出现的恶意组件占比超过70%。

　　这波恶意软件的泛滥，加剧了企业在选择集成到应用中的开源组件质量方面所面临的挑战。据Sonatype的数据显示，平均每个企业应用都至少包含180个第三方组件，这一数量管理起来颇具挑战性。

　　因此，Sonatype发现，尽管95%的漏洞有更安全的替代方案，但超过80%的易受攻击的应用依赖项在一年多的时间里仍未得到修补。即使在应用了更新的情况下，仍有3.6%的易受攻击依赖项被更新到了其他不安全的版本。

　　以Log4j为例。这个被数百万个应用使用的Java日志记录库，在2021年12月发现了一个被称为Log4Shell的严重漏洞。该漏洞及其后出现的几个漏洞都受到了广泛关注，但近三年后，从Maven Central Java存储库中下载的log4j中，仍有13%是易受攻击的版本。

　　Sonatype在报告中写道：“管理开源风险需要优化安全策略和实践，以跟上新OSS库快速发展的步伐。企业很难为了进行手动漏洞审查而放慢DevOps流程，这导致开发人员感到沮丧。”恶意软件可导致供应链遭受攻击

　　与针对台式机的恶意软件一样，上传到开源包存储库的恶意组件可能服务于不同的目的，并非所有恶意组件都具有相同的影响。

　　Sonatype将近一半的恶意组件归类为“可能不需要的应用”（PUA）——这些组件在实践中大多是无害的，但其功能未向最终用户披露。这包括抗议软件，即组件的创建者在其中包含抗议信息或旨在引起对其所关心问题的关注的行动。

　　另有12%的组件被标记为“安全保留包”，这意味着生态系统维护者曾在某个时刻将其标记为恶意，并用干净的占位符包替换它们，以引起使用这些包的人的注意。其余的恶意组件则具有可能导致供应链遭受攻击的严重后果。约14%的恶意软件包通过钓鱼技术分发，即利用依赖项混淆来冒充组织内部使用的软件包，以便在开发系统上进一步植入恶意软件。

　　约14%的恶意软件包旨在从机器上窃取敏感文件和数据，如环境变量、身份验证令牌、密码文件和其他可能帮助攻击者日后攻破更多系统的信息。其中3%的软件包还针对个人身份信息（PII），另有3%的软件包在机器上部署后门和木马。

　　其他类型的恶意行为包括植入加密货币挖矿程序（1.2%）、破坏文件系统或危及开发人员用于编写代码的IDE工具或持续集成平台。

　　近期发生的一些不良软件包事件包括：一名开发者为了从奖励开源贡献的加密货币计划中获利，向NPM上传了约14,000个虚假软件包；攻击者利用拼写劫持技术推送了一个名称与热门库极为相似的Python软件包，该软件包部署了Lumma Windows窃取器；还有ZX Utils后门事件，这是一个恶意开发者多年来对合法项目进行渗透攻击的例子，目的是篡改代码。

　　Sonatype研究人员写道：“传统恶意软件扫描解决方案无法检测到这些新型攻击形式，导致开发者和DevOps环境面临独特的风险。随着攻击数量的持续增长，组织所面临的明确且紧迫的危险也将随之增加。”

　　部分漏洞信息不可靠

　　Sonatype发现，每个企业应用程序平均每年会从依赖项中继承13个严重或高严重性的漏洞。除了需要自动化工具来跟踪所有直接和间接依赖项（即依赖项的依赖项）以及其中发现的漏洞外，漏洞信息的来源也不尽相同。

　　例如，国家漏洞数据库（NVD）中仍有超过17,000个漏洞尚未处理。Sonatype在实际操作中发现，当安全研究人员对漏洞进行更详细的审查时，原本根据CVSS评分标准被评为7分以下（中等）的漏洞中，有超过三分之二被修正为7分以上（高或严重）。

　　因此，根据公司所使用的漏洞信息来源，他们可能会完全忽略某些漏洞，或者认为这些漏洞不那么关键而推迟处理。如果应用程序评估后漏洞评分发生变化，则很难确定需要多长时间才会再次进行扫描。

　　研究人员写道：“通过关注有助于管理依赖项并应用实时漏洞检测的工具，可以降低持续风险。事实上，我们发现使用软件物料清单（SBOM）来管理开源依赖项的项目，与未使用的项目相比，修复时间缩短了264天。”

　　SBOM标准的推广和政府相关规定的强烈鼓励，已经促使越来越多的开源开发者采用SBOM。然而，采用速度并未跟上新组件的发布速度。在过去12个月中，发布了近700万个新的开源组件，其中只有61,000个附有SBOM。

　　一个令人担忧的趋势是，无论漏洞的严重性如何，修复漏洞的平均时间都在不断增加。关键漏洞的平均修复时间过去在200至250天之间，但现在某些情况下已超过500天。高严重性漏洞的修复时间从150至300天延长到400多天；低严重性缺陷的修复时间现在为500至700天，部分甚至达到800天。

　　研究人员表示：“这一急剧增加表明，发布者不堪重负，难以同时应对大量的安全问题以及持续的创新和功能开发需求。”