python 库使用宽泛的依赖版本范围（如 >=1.0,
python 库使用宽泛的依赖版本范围（如 >=1.0,
在开源 Python 库的供应链安全实践中，Software Bill of Materials（SBOM）正日益成为关键交付物——它清晰列出项目所依赖的组件及其版本、许可证与漏洞元数据。然而，当库以声明式、非锁定方式定义依赖（例如 pyproject.toml 中使用 requests >=2.28.0,），SBOM 的生成便面临根本性挑战：<strong>同一份源码在不同构建环境或时间点可能解析出完全不同的依赖图谱</strong>（包括直接依赖的精确版本及整个传递依赖树），导致 SBOM 失去确定性、可验证性与可审计性。
目前，主流 SBOM 标准（如 CycloneDX 和 SPDX）尚未在规范层面明确定义如何处理“未锁定的版本范围”场景。CycloneDX 规范仓库中明确将此列为待决议题（Issue #321 和 PR #586），核心争议在于：
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 若仅记录
pyproject.toml中的原始范围表达式（如django>=4.2,），则 SBOM 缺乏实际组件标识，无法用于漏洞扫描或许可证合规检查； - 若基于某次
pip install或poetry lock生成带具体版本的 SBOM，则该产物不具备可重现性，且易被误认为是“官方发布依赖集”，引发责任归属混淆。
因此，现阶段最务实的工程实践是：暂不为纯库项目（非应用/可部署制品）自动生成 SBOM。取而代之的是：
✅ 在 README.md 或 SECURITY.md 中主动声明：“本库未提供 SBOM，因依赖采用语义化版本范围，其解析结果随构建环境动态变化；最终依赖图应由下游集成方在其锁定文件（如 poetry.lock 或 requirements.txt）基础上生成。”
✅ 鼓励使用者在构建其应用时，使用 cyclonedx-bom（配合 pip-tools 或 poetry export）生成终端可执行环境的 SBOM，而非库作者越俎代庖。
✅ 持续关注 CycloneDX v1.7 规范进展，该版本计划引入 dependencyConstraints 等新字段，有望原生支持版本范围建模。
# 示例：下游用户生成可审计 SBOM 的推荐流程（非库作者执行） poetry export -f requirements.txt --without-hashes > requirements.txt cyclonedx-bom -r -o bom.xml # 基于已锁定的 requirements.txt 生成 CycloneDX SBOM
需要强调的是：这一建议仅适用于作为依赖被集成的 Python 库。若您的项目是可分发的 CLI 工具、服务容器镜像或 PyPI 上的可执行包（即具有明确运行时依赖快照），则仍应通过 pip-tools + pipdeptree + cyclonedx-bom 流程生成锁定后的 SBOM。归根结底，SBOM 的价值在于反映真实运行时构成——对库而言，“真实运行时”并不存在，它只存在于使用者的环境中。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
