在布鲁塞尔举行的 FOSDEM 2026 上，开发者兼研究者 Vlad-Stefan Harbuz 抛出了一个对大多数工程团队都不太体面的事实：我们自以为知道自己依赖了什么，很多时候其实并不知道。那些被 Python、Node.js 或其他语言包装起来的预编译二进制库，往往没有出现在项目的依赖清单里，却真实地参与了运行、承载了漏洞风险，也消耗着维护者的时间。
这件事真正重要的地方，不在于“依赖管理又多了一个术语”，而在于它戳穿了今天软件供应链治理里的一个假设——只要 SBOM、锁文件和漏洞扫描做全了，企业就能看清风险。Harbuz 讨论的“phantom binary dependencies（幽灵二进制依赖）”说明，现实没这么整齐：源码依赖可见，二进制依赖常常隐身，而医院系统、交通平台、互联网服务跑的正是这种混合栈。
幽灵依赖不是边角料，它是供应链台账里的缺口
Harbuz 的定义很直接：项目依赖了别人的预编译二进制，但这种关系没有被清楚记录。典型场景是 Python 调用 C 库，或者一个语言生态把底层动态库打包进 wheel、插件或扩展模块里。源码依赖通常写进 pyproject.toml、package.json，二进制依赖却可能只存在于构建产物中，开发者直到出漏洞、编译失败或跨平台崩溃时才发现它的存在。
这不是理论问题。论文《Insight: Exploring Cross-Ecosystem Vulnerability Impacts》给出过一个扎眼的数据：24.0% 的 PyPI 项目会传递性调用存在漏洞的 C 库 API。这个比例说明，语言层“看起来安全”并不等于底层库也安全。我的判断是，今天不少企业采购的软件成分分析工具，能把源码世界画得很漂亮，但一旦跨到 C/C++、系统动态库、dlopen() 这类边界，视野就开始发虚。
安全只是其中一半，另一半是钱该付给谁
Harbuz 把问题拆成两部分：安全和可持续性。前者好理解，依赖关系看不见，漏洞预警就会漏报；后者更少被讨论。现在企业开始接受“开源不能只白嫖”，Open Source Pledge 截至文中写作时已向开源开发者支付 6,879,498 美元，思路是按依赖关系给关键维护者付钱。问题在于，如果底层真正撑起业务的二进制包根本没被识别出来，资金分配就会天然偏向“台面上的包”，而不是最辛苦、最关键的那层维护者。
这也是原文里最有现实感的一点：看不见的依赖，不只意味着看不见的漏洞，也意味着看不见的人。很多团队愿意为“关键基础设施”买单，但财务要做预算、法务要审对象、工程团队要给出可追踪清单。没有记录，这些动作都落不下去。开源维护者的倦怠问题，最后不是停在 GitHub issue 区，而是会沿着供应链传导到企业运维和公共服务。
从 Python 到 Linux 发行版，谁在补这个洞，谁还补不上
围绕这个问题，行业已经有一些零散工具和标准，但离“可用的全景图”还差得远。
| 方案/项目 | 主要作用 | 现在能解决什么 | 现实限制 |
|---|---|---|---|
| auditwheel | 分析 Python wheel 的动态库需求 | 在 Python 生态里识别部分二进制依赖 | 输出不够友好，研究和自动化接口仍有限 |
| PEP 770 | 把 SBOM 引入 Python 包 | 让包作者带上更完整的软件成分信息 | 依赖作者配合，历史包不会自动补齐 |
| PEP 725 | 在 pyproject.toml 记录外部二进制依赖 | 给“依赖可见化”一个标准入口 | 标准有了，不等于生态会立刻采用 |
| PEP 804 | 把二进制依赖名映射到非 Python 注册表 | 帮助跨生态定位真实包身份 | 映射维护成本高，命名不统一是老难题 |
| Sony ESSTRA | 在二进制里嵌入元数据 | 提高供应链透明度 | 更像基础设施工程，不是装个插件就能上 |
| Fromager | 尝试让 Python 包完全从源码构建 | 减少对预编译黑盒的依赖 | 成本高、兼容性复杂，短期难成主流 |
横向看，这个问题并不只属于 Python。Node.js 生态这些年也频繁遇到原生模块和预编译二进制分发的麻烦，Sentry 甚至专门写过《How to publish binaries on npm》解释为什么“能发”不等于“好管”。Linux 发行版一侧也在补课，例如 UAPI 规范已经尝试在 ELF 文件里写入包来源和 dlopen() 元数据。公开说法是“透明度可以提升”，行业现实却是：语言包管理器、系统包管理器、容器镜像和企业制品库之间没有统一账本，责任边界也没有统一答案。
对谁影响最大：安全团队先头疼，开发者接着改流程
如果你在企业里负责平台工程、应用安全或合规，这个议题最现实的变化不是“多学一个概念”，而是要重新审视现有扫描流程到底覆盖了多少真实依赖。很多团队今天的动作是扫源码仓库、扫容器镜像、出 SBOM、接 CVE 预警；接下来更麻烦的一步，是确认 wheel、so、dll、插件和 FFI 调用背后到底连到了哪些包。
几类受影响的人，压力点并不一样：
- 开发者会遇到构建流程变长，CI 里多出二进制依赖检查。
- 安全团队会发现现有漏洞台账需要跨语言、跨包管理器重做映射。
- 企业采购和开源项目办公室会发现“该支持谁”比想象中更难量化。
- 普通用户短期感受不强，但长期会体现在补丁延迟、服务中断和事故概率上。
原文提出的方向，我基本认同：先把识别和记录工具做出来，再谈更大规模的治理。因为今天的关键障碍不是“没人意识到风险”，而是缺少一套足够低摩擦的采集方式。真正不那么重要的地方，是把所有希望押在单一标准上。PEP、SBOM、元数据规范都必要，但谁来填、谁来验、谁来持续维护映射表，这些成本才决定它能不能活下来。