开源恶意软件：Xygeni 方法

此 发现者 流程获取发布事件的反馈。发布事件是创建新组件或现有组件的新版本。由于流行的注册表不为感兴趣的消费者提供发布-订阅机制，因此这通常是通过轮询注册表以获取最新事件来完成的。 OSSF 的一个优秀项目， 包裹提要，支持 流行的注册中心（如 PyPI 或 Maven Central），并提供统一的基于 feed 的界面。在 MEW 中，我们添加了一些减少等待时间的具体实现，例如使用 NPM 使用的 CouchDB 数据库的副本，该副本与公共注册中心数据库同步。

在 Xygeni，我们有一个库存[1] 我们客户软件使用的所有组件（直接或间接）。客户的组件坐标定期提供给 MEW，以便对分析进行优先排序：我们客户使用的组件会更早处理。优先级还基于发布者的声誉和组件的关键性，因此来自声誉较低的发布者的组件也会被优先处理。

此 分析仪 然后使用优先级队列中的待处理组件。当选择组件版本进行分析时，将从注册表中下载其 tarball。请注意，分析的是打包的二进制组件：大多数开源组件通常来自开源存储库，通常在 github.com，仅用于上下文，并且始终在组件 tarball 中搜索恶意软件，因为威胁行为者系统地谎报他们声称用于构建他们发布的组件 tarball 的来源。 

从用户的角度来看

我听到了你的疑问：尽早了解恶意软件包版本对我有什么好处？在 “恶意软件包剖析：有哪些趋势？” 我们发现总停留时间为几天，而 MEW 向使用受影响组件的客户发出的第一次通知则在几分钟之内。使用简单的护栏[2] 您可以阻止构建（有两个警报级别，一个是当引擎得出存在潜在恶意软件的结论时完全自动化，另一个是当我们的安全团队通过手动检查确认存在恶意软件时发出的后续通知）。由于暴露窗口较长，等到注册表确认恶意软件并将其从注册表中删除通常为时已晚。

该组织可以使用护栏检查是否存在潜在恶意软件的组件（在两个警报级别中的任何一个中），或者通过 API 快速了解软件项目中的任何直接或间接依赖项是否正在使用恶意组件。

MEW 的工作原理：内部细节

核心：恶意软件检测引擎

分析器使用不同的检测器来捕获不法行为的证据。检测器结合了静态分析、功能分析和上下文分析[3]，如本系列上一篇文章所述。 

在 Xygeni，我们拥有一支在静态分析方面经验丰富的工程团队，这是与其他反恶意软件解决方案的主要区别。请注意，对于某些生态系统，打包的 tarball 包含源代码（例如 NPM 包的 JavaScript 或 TypeScript 代码、PyPI 包的 Python 源代码），或与源代码足够接近以进行静态分析的编译代码（例如 Maven 的 JAR 文件中的字节码）。对于其他生态系统（例如容器映像），二进制可执行文件很常见，因此使用功能推断技术，以及基于 YARA 规则和恶意软件签名的常规恶意软件检测。 

请注意，正则表达式或签名等简单技术不适合检测恶意行为。想象一下检测植入程序或下载程序：某些代码或二进制文件位于软件包中或从外部域下载，与组件无关（可能是来自 威胁行为者购买的大量域名[4]，或 合法域名以逃避检测)。然后使用其中一个函数执行该代码。可以转换代码以隐藏下载 URL 或用于运行下载代码的函数。需要使用完整的静态分析机制进行完整的数据流分析才能检测到它，或者在一般情况下，沙盒执行（如果确实满足运行恶意行为的条件）可以检测到这种情况。

威胁行为者采用相同的技术，并为其设计和实施了检测器。还有一些预处理步骤，例如用于消除混淆，这通常需要发现隐藏的行为。 

添加上下文

一些检测器使用上下文信息。例如，组件注册表中的版本与相关 GitHub 存储库中的标签/发布不匹配，这构成了强有力的证据，表明恶意行为者可能获得了注册表的发布凭据，但没有获得 GitHub 存储库的发布凭据。像影响加密钱包供应商的攻击 莱杰 可以通过这种不匹配轻松检测到。

A 恶意评分 (MS) 是根据探测器运行的结果计算得出的，基于捕获的证据的强度。并非所有结果都相同，并且执行顺序也很重要。 

用户和组件声誉

并非所有开源开发人员都是平等的！ 

一位声誉良好的开发者的 NPM 帐户可能会被劫持（即使是有安全意识的人也会遇到这种情况），并且恶意软件会使用该帐户发布。显然，声誉会急剧下降，只有当被劫持的帐户恢复并且开发者修复导致帐户被接管的情况时，声誉才会恢复到过去的辉煌。声誉很难获得，但可能会在一瞬间失去。  

在 MEW，我们实施了一套全面的声誉管理系统，以奖励积极行为并惩罚可疑活动。该系统从新用户开始，保持中立立场，并根据他们正在进行的活动调整他们的声誉。

用户的声誉可以通过积极行动来提高，例如维护活跃的社交媒体账户、启用多因素身份验证、定期为项目做出贡献以及签名 commits 具有可验证密钥。相反，声誉会因发布恶意软件、使用一次性电子邮件地址、不签署 commits，或在贡献中表现出不寻常的模式。

我们系统的主要目标是确保安全和值得信赖的环境。它通过根据各种因素动态调整用户声誉来实现这一目标，同时还尊重隐私问题和不同注册中心的限制。

为用户计算内部信誉分数（尽可能加入注册表和 github 帐户），并与在分析的组件分类期间使用的恶意分数一起，以更好地限定谁属于组件出版物。

发现恶意行为的证据。那又怎么样？人工审核流程

当前分类器根据浓缩调查结果和用户/组件信誉的分数阈值，将所分析的组件版本设置为“已确认恶意”、“可能恶意”、“高风险”、“低风险”或“非恶意”类别之一。分类为“高风险”或“可能恶意”类别会触发人工审核和首次通知。人工审核后或证据与之前已确认恶意的版本的证据相同时，将设置“已确认恶意”类别。 

当有足够的证据表明存在潜在恶意行为时，将向受影响的组织发出第一个警报（隔离警报）。如前所述，这可能会阻止依赖于被隔离组件的软件的安装或构建。 

这在 MEW 内部产生了一个问题 dashboard 因此安全分析师可能会启动组件的手动审查流程。该团队拥有专门的工具（沙盒、反混淆器、恶意软件研究分发、报告恶意软件工具），用于快速评估所调查组件版本的性质。大多数恶意软件（“凤尾鱼”或不复杂的恶意组件）都经过审查  

审查结果如下： 安全因此自动分析引擎发现了假阳性，并将其作为反馈给机器学习分类器来学习模式；或者 已确认恶意，因此在报告流程之后，该组件会负责任地向公共注册表披露为恶意组件。第二份通知会发送给受影响的组织，这些组织可能会 取消隔离该组件，或者彻底阻止它进入其版本升级过程或内部注册表中使用的组件防火墙。

此设置允许我们每天分析数万个新版本，并识别出数十个可能为恶意的版本，然后我们进行手动审核。请记住，从上一集开始，我们目前在野外看到的恶意组件的比例是万分之一。 

向注册处报告

我们发现，大多数公共注册表（开源基础设施的支柱之一）提供的报告安全问题（尤其是恶意组件）的机制相当有限。我们正在努力改进报告流程的底层组织。通常，我们最多会收到注册表安全团队的反馈电子邮件，确认该组件已从注册表中删除。 

有时注册中心会被滥用，违反其使用条款，但不会造成交付的软件出现恶意行为。这种情况也会报告给注册中心，但不会通知组织以限制噪音。