新增传递依赖中嵌入可执行文件的奇特案例

目录

摘要

这是一个关于在常规依赖升级过程中作为传递依赖引入的新开源软件包的故事。该软件包因包含嵌入式可执行文件而被标记为可疑。然而，手动分析确认它并非恶意软件。此事件凸显了一个事实：任何软件中大量的代码都是通过开源软件供应链引入的，特别是通过下游软件消费者实际无法控制的传递依赖。问题仍然存在：

如何信任作为任何软件重要组成部分的开源代码

发现

在 SafeDep，我们使用自己的产品进行内部测试。最近，我们推出了用于防护恶意开源软件包的 GitHub App。在进行常规依赖升级工作时，我们在 Pull Request xbom/51 中发现了一个非常有趣的现实案例。GitHub App 标记了一个可疑的软件包。

点击放大

分析

经进一步检查，github.com/clipperhouse/stringish @ v0.1.1 Go 模块被标记为可疑。该 Pull Request 涉及以下有意的更改：

• 使用 Dockerfile 进行 Go 依赖升级
• Dockerfile 基础镜像更新为 Go 1.25.2 构建器镜像

注意：相关 Pull Request 可在 xbom/51 查看

可以确定没有刻意添加新的依赖。当一个未知依赖被标记为可疑时，我们几乎可以确定它是一个传递依赖。首要任务是识别引入该 Go 模块的软件包关系链。

输出显示了依赖图中引入 github.com/clipperhouse/stringish 的路径

快速 git diff 确认最后两个依赖是新引入的：

但 github.com/mattn/go-runewidth 的版本已更新

此时，很明显该依赖变更是在 github.com/mattn/go-runewidth 软件包的 v0.0.16 和 v0.0.19 之间引入的。我们确认了这一点：

github.com/rivo/uniseg，一个拥有 600+ 星标和 8 位贡献者的项目，被替换为 github.com/clipperhouse/uax29，后者由个人开发者构建和维护。github.com/clipperhouse/uax29@v2 又依赖于 github.com/clipperhouse/stringish，一个仅在两周前发布的软件包。

虽然单一开发者项目本身不是漏洞，但最近发布且版本较少的软件包被包含在传递依赖中，符合我们过去在各种开源软件供应链攻击中看到的常见攻击者战术、技术和程序（TTP）。

下图描述了可疑软件包的引入路径。

点击放大

为何被标记？

自动分析报告可在此处获取。该软件包被标记为可疑的关键原因：

1. 最近发布的软件包，版本较少
2. 嵌入式可执行文件 github.com/clipperhouse/[email protected]/utf8/utf8.test

这是恶意软件吗？

不是。github.com/clipperhouse/[email protected] 不是恶意软件。我们通过以下方式确认：

1. 使用 xbom 扫描程序功能
2. 手动源代码审查

首先，xbom，一个通过静态代码分析检查代码功能（如进程执行）的工具，未发现任何危险代码功能。手动分析也未发现对 utf8.test 文件的任何引用。事实上，完全没有找到对 utf8.test 文件的任何引用，因此提出了 stringish/issues/1 来讨论从 Go 模块仓库中移除二进制可执行文件的可能性。

结论

这不是恶意软件包的案例。但此事件与我们过去分析过的多个恶意软件包相似，例如 llm-oracle 恶意 npm 软件包。实际上，引入未使用的二进制软件包或可执行文件类似于 xz 事件中的维护者主导攻击模式。

虽然没有证据表明此案例存在恶意意图，但事实是，当今开源代码是以隐含信任的方式被采用的。这种行为正被利用来通过开源软件供应链引入恶意代码。虽然代码分析仍然是防范此类攻击的可靠方法之一，但这种分析有其局限性。软件开发团队需要意识到这种风险，并采取适当措施保护自己。

参考

• https://github.com/clipperhouse/stringish/issues/1

• https://github.com/safedep/xbom/pull/51

• xbom

• golang

• sca

SafeDep 博客最新内容

关注以获取开源安全与工程的最新更新和见解