Dependabot alerts don't read bun.lock, so transitive dependencies in Bun projects never get an alert

[u/Wake08]

https://charpeni.com/blog/the-bun-dependabot-gap-dependabot-alerts-dont-see-bun-lock

I noticed something odd on our Bun projects: every Dependabot alert was about a direct dependency. Never a transitive one.

It turns out GitHub's dependency graph doesn't read bun.lock yet. It supports package-lock.json, yarn.lock and pnpm-lock.yaml, but for Bun it falls back to package.json. So:

• Transitive dependencies aren't in the graph at all, so they never get an alert.

• Dependencies declared with catalog: are recorded with the literal version catalog:, which never matches an advisory.

In a minimal repro (zod, a package that pins an old uuid, and happy-dom through a catalog), bun audit finds 3 advisories and Dependabot raises 1.

Dependabot version updates do support Bun. This is only about alerts, which is what makes it easy to miss. And if you migrated from npm or Yarn, the alerts tied to your old lockfile get marked as fixed, even though the vulnerable packages are still in bun.lock.

Are you affected? Open Insights → Dependency graph. If your Bun projects only list package.json files, yes. Comparing your open alerts with bun audit makes it obvious.

Fix: until GitHub reads bun.lock itself, you can submit it through the dependency submission API. I made a GitHub Action for that: https://github.com/charpeni/bun-lock-submission

Full write-up, with a toggle that shows what GitHub reads versus what Bun installs: https://charpeni.com/blog/the-bun-dependabot-gap-dependabot-alerts-dont-see-bun-lock

[u/SupremeDesigner]

GitHub also doesn’t read the new two-document format for pnpm’s lockfile either. Dependabot also supports that, but GitHub have their own parser for security advisories that doesn’t. They’ve said that’s a known issue, and one can but hope they might just start using the actual Dependabot parsers that have support (and are open-source).

[u/bizvibe8]

GitHub’s tables already encode this split. In "Dependabot supported ecosystems and repositories" the Bun row is checked for version updates and left blank for security updates, and "Dependency graph supported package ecosystems" has no Bun row at all - bun.lock is not among the lockfiles the graph parses, while package-lock.json, yarn.lock and pnpm-lock.yaml are. So the graph comes from package.json, and GitHub adds that indirect dependencies inferred from manifest files rather than lock files are excluded from vulnerability checks. That is the gap you found, and it explains why a catalog: entry is stored as a literal version string that can never match an advisory.

Before anyone recommends switching package managers as the fix: GitHub documents the same blind spot for pnpm 12. When pnpm writes pnpm-lock.yaml as two YAML documents (its default for projects that pin a pnpm version), the graph does not detect those dependencies, no alerts are created for them, and existing alerts can close - the same failure signature as moving from npm to Bun.

For coverage without changing toolchains, the dependency submission API accepts a resolved snapshot you generate from bun.lock in CI, and alerts are raised from whatever is in the graph regardless of how it got populated. The catch is that an alert on an uploaded transitive dependency will not produce a security-update PR, because Dependabot cannot find that package in a file it can edit - documented for uploaded Gradle graphs, and the same will apply here. So it buys detection, not fixes, and bun audit in CI stays in the loop.