GitHub 的 Python dependency graph 现在更完整了？先按这份清单判断你的 SBOM 盲区还剩多少

Article type: tutorial
Voice: operator

我先拿一个最小 Python 项目跑了一遍：requirements.txt 里只有一行 requests==2.32.3，但实际解析出来的安装树里，除了 requests，还会带出 charset-normalizer、idna、urllib3、certifi 这 4 个间接依赖。也就是说，如果你的视角还停在 manifest 层，SBOM 往往从第一步就已经不完整了。

先说结论

如果你的团队主要维护 Python 服务、内部工具或自动化脚本库，现在值得重新看一眼 GitHub 的 Python dependency graph。截至 2026-04-26，GitHub 已明确把 Python 的 dependency graph 补到更完整的间接依赖层，且 changelog 点名支持 pip、uv、Poetry v1/v2。这会直接影响 SBOM 导出、依赖审查和漏洞优先级判断。

但这不等于“开了就万事大吉”。如果你的仓库大量依赖私有 registry、运行时动态装包、或把依赖解析放在 GitHub 之外的构建链路里，那么新的 Python dependency graph 只能补上一部分盲区，不能自动替你补齐全部事实。

适合谁 / 不适合谁

适合谁：

• 在 GitHub 上维护 Python 应用、SDK、Agent 工具链或内部自动化仓库的团队
• 需要导出 SBOM、跑 dependency review、做漏洞优先级分发的工程团队
• 已经在用 pip、uv 或 Poetry，但过去主要只看 manifest / lock file 的仓库管理员

不适合谁：

• 依赖关系主要发生在 GitHub 之外，仓库本身只是镜像或只存一层包装脚本的团队
• 依赖大量由运行时下载、插件系统加载或外部构建平台注入，仓库静态内容本来就不代表真实运行面的项目
• 目前最核心的问题不是 Python 依赖可见性，而是镜像来源、CI digest 漂移或部署前拦截链路，那你应该先看这篇 《KICS 镜像被投毒后，团队现在该查什么？先按 digest 追一遍 CI 历史》

我先做了一个最小本地例子

这不是 GitHub 后端功能验收，只是一个足够小的本地例子，用来说明为什么 Python dependency graph 一旦只看 manifest，就天然会漏掉间接依赖。

• 环境：macOS / Python venv
• 命令：pip install requests==2.32.3 pipdeptree
• 结果：manifest 里只有 requests 1 个直接依赖，但解析树里额外出现 4 个间接依赖：charset-normalizer、idna、urllib3、certifi

这件事看起来不复杂，但它会直接影响两类判断：

1. 你导出的 SBOM 能不能覆盖真正进了环境的包
2. 你在 PR 里看到的依赖变更，究竟只是顶层声明变化，还是连带把一整串传递依赖一起带进来了

GitHub 这次到底补了什么

GitHub changelog 这次的核心不是“Python 终于也能看依赖了”——dependency graph 本来就不是新东西——而是 Python dependency graph 的间接依赖树更完整了。GitHub 在 changelog 里给出的原话很明确：Python 项目现在会看到“more complete and accurate transitive dependency trees”，而且这些结果会进入 dependency graph 和 SBOM。

更关键的一句是：这次能力来自一种新的 Dependabot job，它会构建 dependency snapshot，再上传到 Dependency Submission API。这意味着 GitHub 不是只靠仓库里那几份静态文件做浅层解析，而是在 Python 这条链路上把“解析后的事实”补得更深了一层。

如果你平时会用 GitHub 的 dependency review、Dependabot alerts 或导出 SBOM，这类增强不是后台小修小补，而是会直接改变你看到的依赖面。对想持续跟进这类供应链与工程治理话题的团队，也可以顺手回到 TG Hubs 的 infra 主题页 把相关案例放在一起看。

哪些仓库最该先开一次检查

如果你只准备先做一轮有限排查，我会优先看这 4 类仓库：

• 对外发布 SDK 或集成包的仓库：因为一旦 dependency graph 更完整，你会更快看到哪些传递依赖其实被下游一起吃进去了。
• Agent / 自动化工具仓库：这类项目常常把 HTTP、解析、日志、鉴权、任务编排等依赖叠在一起，间接依赖比直觉里多。你可以顺手对照这篇 《GitHub App installation token 格式要变了？先查这 4 处最容易把集成打断的硬编码》，把“依赖面”和“集成面”一起看，而不是只补其中一边。
• 安全或合规要求高的内部服务：因为 SBOM 覆盖率的改善，往往先体现在审计问题变少，而不是立刻体现在漏洞数下降。
• 历史上 manifest 很干净、但构建结果经常很胖的仓库：这类仓库最容易出现“声明看起来简单，实际拉进来的东西很多”的错觉。

先过哪 5 个检查点

如果你现在想判断新的 Python dependency graph 值不值得纳入团队流程，我建议先过这 5 个检查点：

• 检查包管理器是不是主流路径：GitHub changelog 当前明确点名支持 pip、uv、Poetry v1/v2。如果你走的是更非标准的装包路径，先别把预期拉太满。
• 看依赖是否主要发生在仓库内：GitHub Docs 对 dependency graph 的定义很清楚，它基于仓库里的 manifest、lock file，以及提交到 Dependency Submission API 的数据。仓库外动态发生的事，不会凭空自己出现。
• 确认私有 registry 和组织级配置是否会参与解析：changelog 特别提到新的 Dependabot job 可以访问 organization-wide configurations for private registries。对有私有源的团队，这一条比“多看见几个包”更重要。
• 把 SBOM 导出当成验收结果，不要只看 UI：GitHub Docs 明确把 dependency graph 和 SBOM 导出绑在一起。真正要过审计，最终看的是导出的清单有没有更接近真实构建结果。
• 把 dependency review 一起纳入 PR 审查：Docs 也写得很直接，针对默认分支的依赖变更，GitHub 会基于 dependency graph 给 PR 加上 dependency reviews。图更完整，review 的价值才会跟着变高。

这次不会自动帮你解决的 3 个盲区

这里反而是最容易被高估的部分。新的 Python dependency graph 更完整，不等于依赖可见性已经闭环。

1) 运行时才安装的依赖

如果某些包是在容器启动阶段、脚本执行阶段、或平台预构建阶段才被拉下来，仓库层的 dependency graph 依旧可能看不全。GitHub Docs 对 Dependency Submission API 的定位就是：提交那些“静态分析抓不到”的依赖。如果你的项目正好属于这类，就不能只等自动解析。

2) 非标准或跨系统构建链路

如果依赖解析发生在 monorepo 的另一层、外部构建器、或你们自定义的产物拼装步骤里，那么 GitHub 这次补的是 Python 主流路径，不是所有拼装链路。你可能还需要自己接 Dependency Submission API，或者直接提交 SBOM snapshot。

3) 你把“依赖更完整”误读成“风险自动更低”

依赖图变完整，首先改变的是可见性，不是风险本身。真正能不能把高风险变更拦在上线前，还是要回到 CI、部署和运行前检查链路。这个层面更接近 《GitHub 如何用 eBPF 提前拦住高风险部署：一份更实用的借鉴清单》

一个更稳的落地顺序

如果你不想把这件事做成又一个“功能开关已经打开，但没人真的看结果”的安全动作，可以按这个顺序推进：

• 先挑 3 个最关键的 Python 仓库，而不是全仓一口气铺开
• 先比对 dependency graph / SBOM / 实际构建依赖有没有明显差距
• 再看 dependency review 是否开始出现过去看不到的传递依赖变化
• 对私有 registry、多阶段构建、外部装包链路的仓库，单独补 Dependency Submission API 或 SBOM snapshot
• 最后再决定哪些仓库值得纳入更严格的 PR 审查或合规基线

这样做的好处是：你先验证“可见性有没有变好”，再决定要不要扩大流程成本。

FAQ

Python dependency graph 现在是不是所有 Python 仓库都自动更完整了？

不是。GitHub 当前明确增强的是 Python 主流包管理器路径下的 dependency snapshot 能力。仓库外动态安装、非标准构建链路、以及没被提交回 GitHub 的依赖事实，仍然可能留在图外。

GitHub 这次和以前只看 manifest / lock file 有什么区别？

区别在于它不再只靠静态文件做浅层判断。GitHub changelog 明说，这次是通过新的 Dependabot job 构建 snapshot，再上传到 Dependency Submission API，所以更接近“解析后的依赖事实”。

如果我已经能导出 SBOM，还需要关心 Python dependency graph 吗？

需要。因为 GitHub Docs 已经把 dependency graph、dependency review、Dependabot alerts 和 SBOM 放在同一条 supply-chain 可见性链路里。图不完整，后面几层也会跟着打折。

私有 registry 的 Python 仓库，这次收益大吗？

通常更大。因为 changelog 特别提到新的 Dependabot job 可以访问 organization-wide private registry 配置。对过去因为私有源而解析不完整的仓库，这往往比“多显示几个传递依赖”更有实际意义。

结论

这次 GitHub 对 Python dependency graph 的补强，值得被当成一次“Python 依赖可见性升级”，而不是普通的 changelog 噪音。它最适合拿来补 SBOM、dependency review 和私有 registry 解析这三件事之间的断层。

但也别把它理解成依赖治理已经自动闭环。更完整的 Python dependency graph，解决的是“你终于更容易看见什么进来了”；至于哪些东西该拦、该审、该补提交链路，仍然要靠团队自己把规则接上。

Sources

• GitHub Changelog: Dependabot-based dependency graphs for Python
• GitHub Docs: About the dependency graph
• GitHub Docs: Using the dependency submission API