根据软件供应链管理公司 Sonatype 的最新报告，恶意软件正以前所未有的速度侵入开源软件的开发生态系统。自2023年11月以来，该公司在流行的Java、JavaScript、Python和.NET注册包中追踪到了超过50万个新的恶意软件包。

自从2019年以来，该公司在其年度《软件供应链状况报告》中持续追踪大约70万个恶意软件包的数据。在这些被追踪的恶意软件中，超过70%是新出现的恶意组件。

这一波恶意软件的兴起，无疑增加了企业在筛选并整合至应用中的开源组件方面的难度。据Sonatype数据显示，每个企业的应用程序平均包含超过180种不同的第三方组件，这使得管理工作变得更加复杂和具有挑战性。

结果显示，超过80%的易受攻击应用程序依赖项在过去一年多时间里未进行修补，尽管95%的应用程序依赖项存在更安全的替代方案。即使应用了更新，在3.6%的情况下，也会被更新为不安全版本。

以Log4j为例，2021年12月，一款广泛应用于数百万个应用程序中的Java日志记录工具——Log4j被发现存在一个名为“Log4Shell”的高危漏洞。这一漏洞在随后引起了大量关注，但在近三年后，尽管许多组织已更新其软件版本以规避缺陷，但据Maven Central Java库的统计显示，下载的log4j版本中仍有13%是易受攻击的版本。

根据 Sonatype 的报告：“为了应对开源风险的增加并跟上新 OSS 库的快速发展，需要对安全策略和实践进行优化。然而，一些组织发现他们正在减慢 DevOps 流程以手动审查漏洞，这种做法不仅效率低下，而且导致开发人员感到沮丧。”

01

损恶意软件可能导致供应链受

与针对PC上的恶意软件一样，上传到开源存储库的恶意组件可能用于不同的目的，并且不是所有组件都具有同样的影响。

根据Sonasystem的分类，将近一半的恶意组件被归类为“潜在有害应用程序”（PUA）。大多数这些应用程序在实际应用中并无害处，但由于其功能未向用户公开，因此被视为有潜在风险。这其中就包括了一些抗议软件，这类软件的创建者在其组件中加入了抗议信息或行动，以引起他人的关注。

另外有12%的软件被归类为“安全保留包”，这表明在某个时刻，生态系统维护者曾将其标记为恶意的软件。为了吸引用户的注意，他们用无害的占位符替换了这些软件中的恶意代码部分。

后果确实很严重，可能会影响到整个供应链的安全。据统计，约有14%的软件是通过网络钓鱼的方式传播的，这些软件往往通过伪造依赖关系迷惑开发环境，进而在该环境中植入更多的恶意程序。

大约14%的恶意软件目的是窃取敏感数据，例如环境变量、认证令牌及密码文件等，这些资料可用于日后进一步攻击其他系统。而3%的恶意软件则专门针对个人信息（PII）进行盗窃；另外3%的恶意程序包内含后门和特洛伊木马，用以在计算机上执行潜藏式破坏任务。

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

一些近期不受欢迎的软件包事件包括：一名开发者向NPM上传了大约14,000个假软件包，以从奖励开源贡献的加密货币计划中获利；攻击者利用拼写错误劫持（typosquatting）推送一个与流行库名称非常相似的Python软件包，该软件包部署了Lumma Windows窃取器；以及ZX Utils后门，这是恶意开发者长期渗透合法项目并投毒代码的一个案例。

传统上，针对恶意软件的扫描解决方案往往难以识别这些新型攻击形式，这使得开发人员及其在DevOps环境中面临着特殊的风险。Sonatype的研究人员指出：“随着这种新威胁的不断涌现，相关组织面临的潜在风险和现实挑战也将持续升级。”

02

某些漏洞信息不可靠

根据 Sonatype的研究结果，每个企业应用平均每年会收到13个由依赖关系继承而来的严重或高严重性安全漏洞。这意味着企业在管理和保护其应用时，不仅需要跟踪所有直接和间接依赖项（即依赖关系的依赖），还需要自动化工具来帮助识别和管理这些潜在的安全威胁。此外，不同来源的漏洞信息可能存在差异，这也增加了企业在应对安全挑战时的复杂性和难度。

例如，国家漏洞数据库（NVD）已经积累了超过17,000个未处理的漏洞。Sonatype在实际操作中发现，在进行更详细的安全审查后，那些最初被评为CVSS严重性评分低于7的漏洞中，有超过三分之二被重新评估为7分及以上（即高或严重级别）。

所以，如果公司依赖的漏洞信息源有误，就可能遗漏真正的安全威胁，或者延迟修复这些漏洞，错误地低估它们的严重性。如果一个漏洞的评分在应用程序评估后被改变，很难说多久之后它会被再次扫描。

“通过专注于帮助管理依赖项和应用实时漏洞检测的工具，可以减少持续的风险，”研究人员写道。“实际上，我们发现使用软件物料清单（SBOM）来管理开源软件（OSS）依赖项的项目，与那些没有使用的相比，修复时间减少了264天。”

软件物料清单（SBOM）标准的推广得到了政府的法规支持，这促使更多的开源开发者采纳这一标准。然而，尽管新发布的组件数量激增至近700万，但采用SBOM的开源组件仅占极小比例，约61,000个。

一个令人不安的趋势是，无论漏洞的严重程度如何，修复漏洞的平均时间都在增加。严重漏洞的平均修复时间曾经在200到250天之间，但现在在某些情况下已经超过500天。高严重性漏洞的修复时间已从150到300天延长到超过400天；低严重性缺陷现在的修复时间为500到700天，有些甚至延长到800天。

研究人员说：“这一急剧的变化使发布者不堪重负，他们需要在确保安全性不断提升的同时，持续进行技术创新并开发新的功能。”