软件项目常常依赖于未被明确记录的预编译二进制包，形成了“幽灵二进制依赖”。这种隐形的依赖关系对开源生态系统的可持续性和软件安全构成了严重威胁，尤其影响到医院和交通等关键基础设施。解决方案在于开发能够识别和记录这些依赖关系的工具，并推动包管理系统的改进，最终实现依赖关系的完全透明化，以保障技术基础设施的稳定与安全。
什么是幽灵二进制依赖？
当你创建一个软件包时，你可能会依赖其他软件包的源代码。这种依赖关系通常会记录在清单文件（如 pyproject.toml 或 package.json）中。
然而，有时你会依赖于预编译的二进制文件，例如在 Python 等语言中调用 C 语言等已编译的代码。
在几乎所有的生态系统中，追踪二进制依赖都非常困难。当你依赖一个包的预编译二进制文件时，这些信息通常不会被记录在任何地方。
这意味着你的项目与你所依赖的二进制文件之间的关系是隐藏的，我们称之为幽灵二进制依赖。
为什么这是一个重要问题？
幽灵二进制依赖主要带来两大风险：可持续性和安全性。如果我们无法可靠地识别这些依赖，我们的技术基础设施将面临威胁。
可持续性风险：开源项目的维护者因缺乏资金支持而面临职业倦怠。如果我们不知道自己依赖了哪些二进制包，就无法向其背后的维护者提供支持。这会危及整个开源生态系统的健康发展。
安全风险：如果你依赖的库存在安全漏洞，你的项目也会变得脆弱。如果你对自己的依赖关系没有清晰的了解，就无法掌握可能影响你的安全漏洞。对于支持医院、交通系统和互联网等关键基础设施的软件来说，这种漏洞会将公众置于危险之中。
我们该如何解决这个问题？
解决这个问题需要大量工作，但我们可以通过构建工具和进行系统性变革来纠正这些问题。
首先，我们应该创建能够为各种软件包识别和记录二进制依赖的工具。这能为维护者、安全研究人员和其他相关方提供所需的信息，以制定更稳健的解决方案。
获得这些信息后，我们可以着手解决其他问题：
- 如何确保二进制依赖总是来源于合适的包管理器，以便它们能够及时获得安全补丁？
- 如何确保不同类型的包管理器（如语言包管理器和系统包管理器）能够协同工作，就整个依赖图中的安全问题向开发者发出警告？
相关资源与正在进行的工作
以下是一些有助于了解更多信息或参与此项工作的资源：
- bindep repository: 记录了正在进行中的相关代码和笔记。
- The Open Source Pledge: 一项旨在让公司为他们所依赖的开源维护者付费的倡议。
- C-Shaped Hole in Package Management: Andrew Nesbitt 发表的一篇关于二进制依赖问题的精彩文章。
- Dependency Resolution in Python: Beware The Phantom Dependency: Anand Sawant 的文章，最早提出了“幽灵依赖”这个术语。
- auditwheel: 一个广泛使用的 Python 包，可以识别 wheel 文件所需的动态库。
- elfdeps: 一个较少人知的 Python 包，可以识别 wheel 文件所需的动态库并提供公共 API。
- PEP 770: 引入了在 Python 包中使用 SBOM（软件物料清单）的提案，有助于发现二进制依赖。
- PEP 725: 指定了一种在
pyproject.toml中记录二进制依赖的方法。 - PEP 804: 指定了一个将二进制依赖名称映射到非 Python 注册表中包的系统。
- ESSTRA: 索尼开发的一种工具，旨在通过在二进制文件中嵌入元数据来提高供应链透明度。
- Fromager: 一款旨在让 Python 包完全从源代码构建的工具，包括其所有二进制依赖。
- UAPI 规范: 提供了在 ELF 二进制文件中记录动态库来源（如其源自的系统包名称）的方法。
- Insight: Exploring Cross-Ecosystem Vulnerability Impacts: 一篇学术论文，描述了一个用于识别 Python 代码何时调用已知存在安全漏洞的 C 库的系统。
- The PURL registry: 一个 C/C++ 包的注册表，可用于为二进制依赖分配可靠的身份。