自 2023 年以来，Python 软件基金会一直拥有一位驻地安全开发人员（由开源安全基金会的漏洞发现项目“Alpha-Omega”赞助）。他刚刚发布了一份长达 11 页的白皮书，探讨了开源软件的“幻影依赖”问题，并提出了解决方案。“幻影”依赖项无法通过打包元数据、清单或锁定文件进行跟踪，因此漏洞扫描程序或合规性和策略工具等工具“无法发现”它们。因此，驻地 Python 安全开发人员 Seth Larson 撰写了一份最近获得认可的 Python 增强提案，该提案提供了一种简便的方法，让软件包能够通过软件物料清单 (SBOM) 提供元数据。白皮书内容如下：Python 增强提案 770 向后兼容，并且可以通过工具默认启用，这意味着大多数项目无需手动选择启用即可开始生成有效的 PEP 770 SBOM 元数据。 Python 并非唯一受“幻影依赖”问题影响的软件包生态系统。使用 SBOM 记录元数据的方法可以被其他希望记录与生态系统无关的软件元数据的软件包生态系统重新混合和采用……在 Endor Labs 的 [2023 依赖项] 报告中，Python 被列为受“幻影依赖”问题影响最大的软件包生态系统之一。Python 尤其受到影响的原因有很多：- Python 与非 Python 软件接口的方法有很多，例如通过 C-API 或 FFI。Python 可以“包装”并为用其他语言（例如 C、C++、Rust、Fortran、Web Assembly 等）编写的软件公开一个易于使用的 Python API。- Python 是科学计算和人工智能的首要语言，这意味着许多用系统语言编写的高性能库需要通过 Python 代码访问。- 最后，Python 软件包有一种称为“wheel”的分发类型，它本质上是一个 zip 文件，通过解压到目录中进行“安装”，这意味着安装过程中不需要任何编译步骤。这对于在安装前检查软件包来说非常棒，但这意味着所有编译语言都需要在安装前预编译成二进制文件……在设计新的软件包元数据标准时，首要考虑的问题之一是减少打包工具（主要为志愿者）维护人员以及发布到 Python 软件包索引的数千个项目所需的工作量……通过将 PEP 770 SBOM 元数据定义为使用文件目录而不是新的元数据字段，我们能够避免所有实现上的难题……我们将致力于在流行的开源 SBOM 和漏洞扫描工具上提交问题，并逐渐减少幻影依赖项对 Python 软件包生态系统的影响。Python 软件基金会在一份声明中解释说，白皮书“详细介绍了 PEP 770 的创建和接受方法、挑战和见解，以及采用软件物料清单 (SBOM) 来提高 Python 软件包的可度量性”。白皮书最后还附有一条有用的说明。在与其他开源软件包生态系统维护者交流后，我们了解到其他生态系统在 Phantom Dependencies 方面也存在类似的问题。我们欢迎其他软件包生态系统采用 PEP 770 中的 Python 方法，并愿意提供实施指导。
在 Slashdot 上阅读更多内容。