GitHub Dependabot Ignores `bun.lock` Files, Missing Transitive Dependency Alerts in Bun Projects

Introduction: The Hidden Gap in Bun Dependency Security

Here’s the problem: GitHub’s Dependabot, a tool millions rely on for security alerts, is blind to Bun’s bun.lock files. This isn’t a minor oversight—it’s a systemic failure to monitor transitive dependencies, the hidden packages your project inherits from direct dependencies. In Bun projects, these transitive dependencies slip through the cracks, leaving potential vulnerabilities unflagged and unfixed.

The mechanism is straightforward but devastating. GitHub’s dependency graph, which powers Dependabot alerts, does not parse bun.lock files. Instead, it falls back to package.json, a file that only lists direct dependencies. This fallback means transitive dependencies—often the source of critical vulnerabilities—are entirely absent from the graph. Without them, Dependabot can’t generate alerts, even if these dependencies are outdated or compromised.

Consider the causal chain: Impact → Internal Process → Observable Effect:

• Impact: A transitive dependency in your Bun project contains a known vulnerability.
• Internal Process: Dependabot scans package.json but ignores bun.lock, failing to detect the vulnerable transitive dependency.
• Observable Effect: No alert is triggered, leaving the vulnerability unaddressed and your project exposed.

Compounding the issue, dependencies declared with Bun’s catalog: syntax are recorded as literal strings (e.g., "catalog:") in the dependency graph. This mismatch prevents advisories from being linked to these dependencies, as the version strings never align with advisory data. In a test case, bun audit identified three vulnerabilities, while Dependabot raised only one—a stark illustration of the gap.

The risk isn’t theoretical. As Bun gains traction for its speed and simplicity, developers migrating from npm or Yarn may falsely assume their projects are secure. Dependabot marks alerts tied to old lockfiles (e.g., package-lock.json) as fixed, even if the vulnerable packages persist in bun.lock. This creates a false sense of security, masking real threats.

To diagnose the issue, check your project’s dependency graph in GitHub Insights. If only package.json files are listed, your transitive dependencies are unmonitored. Comparing Dependabot alerts with bun audit results will reveal the discrepancy.

The optimal fix, pending GitHub’s native support for bun.lock, is to manually submit the lockfile via GitHub’s dependency submission API. A GitHub Action like this one automates the process, ensuring transitive dependencies are included in the graph. This solution is effective but temporary—it bridges the gap until GitHub integrates bun.lock parsing natively.

The choice is clear: If your project uses Bun, submit bun.lock via the API. Failing to do so leaves your project vulnerable to unmonitored transitive dependencies. The mechanism of risk is clear, and the solution, while not ideal, is actionable. Ignore this at your peril.

Background

Bun, a modern JavaScript runtime and bundler, has gained traction for its performance and simplicity. However, its adoption introduces a critical oversight in dependency management: GitHub’s Dependabot alerts fail to recognize Bun’s bun.lock files. This gap leaves transitive dependencies in Bun projects unmonitored for security vulnerabilities, exposing applications to potential exploits.

The Role of bun.lock Files

bun.lock files are Bun’s mechanism for locking dependency versions, ensuring consistent installations across environments. Unlike package.json, which lists direct dependencies, bun.lock captures the entire dependency tree, including transitive dependencies. This file is critical for reproducibility and security, as it pins exact versions of all dependencies, preventing unintended updates that could introduce vulnerabilities.

Dependabot’s Blind Spot

GitHub’s Dependabot, a widely used tool for identifying security vulnerabilities in dependencies, relies on GitHub’s dependency graph. This graph parses lockfiles like package-lock.json, yarn.lock, and pnpm-lock.yaml to map dependencies. However, it does not yet support bun.lock. As a result, Dependabot falls back to package.json for Bun projects, which only includes direct dependencies. Transitive dependencies, locked in bun.lock, are entirely omitted from the graph.

Mechanisms of Failure

• Transitive Dependencies Ignored: Since bun.lock is not parsed, transitive dependencies are absent from the dependency graph. This means Dependabot cannot detect vulnerabilities in these dependencies, leaving them unmonitored.
• Incorrect Recording of catalog: Dependencies: Bun’s catalog: syntax allows specifying dependencies from custom registries. Dependabot records these as literal strings (e.g., catalog:), which never match security advisories. This prevents alerts even when vulnerabilities exist.
• False “Fixed” Alerts: When migrating from npm or Yarn to Bun, Dependabot marks alerts tied to old lockfiles (e.g., package-lock.json) as fixed. However, if the vulnerable packages persist in bun.lock, the risk remains unaddressed, creating a false sense of security.

Impact and Risk Formation

The failure to monitor transitive dependencies creates a security gap in Bun projects. Vulnerable packages can remain undetected, exposing applications to exploits. For example, if a transitive dependency contains a critical vulnerability, attackers could exploit it to compromise application integrity or user data. The risk is compounded by the fact that developers may assume Dependabot’s alerts provide comprehensive coverage, unaware of the blind spot in Bun projects.

Diagnosis and Verification

To determine if your Bun project is affected, check GitHub Insights → Dependency graph. If only package.json is listed as a source, transitive dependencies are not being monitored. Comparing Dependabot alerts with bun audit results can highlight discrepancies. For instance, in a minimal repro with zod (pinning an old uuid) and happy-dom (via catalog:), bun audit identified 3 advisories, while Dependabot raised only 1.

Temporary Solution

Until GitHub natively supports bun.lock parsing, developers can manually submit bun.lock files via GitHub’s dependency submission API. A GitHub Action like charpeni/bun-lock-submission automates this process, ensuring transitive dependencies are included in the graph. This solution is effective but requires proactive implementation and is not a permanent fix.

Professional Judgment

The optimal solution is for GitHub to add native support for bun.lock parsing. Until then, submitting bun.lock via the API is the most effective workaround. Failing to address this gap leaves projects vulnerable, and relying solely on Dependabot’s alerts for Bun projects is a critical error. Developers must take immediate action to mitigate risk, especially if migrating from other package managers.

Rule: If using Bun, submit bun.lock via the dependency submission API to monitor transitive dependencies and mitigate security risks.

The Problem: Dependabot’s Blind Spot in Bun Projects

GitHub’s Dependabot, a critical tool for monitoring security vulnerabilities in project dependencies, has a glaring oversight when it comes to Bun projects. The root issue? Dependabot ignores bun.lock files, the lockfiles generated by Bun to pin dependency versions, including transitive ones. Instead, it falls back to parsing only the package.json file, which lists direct dependencies but omits the full dependency tree. This mechanical failure in dependency scanning leaves transitive dependencies unmonitored, creating a security gap.

Mechanisms of Failure

• Transitive Dependencies Ignored:

When Dependabot scans a Bun project, it relies on GitHub’s dependency graph, which does not parse bun.lock files. As a result, transitive dependencies—those pulled in by direct dependencies—are excluded from the graph entirely. This omission means Dependabot cannot detect vulnerabilities in these dependencies, leaving them unpatched and exposed.

• Incorrect catalog: Dependency Recording:

Bun allows developers to declare dependencies using the catalog: syntax, which specifies a package from a custom catalog. Dependabot, however, records these dependencies as literal strings (e.g., "catalog:"). This mismatch prevents advisories from linking to these dependencies, as the recorded version never matches the advisory’s criteria.

• False “Fixed” Alerts:

When migrating from npm or Yarn to Bun, Dependabot marks alerts tied to the old lockfiles (e.g., package-lock.json) as “fixed”, even if the vulnerable packages are still present in bun.lock. This false sense of security arises because Dependabot’s alerts are tied to the old lockfile, not the new bun.lock file.

Causal Chain: Impact → Internal Process → Observable Effect

Impact: Vulnerable transitive dependencies exist in Bun projects.

Internal Process: Dependabot scans package.json but ignores bun.lock, failing to detect transitive dependencies.

Observable Effect: No alerts are raised for transitive vulnerabilities, leaving them unaddressed.

Risk Formation Mechanism

The risk arises from the discrepancy between what Bun installs and what Dependabot monitors. While bun.lock ensures consistent and secure installations by pinning exact versions, Dependabot’s reliance on package.json creates a monitoring gap. This gap allows vulnerabilities in transitive dependencies to persist undetected, exposing applications to potential exploits. For developers migrating to Bun, this oversight can lead to a false assumption of security, as old alerts are marked as fixed without actual resolution.

Diagnosis: Identifying the Gap

To determine if your Bun project is affected, follow these steps:

• Open GitHub Insights → Dependency graph. If only package.json files are listed, transitive dependencies are unmonitored.
• Compare Dependabot alerts with the results of bun audit. Discrepancies indicate unmonitored vulnerabilities.

Solutions: Bridging the Gap

Until GitHub natively supports bun.lock parsing, developers must take proactive steps to mitigate this risk.

Temporary Fix: Manual Submission via Dependency Submission API

The most effective workaround is to manually submit bun.lock files via GitHub’s dependency submission API. This process ensures that transitive dependencies are included in the dependency graph, enabling Dependabot to monitor them for vulnerabilities. Tools like the GitHub Action charpeni/bun-lock-submission automate this submission, reducing manual effort.

Optimal Solution: Native bun.lock Support

The ultimate solution is for GitHub to add native support for bun.lock parsing. This would eliminate the need for manual submissions and ensure comprehensive dependency monitoring for Bun projects. Until then, the dependency submission API remains the most effective workaround.

Rule for Choosing a Solution

If using Bun, submit bun.lock via the dependency submission API to monitor transitive dependencies and mitigate security risks.

Typical Choice Errors and Their Mechanism

A common error is assuming Dependabot’s alerts are comprehensive for Bun projects. This assumption arises from Dependabot’s reliable performance with npm, Yarn, and pnpm lockfiles, leading developers to overlook the bun.lock gap. Another error is relying solely on bun audit, which, while effective for local scans, does not integrate with GitHub’s dependency graph or alert system.

Conclusion

Dependabot’s inability to parse bun.lock files creates a critical security gap in Bun projects. By understanding the mechanisms of this failure and implementing the dependency submission API as a workaround, developers can bridge this gap until native support is available. The rule is clear: If you’re using Bun, submit bun.lock to protect your project.

Scenarios and Implications

1. Silent Exploitation of a Transitive Dependency

A Bun project uses zod, which transitively depends on an outdated version of uuid with a known vulnerability (e.g., CVE-2023-1234). Because Dependabot ignores bun.lock, it never alerts the developer. An attacker exploits this vulnerability to inject malicious data, compromising user sessions. Mechanism: Dependabot falls back to package.json, which lacks transitive dependencies, so the vulnerable uuid remains unmonitored. Observable effect: No alert is raised, and the vulnerability persists undetected.

2. False Sense of Security After Migration

A team migrates from npm to Bun, assuming Dependabot will continue monitoring their dependencies. They receive no new alerts, but bun audit reveals three vulnerabilities in transitive dependencies. Mechanism: Dependabot marks old package-lock.json alerts as "fixed" despite vulnerabilities persisting in bun.lock. Observable effect: Developers falsely believe their project is secure, leaving vulnerabilities unpatched.

3. Catalog Dependency Mismatch

A project uses Bun’s catalog: syntax to declare a dependency on happy-dom. Dependabot records this as "catalog:", preventing advisories from matching. A critical vulnerability in happy-dom goes unnoticed. Mechanism: Dependabot’s literal recording of catalog: breaks advisory linking. Observable effect: No alert is triggered, and the vulnerability remains unaddressed.

4. Supply Chain Attack via Unmonitored Dependency

A transitive dependency in a Bun project is compromised by a supply chain attack. Dependabot fails to detect the malicious package, allowing it to propagate through the application. Mechanism: Dependabot’s reliance on package.json excludes transitive dependencies from monitoring. Observable effect: The malicious package is installed and executed, potentially exfiltrating data or injecting malware.

5. Inconsistent Security Posture Across Teams

One team uses bun audit and discovers vulnerabilities, while another relies solely on Dependabot alerts. The latter team remains unaware of transitive vulnerabilities. Mechanism: Dependabot’s incomplete monitoring creates a gap in security practices. Observable effect: Inconsistent vulnerability detection leads to uneven risk exposure across projects.

6. Delayed Response to Critical Vulnerabilities

A critical vulnerability is disclosed in a widely used transitive dependency. Dependabot fails to alert Bun projects, delaying remediation. Mechanism: Dependabot’s exclusion of bun.lock prevents timely detection of transitive vulnerabilities. Observable effect: Projects remain exposed until manual auditing or external notification occurs.

Mitigation and Decision Dominance

Optimal Solution: Submit bun.lock via GitHub’s dependency submission API using tools like charpeni/bun-lock-submission. This automates inclusion of transitive dependencies in the dependency graph. Effectiveness: Bridges the monitoring gap until GitHub natively supports bun.lock. Rule: If using Bun, submit bun.lock via the API to monitor transitive dependencies and mitigate security risks. Common Error: Relying solely on Dependabot alerts or bun audit without integrating both. Mechanism: Dependabot’s alerts are incomplete, and bun audit lacks GitHub integration, creating a monitoring gap.

Conclusion and Recommendations

The investigation reveals a critical oversight in GitHub's Dependabot: its inability to parse bun.lock files leaves transitive dependencies in Bun projects unmonitored for security vulnerabilities. This gap stems from Dependabot's reliance on GitHub's dependency graph, which currently supports package-lock.json, yarn.lock, and pnpm-lock.yaml, but not bun.lock. As a result, Dependabot falls back to package.json, which only captures direct dependencies, leaving transitive dependencies—often the source of hidden vulnerabilities—untracked.

Urgency of Addressing the Issue

As Bun gains traction for its performance and simplicity, this oversight poses an immediate risk. Developers migrating to Bun may falsely assume their projects are secure due to Dependabot's incomplete monitoring. Unaddressed vulnerabilities in transitive dependencies could expose applications to exploits, compromising data integrity and user trust. The risk is compounded by Dependabot marking alerts tied to old lockfiles as "fixed," even if vulnerabilities persist in bun.lock.

Actionable Recommendations

1. Temporary Fix: Submit bun.lock via Dependency Submission API

Until GitHub natively supports bun.lock, manually submitting it via the dependency submission API is the most effective workaround. Tools like charpeni/bun-lock-submission automate this process, ensuring transitive dependencies are included in the dependency graph. Rule: If using Bun, submit bun.lock via the API to monitor transitive dependencies and mitigate security risks.

2. Diagnose the Gap: Compare Dependabot Alerts with `bun audit

To identify unmonitored vulnerabilities, compare Dependabot alerts with bun audit results. If GitHub Insights → Dependency graph lists only package.json, transitive dependencies are unmonitored. This comparison highlights discrepancies and underscores the need for manual submission.

3. Optimal Solution: GitHub Must Add Native bun.lock Support

The long-term solution is for GitHub to integrate bun.lock parsing into its dependency graph. This would eliminate the need for manual submissions and ensure comprehensive monitoring. Until then, the API submission workaround remains critical.

4. Avoid Common Errors

• Error: Relying solely on Dependabot for Bun projects. Mechanism: Dependabot's alerts are incomplete due to missing transitive dependencies. Rule: Always use bun audit alongside Dependabot.
• Error: Assuming migrated projects are secure. Mechanism: Dependabot marks old lockfile alerts as "fixed" despite vulnerabilities in bun.lock. Rule: Verify security by comparing alerts with bun audit.

Professional Judgment

The current gap in Dependabot's functionality for Bun projects is a significant security risk. While manual submission of bun.lock via the API is an effective temporary fix, it requires proactive implementation. GitHub's native support for bun.lock is the optimal solution, but until then, developers must take immediate action to bridge this monitoring gap. Failure to do so leaves projects exposed to undetected vulnerabilities, undermining application integrity and user trust.