《Bun 生态里的 Dependabot 盲区：Dependabot 告警读不到 bun.lock》
标签：
#软件供应链安全 #依赖管理 #Bun #Dependabot #依赖图谱 #开源漏洞告警 #传递依赖 #CVE治理 #前端工程化
总结：
GitHub 的依赖图谱至今还不能解析
文章要点：
1. 作者发现，自己团队里已改用 Bun 的前端，Dependabot 告警数量少得反常，而且这些告警全都指向直接依赖，一条传递依赖告警都没有；于是开始追查原因，发现是 Bun 生态里的 Dependabot 盲区。
2. 根本原因是依赖图谱的“支持清单”里只有 `package-lock.json`、`yarn.lock`、`pnpm-lock.yaml`，没有 `bun.lock`；遇到 Bun 项目时，它只能退回读取 `package.json`，从而丢失了完整的版本信息。
3. 这里有一个容易让人混淆的地方：Dependabot 的**版本更新**从 2025 年初起就已经支持 Bun，会帮你修改 `bun.lock`；但**安全告警**走的是另一套依赖图谱，至今仍然不读它。
4. 作者构建了一个最小复现案例：`bun audit` 报告了 3 个漏洞（`zod`、`uuid` 以及
5. 在演示项目中，GitHub 只看到 12 个包中的 3 个；而在真实项目里，大部分包都是传递依赖，所以这个缺口比 3/12 所显示的更大。
6. 另一个更隐蔽的坑是：从 npm 或 Yarn 迁移到 Bun 时，旧 lockfile 会消失，GitHub 于是把那些依赖的未解决告警标记为**已修复**；但漏洞仍然原封不动地留在 `bun.lock` 里。
7. 作者提供的解法是 GitHub 的依赖提交 API：他自己写了一个
8. 使用前需要了解几点：告警只跟随默认分支；它只提供告警，不提供修复（修复需要依靠 `bun audit fix`）；首次运行会一次性出现一批告警，需要预留时间进行分类处理；私有包要使用 `exclude` 排除，避免因为与公开包重名而出现误报。
9. 作者的落地建议是：先自查是否受影响（查看 Dependency graph 里有没有
URL：https://charpeni.com/blog/the-bun-dependabot-gap-dependabot-alerts-dont-see-bun-lock
标签：
#软件供应链安全 #依赖管理 #Bun #Dependabot #依赖图谱 #开源漏洞告警 #传递依赖 #CVE治理 #前端工程化
总结：
GitHub 的依赖图谱至今还不能解析
bun.lock`，因此在使用 Bun 的项目里，Dependabot 安全告警只能看到 `package.json 中直接声明的依赖，所有传递依赖以及通过 catalog 声明的依赖都会从它的视野中消失。结果是，迁移到 Bun 之后，项目看起来变得更“干净”了，但这其实是因为大量漏洞都变得看不见了。文章要点：
1. 作者发现，自己团队里已改用 Bun 的前端，Dependabot 告警数量少得反常，而且这些告警全都指向直接依赖，一条传递依赖告警都没有；于是开始追查原因，发现是 Bun 生态里的 Dependabot 盲区。
2. 根本原因是依赖图谱的“支持清单”里只有 `package-lock.json`、`yarn.lock`、`pnpm-lock.yaml`，没有 `bun.lock`；遇到 Bun 项目时，它只能退回读取 `package.json`，从而丢失了完整的版本信息。
3. 这里有一个容易让人混淆的地方：Dependabot 的**版本更新**从 2025 年初起就已经支持 Bun，会帮你修改 `bun.lock`；但**安全告警**走的是另一套依赖图谱，至今仍然不读它。
4. 作者构建了一个最小复现案例：`bun audit` 报告了 3 个漏洞（`zod`、`uuid` 以及
happy-dom 的 CVE-2026-33943），而 GitHub 只对 zod 发出了告警，因为 uuid 只存在于 lockfile 中，`happy-dom` 的版本被记录成了字面量字符串 `catalog:`。5. 在演示项目中，GitHub 只看到 12 个包中的 3 个；而在真实项目里，大部分包都是传递依赖，所以这个缺口比 3/12 所显示的更大。
6. 另一个更隐蔽的坑是：从 npm 或 Yarn 迁移到 Bun 时，旧 lockfile 会消失，GitHub 于是把那些依赖的未解决告警标记为**已修复**；但漏洞仍然原封不动地留在 `bun.lock` 里。
7. 作者提供的解法是 GitHub 的依赖提交 API：他自己写了一个
bun-lock-submission Action，它能读取仓库里所有 `bun.lock`（包含 workspace 和 catalog），并区分直接依赖与传递依赖、运行时依赖与开发依赖，然后一次性提交；实测几分钟内就会出现告警，通常只需要几秒。8. 使用前需要了解几点：告警只跟随默认分支；它只提供告警，不提供修复（修复需要依靠 `bun audit fix`）；首次运行会一次性出现一批告警，需要预留时间进行分类处理；私有包要使用 `exclude` 排除，避免因为与公开包重名而出现误报。
9. 作者的落地建议是：先自查是否受影响（查看 Dependency graph 里有没有
bun.lock`，再用 `gh api 统计告警的来源分布），复查迁移日期前后被关闭的告警，加上这个 Action 并预留时间处理告警，等 GitHub 原生支持之后，再删掉工作流，并运行 `bunx bun-lock-submission clear`。URL：https://charpeni.com/blog/the-bun-dependabot-gap-dependabot-alerts-dont-see-bun-lock
Nicolas Charpentier
The Bun Dependabot Gap: Dependabot Alerts Don't See bun.lock | Nicolas Charpentier
GitHub's dependency graph doesn't read bun.lock yet, so in Bun projects Dependabot alerts only cover what's written in package.json, and never a transitive dependency. Here's how to check if you're affected, and how I closed the gap with a GitHub Action.
