GitHub Dependabot alerts are getting a new inactivity policy that could change how developers monitor vulnerable dependencies in older repositories. Starting December 8, 2026, GitHub will turn off Dependabot alerts on most repositories that have recorded no qualifying activity during the previous year.
The change applies to repositories on GitHub.com across all plans and to GitHub Enterprise Cloud with data residency. It does not apply to GitHub Enterprise Server.
GitHub says existing alerts will be archived, not deleted. They can be restored when alerts are re-enabled, either through repository settings or automatically following a new push.
The announcement is designed to reduce the processing and alert volume associated with repositories that are no longer actively developed. But it also raises an important operational question: does a repository that has not changed for a year necessarily represent a lower security risk?
For software maintainers, DevSecOps teams and organizations with large collections of archived projects, the answer depends on whether those repositories are still distributed, deployed or consumed by other systems.
What Is Changing With GitHub Dependabot Alerts?
Dependabot alerts notify repository maintainers when GitHub identifies known vulnerabilities affecting dependencies in a project.
They rely on dependency information and security advisories to help teams identify vulnerable packages and assess whether updates are necessary.
Under the new policy, GitHub will automatically disable alerts on most repositories that have remained inactive for a year.
GitHub’s official November 10 announcement specifies three events that count as activity:
-
A push to any branch or tag.
-
Creation of the repository.
-
Enabling Dependabot alerts.
The policy is therefore based on particular repository events, not on every possible sign that a project remains useful.
A repository may still receive visitors, be cloned by developers or provide dependencies to other projects without recording one of those qualifying events.
What happens to existing vulnerability alerts?
GitHub will archive existing Dependabot alerts when the feature is disabled because of inactivity.
Those alerts are not permanently deleted.
When Dependabot alerts are enabled again, GitHub restores the archived alerts and restarts the one-year activity clock.
That preservation is useful for audit continuity, but teams should not confuse archived historical findings with evidence that continuous vulnerability monitoring remained active throughout the paused period.
Why GitHub Is Pausing Dependabot Alerts
GitHub attributes the decision to the growing volume of vulnerability discovery and associated alerts.
Maintaining security analysis for large numbers of repositories consumes infrastructure resources, including projects that have not received code changes for extended periods.
The policy prioritizes repositories showing recent development activity.
From an infrastructure perspective, this is understandable. A large software-hosting platform must allocate scanning and alert-processing capacity across millions of repositories with very different maintenance patterns.
However, the operational meaning of inactivity is more complicated than the absence of recent commits.
A repository can be stable, widely used and security-sensitive without requiring frequent code changes.
For example, a mature internal library may remain unchanged for more than a year while continuing to be incorporated into production applications.
Its dependency vulnerabilities may still matter even though the repository appears inactive under GitHub’s definition.
How the Dependabot Alerts Inactivity Rule Works
The policy introduces a one-year inactivity threshold, but GitHub also provides straightforward ways to restore monitoring.
| Repository condition | Expected behavior |
|---|---|
| No qualifying activity for one year | Alerts may be disabled beginning December 8 |
| New push to a branch or tag | Alerts automatically re-enabled |
| Alerts manually enabled | Archived alerts restored |
| Enforced security configuration enables alerts | Exempt from automatic disabling |
| Enterprise policy prevents repository administrators from toggling alerts | Exempt |
| GitHub Enterprise Server repository | Not covered by this change |
Based on GitHub’s November 10, 2026 announcement.
GitHub Changelog
Does creating a new branch count as activity?
GitHub specifically identifies pushing to a branch or tag as qualifying activity.
The announcement does not say that every administrative or organizational change to a repository resets the inactivity clock.
Teams should avoid assuming that changing a description, assigning a topic or modifying repository visibility is sufficient.
Does Dependabot automatically resume after a push?
Yes. GitHub says any push to the repository automatically turns Dependabot alerts back on.
The archived alerts are restored, and the one-year clock starts again.
That makes recovery relatively simple for repositories returning to active development.
However, organizations should not rely on artificial commits solely to preserve security monitoring when GitHub provides explicit configuration mechanisms for keeping alerts enabled.
Which GitHub Repositories Are Exempt?
Two enterprise policy conditions are particularly important.
First, GitHub will not automatically disable alerts on repositories covered by an enforced security configuration that enables Dependabot alerts.
Second, GitHub excludes repositories belonging to enterprises whose Dependabot alerts policy prevents repository administrators from enabling or disabling alerts themselves.
These exceptions allow centralized security governance to take precedence over the inactivity rule.
Why enforced security configurations matter
Large organizations often use centralized policies to ensure consistent security coverage.
A repository may be owned by an individual team, but its dependency vulnerabilities can affect systems maintained by other groups.
An enforced security configuration helps avoid relying entirely on repository-level decisions.
For organizations with long-lived libraries, infrastructure code and regulated software, centrally enforced monitoring may be preferable to allowing inactive repositories to fall out of alert coverage automatically.
The correct policy depends on the organization’s risk assessment, but the November announcement makes centralized configuration especially relevant.
The Security Risk of Inactive Repositories
The most important distinction is between a repository that is inactive and software that is no longer used.
Those are not equivalent conditions.
A repository may be inactive because its code is stable. It may also be inactive because a project has been abandoned.
Both scenarios can involve vulnerable dependencies, but their operational implications differ.
Stable software can still become vulnerable
A dependency that was considered secure when a project was last updated may later receive a vulnerability disclosure.
The application code does not need to change for the risk to emerge.
This is why dependency monitoring is useful even for software that receives infrequent maintenance.
An old repository containing an actively deployed service, reusable library or container configuration may still deserve ongoing security coverage.
Archived repositories can remain part of the supply chain
A project can also remain relevant through indirect use.
Other repositories may depend on its released packages, fork its code or incorporate its artifacts into larger systems.
The absence of new commits does not reveal whether downstream consumers remain exposed.
Organizations should therefore assess the deployment and dependency relationships of inactive repositories before deciding that paused monitoring is acceptable.
Dependabot Alerts vs. Dependabot Updates: An Important Difference
The November 2026 change concerns Dependabot alerts, not a blanket shutdown of every Dependabot feature.
Dependabot supports several related but distinct capabilities.
Dependabot alerts identify known vulnerable dependencies. Dependabot security updates can propose changes to remediate supported vulnerabilities. Dependabot version updates propose newer dependency versions according to repository configuration.
These functions should not be treated as interchangeable.
GitHub previously introduced inactivity-based pauses for automated Dependabot pull requests, but its earlier policy explicitly distinguished those pauses from Dependabot alerts.
The December 2026 change introduces a separate inactivity rule affecting alert coverage itself.
The GitHub Blog
TechnologyHQ recently covered GitHub Dependabot’s support for Agent Package Manager, which allows automated version updates for supported AI agent dependencies.
That capability concerns dependency maintenance, whereas the new inactivity policy concerns whether vulnerability alerts remain enabled for dormant repositories.
What Enterprise Security Teams Should Do Before December 8
Organizations with many repositories should review their security coverage before the new policy begins.
The most useful approach is to identify repositories that have not recorded qualifying activity during the previous year and classify them according to their actual operational importance.
A dormant demonstration project is different from a stable library used by production applications.
A practical repository audit
Security teams can organize repositories into several categories:
-
Actively maintained repositories with current development.
-
Stable repositories that remain in production use.
-
Archived repositories that are still consumed by other projects.
-
Abandoned repositories with no identified operational dependencies.
The second and third groups deserve particular attention because GitHub’s inactivity criteria may not reflect their continuing importance.
For critical repositories, administrators should evaluate whether an enforced security configuration is appropriate.
Check dependency exposure, not just commit history
Repository activity is a useful operational signal, but it is not a complete measure of security exposure.
A stronger assessment considers whether the repository’s software is deployed, whether packages are still distributed, whether downstream projects depend on it and whether its maintainers can respond to new vulnerabilities.
Where available, software bills of materials, dependency inventories and deployment records can help answer those questions.
The objective is to avoid losing visibility into software that remains relevant simply because it has not changed recently.
How to Restore Dependabot Alerts
GitHub provides two documented restoration mechanisms.
A new push automatically re-enables Dependabot alerts for the repository.
Alternatively, administrators can enable Dependabot alerts through repository settings, subject to the organization’s permissions and security policies.
In either case, GitHub restores archived alerts and resets the one-year inactivity clock.
The company’s announcement does not specify that re-enabling alerts automatically resolves previously reported vulnerabilities.
Restored findings still require review and remediation.
What administrators should verify afterward
After restoring alerts, teams should confirm that the repository’s expected security coverage is enabled.
They should review restored findings, identify any critical or high-priority vulnerabilities and verify whether the repository’s dependency information remains accurate.
They should also confirm that relevant owners and security teams can access the findings.
If the repository remains operationally important but is expected to receive few commits, centralized enforcement may provide more dependable continuity than relying on future pushes.
How This Fits Into Modern DevSecOps
The new policy illustrates a broader challenge in software supply-chain security: monitoring resources are finite, but vulnerability exposure is not limited to actively developed projects.
Security tools must balance scale, signal quality and operational cost.
Organizations must balance those platform optimizations against their own responsibility for deployed software.
TechnologyHQ’s CodeQL 2.27.4 analysis explored a related issue: security tooling must produce useful findings without overwhelming developers with irrelevant alerts.
The Dependabot change approaches that challenge through repository activity rather than vulnerability-detection accuracy.
Both approaches can improve operational efficiency, but neither eliminates the need to understand what software remains important.
Does the New Policy Affect GitHub Enterprise Server?
No. GitHub explicitly states that the December 8 change does not apply to GitHub Enterprise Server.
It applies to GitHub.com across all plans and GitHub Enterprise Cloud with data residency.
For data residency customers, GitHub says archived alerts remain stored in the same region as the enterprise’s other data.
Organizations operating both cloud and self-hosted GitHub environments should therefore distinguish their applicable policies rather than assume identical behavior across deployments.
Frequently Asked Questions
When will GitHub Dependabot alerts pause on inactive repositories?
GitHub says the policy begins December 8, 2026, for most eligible repositories with no qualifying activity during the previous year.
Will existing Dependabot alerts be deleted?
No. Existing alerts will be archived and restored when monitoring is re-enabled.
What activity prevents Dependabot alerts from pausing?
GitHub counts a push to any branch or tag, repository creation, or enabling Dependabot alerts.
Can enterprises keep Dependabot alerts enabled permanently?
GitHub exempts repositories covered by enforced security configurations that enable alerts, along with repositories under certain restrictive enterprise policies.
Does a push automatically restore Dependabot alerts?
Yes. GitHub says a push automatically re-enables alerts, restores archived findings and restarts the one-year clock.
Does the policy apply to GitHub Enterprise Server?
No. GitHub Enterprise Server is excluded from the announced change.
The Bottom Line
The December 8 change to GitHub Dependabot alerts is intended to make vulnerability monitoring more efficient by reducing work associated with inactive repositories.
For abandoned projects, that may be a reasonable operational optimization.
For stable software still used in production, however, inactivity is not the same as irrelevance.
The best response is to review dormant repositories before the policy takes effect, preserve monitoring for important software through appropriate security configurations and ensure that restored alerts receive proper attention.
The central security principle remains unchanged: software dependencies can become vulnerable even when the code that uses them has not changed.
Ingrid Maldine is a business writer, editor and management consultant with extensive experience writing and consulting for both start-ups and long established companies. She has ten years management and leadership experience gained at BSkyB in London and Viva Travel Guides in Quito, Ecuador, giving her a depth of insight into innovation in international business. With an MBA from the University of Hull and many years of experience running her own business consultancy, Ingrid’s background allows her to connect with a diverse range of clients, including cutting edge technology and web-based start-ups but also multinationals in need of assistance. Ingrid has played a defining role in shaping organizational strategy for a wide range of different organizations, including for-profit, NGOs and charities. Ingrid has also served on the Board of Directors for the South American Explorers Club in Quito, Ecuador.
