Aligning Dependabot Security with Ghidra's Internal Dependency Policy

[honeyankit]

Hello Ghidra Team,

I am the Senior Engineering Manager for Dependabot at GitHub. I’ve been following Ghidra’s work in the SRE space and noticed your policy in CONTRIBUTING.md regarding the internal management of 3rd-party library updates.

We have currently shipped some features specifically for sovereign and high-compliance environments (such as self-hosted runners and private vNET integrations with Dependabot). I am curious to learn if there are specific technical blockers - such as air-gapped requirements or manual vetting workflows - that prevent the use of Dependabot alerts or security updates on this repository.

Furthermore, I understand that Dependabot can be noisy in high-traffic codebases, and my team is actively working to solve this through risk-based prioritization. We have launched several noise-reduction features, including cross-ecosystem Grouped Updates and Cooldown Periods to delay PRs for newly released versions until they are vetted by the community. We have also integrated the Exploit Prediction Scoring System (EPSS) to help teams prioritize alerts by their likelihood of exploitation rather than just severity.

Most recently, as of April 2026, we have enabled the ability to assign complex remediation tasks to AI Agents (Copilot, Codex) to handle breaking changes that a simple version bump cannot resolve.

My goal is to understand how we can evolve our tooling to better support the internal-first security posture of mission-critical projects like Ghidra. If there is interest, I would welcome a brief technical dialogue on how Dependabot can provide visibility without disrupting your existing manual review protocols.

Best regards,
Ankit Kumar Honey

[ryanmkurtz]

Hello @honeyankit, thanks for reaching out. As I've alluded to in several other issues/pull-request, we use established internal/corporate tools and services to develop Ghidra, and we simply mirror out to GitHub. We leverage these services to do Dependabot-like things.

Your post did motivate me to get the Dependency Graph and Dependabot Alerts enabled though, which I just pushed out yesterday. I think these will be valuable features so our GitHub users can more easily see any security issues we might be having with the current state of the repo. The Dependabot Security Updates is a feature that we specifically do not want on though. Because GitHub is just a mirror and we have other internal considerations, there's extra work we have to do to bring a PR in and accept it. This extra work is significantly more than the work of us just bumping a version number in a build.gradle file ourselves.

Thanks!

[honeyankit]

@ryanmkurtz: Thank you for the detailed transparency and for the update!

I am very glad to hear that my inquiry helped motivate the enablement of the Dependency Graph and Dependabot Alerts. Improving the security transparency for the global Ghidra community is a significant win for supply chain integrity, especially for a tool as foundational to the SRE ecosystem as this one.

I completely understand your position on Dependabot Security Updates (PRs). In my role as the technical DRI for Dependabot, we frequently encounter this 'mirror-out' friction in high-compliance and sovereign environments. The 'PR ingestion tax' is a real challenge when the source of truth resides on a secure internal network.

My current work is focused on solving this exact Agentic Gap - building workflows where remediation insights can be consumed by internal ticketing or automated systems without disrupting the external mirror’s integrity. If the Ghidra team ever explores ways to automate those internal version bumps via self-hosted infrastructure or vNET-integrated runners, I would be happy to share our architectural findings or connect you with our specialized engineers.

Thank you again for the leadership you provide to the security community. I’m pleased to see the alerts live!

[musaabhasan]

The mirror-only model makes sense for a project like Ghidra. In that setup, Dependabot PR automation is probably less valuable than transparent vulnerability visibility and a clean internal intake path.

A useful middle ground could be:

• keep Dependency Graph and Dependabot Alerts enabled for public visibility;
• avoid external auto-PRs when the authoritative update workflow is internal;
• publish an SBOM or dependency inventory artifact per release so downstream users can assess exposure consistently;
• map public alerts to internal remediation state: acknowledged, internally patched, queued for release, not applicable, or accepted risk;
• include dependency update notes in release documentation when a security-relevant bump lands internally.

That preserves the project’s internal dependency governance while still giving external users enough evidence to understand whether a flagged component is merely visible in the mirror or actually present in a supported release path. For high-compliance users, that distinction is often more useful than seeing an automated PR that maintainers cannot accept directly.

[honeyankit]

This is a very thoughtful perspective, and I agree that for projects operating on a mirror-only model, transparency and accurate vulnerability visibility can often be more valuable than external auto-PR workflows.

I especially like the idea of combining Dependency Graph and Dependabot Alerts with SBOM publication and clearer remediation-state mapping. That gives downstream consumers and compliance-focused organizations much better context around whether a vulnerability is actionable, internally mitigated, or not relevant to supported release paths.

From the Dependabot side, we are increasingly seeing customers ask not just for “alert visibility,” but also for richer lifecycle and remediation context around vulnerabilities. The approach you outlined aligns well with that direction and strikes a practical balance between internal governance models and external transparency.

Thanks for sharing this, it is genuinely helpful feedback and a useful framing for how we think about these workflows going forward.