A repository does not have to be deleted to stop receiving security attention.
It can simply become inactive.
Many organizations have repositories that are no longer being actively developed but are still kept around for reference, maintenance, internal tools, old services, experiments, or applications that have been replaced but not yet removed. These repositories can still contain dependencies with known vulnerabilities.
That makes GitHub's latest change to Dependabot important for teams that keep older repositories around.
Starting December 8, 2026, GitHub will turn off Dependabot alerts for most repositories that have had no activity during the previous year. Existing Dependabot alerts will be archived rather than deleted, and alerts can be restored when Dependabot is enabled again. (github.blog)
This does not mean an old vulnerability suddenly becomes harmless.
It means the repository may stop receiving new Dependabot alert activity unless the repository is reactivated or an organization-level security configuration keeps Dependabot enabled.
For teams with hundreds or thousands of repositories, this is worth reviewing before the change takes effect.
What Counts as an Inactive Repository?
GitHub is using repository activity to determine whether Dependabot alerts should remain active.
For this particular change, activity includes:
- Pushing to any branch or tag
- Creating the repository
- Enabling Dependabot alerts
If none of these activities occurs during the relevant one-year period, GitHub can turn off Dependabot alerts for the repository. (github.blog)
This is important because normal human assumptions about repository activity may be different from GitHub's definition.
For example, a repository might still be:
- Used as a reference
- Deployed manually
- Read by developers
- Connected to internal documentation
- Retained for compliance
- Used occasionally for troubleshooting
None of those activities necessarily count as the activity GitHub uses for this policy.
A repository can therefore be important to an organization while still being considered inactive by Dependabot.
What Happens to Existing Dependabot Alerts?
The existing alerts are not simply deleted.
GitHub says the alerts are archived when Dependabot alerts are paused because of repository inactivity. They can be restored when Dependabot alerts are enabled again. (github.blog)
This distinction matters.
Consider an old application with dependencies like this:
Old Application
|
+-- Newtonsoft.Json
+-- Serilog
+-- Database Driver
+-- Authentication Library
Suppose the application has not received any code changes for more than a year.
A new vulnerability is later discovered in one of those dependencies.
If Dependabot alerts have been paused because the repository is inactive, the repository is no longer receiving the normal alerting behavior from Dependabot.
The dependency can still be vulnerable.
The difference is that the automated alerting mechanism is no longer actively watching the repository in the same way.
This is why inactive repositories should be classified based on business importance, not simply based on whether developers are currently committing code.
Why Old Repositories Still Matter
An old repository is not automatically a safe repository.
Imagine an organization has this structure:
Repositories
|
+-- customer-api
+-- payment-service
+-- admin-portal
+-- legacy-api
+-- old-reporting-tool
+-- migration-scripts
+-- archived-project
The team may consider the last four repositories unimportant because they are no longer part of active development.
But an attacker does not necessarily care whether a repository is actively maintained.
A vulnerable dependency can still create risk if the application remains deployed, an old service is still accessible, credentials are stored somewhere around the project, or the repository contains useful information about the organization's infrastructure.
The first question should therefore be:
“Is this repository really retired?”
If the answer is no, simply allowing Dependabot to become inactive may not be appropriate.
The Difference Between Inactive and Archived
These two concepts are easy to confuse.
An inactive repository is a repository where there has not been enough activity for GitHub's Dependabot policy.
An archived repository is one that has explicitly been placed into GitHub's archived state.
These are not the same thing.
GitHub already has limitations around archived repositories. Dependabot does not scan archived repositories. (docs.github.com)
That means teams should not assume that simply marking a repository as archived is a good way to preserve security monitoring.
If the application is genuinely retired, archiving can make sense.
If the application is still deployed or contains components that need security monitoring, it should be treated as an active security concern.
How Dependabot Finds Vulnerable Dependencies
Dependabot alerts are based on the repository's dependency graph.
GitHub analyzes dependency manifests and lock files to identify dependencies used by the repository. When a known vulnerability affects a dependency in that graph, Dependabot can create an alert. (docs.github.com)
For example, a .NET project might contain:
<ItemGroup>
<PackageReference Include="Some.Package" Version="1.2.3" />
</ItemGroup>
If that package version is associated with a known vulnerability, Dependabot can report the issue when the dependency is represented in the repository's dependency graph.
The important part is that Dependabot is not simply reading every file and guessing which libraries your application uses.
The dependency graph is the foundation for this process.
That means keeping project and lock files accurate is important even for security monitoring.
Old Dependencies Can Become a Hidden Problem
Inactive repositories often have another problem: dependency drift.
An actively maintained application may regularly receive:
Dependency updates
Security patches
Runtime updates
Framework updates
Build changes
An inactive application often receives none of these.
Over time, the difference becomes large.
For example:
Active application
Package 1.5
|
+-- update
|
Package 1.8
|
+-- security fix
|
Package 1.9
An inactive application might remain at:
Package 1.5
|
+-- no maintenance
|
+-- known vulnerabilities
The longer the repository remains untouched, the more difficult it can become to understand its actual security position.
This is why repository lifecycle management and dependency management should be connected.
When a project is retired, the organization should explicitly decide whether it is:
- Completely removed
- Archived and no longer deployed
- Kept for reference
- Still running and therefore requiring security maintenance
Each case needs a different approach.
What Happens When Dependabot Is Turned Back On?
The good part of GitHub's change is that reactivation does not mean starting from an empty security state.
GitHub says that pushing to the repository or enabling Dependabot alerts again restores the archived alerts, and the one-year activity clock starts over. (github.blog)
For example:
Repository becomes inactive
|
v
Dependabot alerts paused
|
v
Existing alerts archived
|
v
Developer pushes a commit
|
v
Dependabot alerts restored
This makes the change reversible.
However, teams should not use an arbitrary commit as a security strategy.
If a repository needs continuous security monitoring, it is better to configure the appropriate security policy rather than periodically touching the repository just to keep it active.
How to Keep Dependabot Alerts Enabled
GitHub provides a way to prevent this inactivity behavior through security configuration.
GitHub says repositories with an enforced security configuration that enables Dependabot alerts will not have alerts turned off because of inactivity. The same applies to enterprises where repository administrators are not allowed to disable Dependabot alerts. (github.blog)
This is particularly useful for organizations with security requirements.
For example:
Organization
|
+-- Production repositories
+-- Internal services
+-- Legacy applications
+-- Security-sensitive repositories
The organization can define which repositories must continue receiving security monitoring regardless of normal development activity.
This is better than expecting individual developers to remember which old repositories need special treatment.
Which Repositories Should You Review First?
Do not start by reviewing every inactive repository in random order.
Start with repositories that still have business or operational value.
A useful priority order is:
1. Production applications
2. Public-facing services
3. Internal services with sensitive data
4. Repositories connected to deployment systems
5. Repositories containing infrastructure code
6. Shared libraries still used by other systems
7. Old applications still running somewhere
8. Truly retired projects
This gives security teams a practical way to focus their effort.
A repository that has not changed for two years but still runs an internal API is a much different security concern from a repository that was created as a proof of concept and never deployed.
Check Repositories That Are Still Deployed
This is one of the most important checks.
GitHub activity tells you about repository activity.
It does not necessarily tell you whether the software is still running.
A service can have zero commits for a year and still be running in:
Production
Staging
A virtual machine
A container
A Kubernetes cluster
A customer's environment
An internal server
Therefore, repository activity should not be used as the only signal for deciding whether a dependency is still important.
A simple inventory can help:
| Repository State | Security Action |
|---|
| Active and deployed | Keep Dependabot enabled |
| Inactive but deployed | Keep security monitoring |
| Inactive but business-critical | Keep monitoring and review ownership |
| Inactive internal tool | Review risk and usage |
| Completely retired | Archive or remove |
| Proof of concept never deployed | Confirm and retire if appropriate |
The important distinction is whether the software still has an operational path to users or systems.
What About Shared Libraries?
Shared libraries create another problem.
Suppose a repository has not changed for a long time, but another active application still consumes it.
The library repository may look inactive.
The application using it is active.
That does not make the library irrelevant.
For example:
Shared Library
|
+---- Service A
|
+---- Service B
|
+---- Internal Tool
If the shared library contains a vulnerable dependency, the security impact may extend to all of those consumers.
This is why dependency ownership should be understood at the organization level rather than only repository by repository.
Before allowing Dependabot alerts to pause, check whether another active project still depends on the repository's packages.
Check Your Dependency Graph
Dependabot depends on accurate dependency information.
GitHub notes that the dependency graph processes manifest and lock files, while certain dependencies that are not represented through those mechanisms may require dependency submission to appear in the graph. (docs.github.com)
This matters for projects that generate dependencies dynamically or use unusual build systems.
For example, a dependency that exists only as a loose file copied into a repository may not automatically appear in the dependency graph.
Likewise, dependencies whose versions are resolved through variables may not always be represented as expected.
If your security inventory looks incomplete, do not assume that Dependabot has scanned everything.
Check the dependency graph itself.
Check Old Alerts Before They Are Archived
Teams should also review the existing Dependabot backlog before repositories become inactive.
An old repository may already have alerts such as:
Critical
High
Moderate
Low
Do not assume that these alerts can be ignored simply because the repository is no longer changing.
Instead, determine whether the repository is:
- Still deployed
- Still reachable
- Still used internally
- Still depended upon
- Completely retired
If it is still used, the dependency vulnerability needs a security decision.
That decision could be an upgrade, mitigation, removal of the affected dependency, or retirement of the application.
The important part is that the decision should be explicit.
A Practical Review Process for Organizations
If your organization has many repositories, use a repository lifecycle review rather than handling this manually one repository at a time.
Step 1: Find inactive repositories
Create a list of repositories that have not had meaningful activity during the relevant period.
Step 2: Check whether they are still deployed
Compare the repository list with your deployment inventory.
Step 3: Check Dependabot alerts
Look for unresolved vulnerabilities and prioritize critical and high-risk issues.
Step 4: Check dependency consumers
For shared libraries, identify active applications that still depend on them.
Step 5: Classify each repository
Use categories such as:
Active
Maintenance
Legacy but deployed
Reference only
Retired
Unknown
The Unknown category is important.
If nobody knows whether an application is still running, that is itself a lifecycle problem.
Step 6: Apply the right security policy
Repositories that still matter should continue receiving security monitoring.
Repositories that are genuinely retired can be archived or removed according to organizational policy.
Step 7: Assign ownership
Every repository that remains operational should have an owner responsible for security issues.
Without ownership, a Dependabot alert can sit unresolved regardless of whether GitHub continues generating alerts.
Common Mistakes
Assuming No Commits Means No Risk
A repository can be inactive and still power a production application.
Repository activity is not the same as application usage.
Archiving Everything Old
An old repository may still be used by production systems or other projects.
Confirm its role before archiving it.
Treating Dependabot as the Entire Security Process
Dependabot identifies known vulnerable dependencies.
It does not replace dependency review, application security testing, infrastructure security, or incident response.
Ignoring Shared Libraries
An inactive library can still affect several active applications.
Always check downstream consumers.
Using Fake Commits to Keep a Repository Active
Adding meaningless commits simply to prevent Dependabot from pausing is the wrong solution.
If security monitoring is required, use the appropriate GitHub security configuration.
If the project is truly retired, retire it properly.
Assuming Archived Alerts Are Deleted
GitHub states that the existing alerts are archived rather than deleted when Dependabot alerts are paused because of repository inactivity. They can be restored when Dependabot is enabled again. (github.blog)
This distinction matters for security history and remediation tracking.
A Simple Repository Security Checklist
Before allowing an older repository to become inactive, ask:
| Question | Why It Matters |
|---|
| Is the application still deployed? | Running software still creates security risk |
| Is the repository used by another project? | Shared code can affect active applications |
| Are there open Dependabot alerts? | Known vulnerabilities need review |
| Is the repository public? | Public exposure can increase risk |
| Does it contain infrastructure code? | Old infrastructure can expose operational details |
| Does it contain credentials or sensitive configuration? | Historical files may contain sensitive information |
| Does it have an owner? | Someone needs to handle security issues |
| Is it genuinely retired? | Retirement determines the right security action |
| Should Dependabot remain enabled? | Critical repositories may need continuous monitoring |
This review does not have to be complicated.
The important part is knowing which repositories are actually still part of the organization's software environment.
What Developers Should Do Before the Change
If you maintain an organization with older GitHub repositories, do not wait until alerts disappear.
Review inactive repositories and separate them into two groups.
The first group contains projects that are genuinely retired.
Those can go through your normal retirement process.
The second group contains applications, libraries, infrastructure projects, or internal tools that are still relevant even though developers rarely push changes.
Those repositories should continue receiving security monitoring.
GitHub's new behavior is primarily about keeping Dependabot focused on actively maintained repositories. It does not change the fact that old software can contain old vulnerabilities.
The important task for engineering teams is therefore repository lifecycle management.
If nobody knows whether an old repository is still important, the problem is larger than Dependabot.
Summary
Inactive repositories can still contain vulnerable dependencies, even when no new code is being written.
Review older repositories before Dependabot alerts are paused. Keep monitoring for projects that are still deployed or used, and properly retire repositories that are genuinely finished. Dependabot can help identify dependency risks, but your team still needs to know which software is actually running.
Join the conversation! Your thoughts help the community grow.