GitHub Will Pause Dependabot Alerts on Inactive Repositories

A repository can remain deployed long after its last commit. GitHub is changing how Dependabot alerts behave when development stops.

José Palanco José Palanco
Last Updated:
2 min read
Share
GitHub Will Pause Dependabot Alerts on Inactive Repositories

Beyond ASPM

Proof-Driven AppSec for teams building with AI

Plexicus uses AI Swarm Pentest to explore authorized application paths, validate what is exploitable, and give teams evidence they can use to prioritize remediation.

Explore AI Swarm Pentest

A repository can remain deployed long after its last commit. GitHub is changing how Dependabot alerts behave when development stops.

What changes on December 8

GitHub announced that, starting December 8, 2026, Dependabot alerts will be turned off for most repositories with no qualifying activity in the past year. Existing alerts are archived, not deleted, and can be restored. This is an alerting policy change, not evidence that inactive software is safe or that its dependencies are no longer used.

GitHub counts creating the repository, pushing to any branch or tag, and enabling Dependabot alerts as activity. A push automatically turns alerts back on; an administrator can also enable them in settings. Either action restores archived alerts and starts a new one-year clock.

Exceptions matter

GitHub says repositories with an enforced security configuration that enables Dependabot alerts are excluded. Repositories in enterprises whose policy prevents repository administrators from changing the alert setting are also excluded. The change applies to all plans on GitHub.com and GitHub Enterprise Cloud with data residency; it does not apply to GitHub Enterprise Server. Consult the announcement for the current rules.

What security teams should do

  1. Inventory repositories that have not had qualifying activity for a year, including code that is still deployed or reused.
  2. Check whether each repository is covered by an enforced configuration or enterprise policy. Assign an owner to repositories whose alerting could pause.
  3. Where appropriate, re-enable alerts in settings or push an authorized change, then review the restored alerts. Do not create meaningless commits merely to satisfy a clock.
  4. Track deployment ownership and review vulnerable dependencies using the evidence available; restoring alerts does not itself remediate a finding.

Keep the repository and the application connected

An inactive repository may still produce a running service. Plexicus remediation describes reviewable fixes for validated findings, while AI Swarm Pentest covers authorized application and API testing. Those capabilities do not imply that Plexicus automatically changes GitHub settings or restores Dependabot alerts. Connect repository ownership, deployed applications and remediation decisions so that an archived alert does not disappear from the team’s follow-up.

Thumbnail: original GitHub Docs Dependabot alert example, GitHub, CC BY 4.0. The documentation screenshot illustrates an alert and does not depict an inactive repository.

Written by
José Palanco
José Palanco
José Ramón Palanco is the CEO/CTO of Plexicus, a pioneering company in ASPM (Application Security Posture Management) launched in 2024, offering AI-powered remediation capabilities. Previously, he founded Dinoflux in 2014, a Threat Intelligence startup that was acquired by Telefonica, and has been working with 11paths since 2018. His experience includes roles at Ericsson`s R&D department and Optenet (Allot). He holds a Telecommunications Engineering degree from the University of Alcala de Henares and a Master`s in IT Governance from the University of Deusto. As a recognized cybersecurity expert, he has been a speaker at various prestigious conferences including OWASP, ROOTEDCON, ROOTCON, MALCON, and FAQin. His contributions to the cybersecurity field include multiple CVE publications and the development of various open source tools such as nmap-scada, ProtocolDetector, escan, pma, EKanalyzer, SCADA IDS, and more.
Read More from José
More to read

Related posts

Ready to validate what matters?

Ready to validate what matters?

Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorized target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)
Private Round For investors