Managing Dependabot Security Alerts in Inactive GitHub Repositories

Many development teams maintain GitHub repositories that are no longer actively developed. These repositories may contain old applications, proof-of-concept projects, discontinued services, archived libraries, or code that is retained for reference.

Although development has stopped, the security risks associated with these repositories do not necessarily disappear. An application that is no longer receiving feature updates may still contain vulnerable dependencies, outdated packages, exposed credentials, or components with known security weaknesses.

GitHub Dependabot helps developers identify vulnerable dependencies and provides alerts when known security advisories affect a repository. However, managing these alerts becomes more complicated when repositories remain inactive for long periods.

GitHub has announced a change under which Dependabot alerts will be turned off for most repositories that have had no qualifying activity during the previous year. Existing alerts will be archived rather than deleted, and repository activity or manually enabling alerts can restore them.

This change makes it important for engineering teams to review inactive repositories, understand which projects still require security monitoring, and decide how to manage their existing alerts.

This article explains how Dependabot alerts work, what the inactive-repository change means, how to identify repositories that need attention, and how to build a practical security-management process.

Why Inactive GitHub Repositories Still Need Security Monitoring

A repository does not become secure simply because developers stop committing code to it.

Consider an application that was developed several years ago using an older version of ASP.NET Core, Node.js, or Python. The application may no longer receive feature updates, but its dependencies can still have publicly disclosed vulnerabilities.

For example, a repository might contain the following package configuration:

{
  "dependencies": {
    "express": "4.17.1",
    "axios": "0.21.1"
  }
}

If a security advisory identifies a vulnerability affecting one of these versions, the repository may require attention even if nobody has modified the application recently.

The same situation can occur with:

Internal tools that are still used by employees.
Older applications that remain deployed in production.
Open-source libraries that are no longer maintained.
Development projects that contain reusable components.
Sample applications that are still downloaded and executed.
Repositories containing infrastructure or deployment scripts.

An inactive repository can therefore represent an unresolved security risk.

Inactive does not necessarily mean unused

One of the biggest mistakes organizations make is treating repository activity as a reliable measure of application usage.

A repository may have no recent commits but still support an active production application.

For example:

Repository	Recent development	Actual usage	Security concern
Legacy payment service	No commits	Production	High
Internal reporting tool	No commits	Used by employees	Medium to high
Old learning project	No commits	Not used	Lower
Archived prototype	No commits	No deployment	Depends on exposure
Shared internal library	Occasional commits	Used by multiple applications	High

Repository activity is only one signal. Before disabling security monitoring or archiving a project, determine whether the application is still deployed, consumed, or accessible.

Understanding the Dependabot Inactive Repository Change

Dependabot alerts help repository owners identify vulnerable dependencies through GitHub's dependency graph and security advisory information.

GitHub announced that starting December 8, 2026, Dependabot alerts will be turned off for most repositories with no qualifying activity during the previous year.

The existing alerts will be archived rather than deleted. They can be restored when Dependabot alerts are enabled again.

The change applies to GitHub.com and GitHub Enterprise Cloud with data residency. It does not apply to GitHub Enterprise Server.

What counts as repository activity?

GitHub identifies the following actions as qualifying activity for this policy:

Pushing to any branch or tag.
Creating the repository.
Turning on Dependabot alerts.

This distinction is important because not every interaction with a repository necessarily resets the inactivity period.

For example, simply opening an issue, reviewing a pull request, or viewing the repository should not be assumed to count as qualifying activity under this announcement.

Teams should review the official policy rather than relying on a general understanding of GitHub repository activity.

What happens when Dependabot alerts are turned off?

The change does not mean that GitHub deletes the repository or its dependency files.

Instead, the alert-monitoring state changes.

Area	Expected behavior
Repository source code	Remains available
Existing Dependabot alerts	Archived, not deleted
New Dependabot alert monitoring	Turned off for affected repositories
Repository activity	Can automatically restore alerts
Manual re-enablement	Restores archived alerts
Security configuration	Can prevent automatic deactivation when alerts are enforced
GitHub Enterprise Server	Not covered by this change

The important point is that an archived alert is not the same as a resolved vulnerability.

If a repository becomes inactive and its alerts are archived, the underlying vulnerable dependency may still exist in the source code.

Which repositories are excluded?

GitHub has identified exceptions to the automatic deactivation behavior.

Repositories covered by an enforced security configuration that enables Dependabot alerts will not have alerts automatically turned off.

Repositories in enterprises where the Dependabot alerts policy does not allow repository administrators to enable or disable alerts are also excluded.

Organizations should review their security configurations and enterprise policies to understand which repositories are protected by these exceptions.

How to Identify Inactive Repositories That Need Attention

Before deciding how to manage Dependabot alerts, create an inventory of repositories across the organization.

Start by identifying repositories that have not received qualifying activity during the previous year.

GitHub CLI can help retrieve repository information.

For example:

gh repo list ORGANIZATION_NAME \
  --limit 200 \
  --json nameWithOwner,isArchived,pushedAt \
  --jq '.[] |
    [
      .nameWithOwner,
      .isArchived,
      .pushedAt
    ] |
    @tsv'

This command returns the repository name, archived status, and latest push timestamp.

The pushedAt value is useful for an initial review, but it should not be treated as a complete implementation of GitHub's inactivity policy. Repository creation and enabling Dependabot alerts are also qualifying events, and the policy's activity tracking should be considered separately.

Identify repositories with no recent pushes

You can use Python to process the repository inventory and identify repositories whose latest push is older than a year.

from datetime import datetime, timedelta, timezone
import json

with open("repositories.json", encoding="utf-8") as file:
    repositories = json.load(file)

cutoff = datetime.now(timezone.utc) - timedelta(days=365)

for repository in repositories:
    pushed_at = repository.get("pushedAt")

    if not pushed_at:
        print(
            repository["nameWithOwner"],
            "No push timestamp available"
        )
        continue

    pushed_date = datetime.fromisoformat(
        pushed_at.replace("Z", "+00:00")
    )

    if pushed_date < cutoff:
        print(
            repository["nameWithOwner"],
            "Requires inactivity review"
        )

This example identifies repositories that need investigation based on their latest push. It does not establish whether GitHub will deactivate their alerts.

A production inventory should also include repository creation dates, security settings, deployment status, ownership, and the date Dependabot alerts were enabled.

Classify repositories by business importance

After collecting repository information, classify each project according to its actual usage and business impact.

A useful inventory might look like this:

Repository	Last push	Production usage	Owner	Recommended action
payment-service	8 months ago	Yes	Payments team	Keep alerts enabled
legacy-reporting	18 months ago	Yes	Data team	Review and remediate
old-demo-app	2 years ago	No	Developer tools	Consider archiving
internal-library	14 months ago	Yes	Platform team	Keep alerts enabled
prototype-api	3 years ago	No	Unassigned	Review ownership

This approach prevents an organization from treating every inactive repository in the same way.

A project that is no longer developed but remains part of a production deployment needs a different security strategy from an abandoned demonstration application.

How to Review Dependabot Alerts in a Repository

Once you identify repositories that need attention, review their existing security alerts.

Open the repository on GitHub and navigate to its Security and quality section. Select the Dependabot vulnerabilities view to inspect the available alerts.

Depending on the repository interface and permissions, you can review:

Open security alerts.
Closed and dismissed alerts.
Vulnerable package names.
Affected dependency versions.
Ecosystem information.
Severity and advisory details.
Available fixed versions.
Related Dependabot security update pull requests.

Prioritize alerts based on risk

Not every Dependabot alert requires the same response.

A useful starting point is to review the severity, dependency scope, exploitability information, and application exposure.

For example:

Factor	What to investigate
Severity	Is the vulnerability classified as critical, high, medium, or low?
Dependency scope	Is the package used in production or only during development?
Exposure	Is the application publicly accessible?
Fixed version	Is a patched version available?
Reachability	Can the application reach the vulnerable functionality?
Business impact	Does the affected application support an important business process?

Where available, Dependabot reachability analysis can provide additional evidence about whether application code calls a vulnerable function.

However, reachability information should be interpreted carefully. An unreachable verdict does not mean that a dependency can be ignored permanently, and a reachable verdict does not by itself prove that an attacker can exploit the vulnerability.

The application's deployment and usage context must still be considered.

Review production and development dependencies separately

A vulnerability in a production dependency may directly affect a deployed application.

A development dependency may not be included in the production runtime, but it can still introduce risks through build tools, test environments, or developer machines.

For example:

{
  "dependencies": {
    "express": "4.17.1"
  },
  "devDependencies": {
    "jest": "26.6.3"
  }
}

In this example, Express is a production dependency, while Jest is a development dependency.

Both should be reviewed, but the remediation priority may differ depending on the vulnerability and how the packages are used.

How to Fix Vulnerabilities in Inactive Repositories

Once an alert has been reviewed, choose a remediation approach based on the repository's purpose.

Update the vulnerable dependency

If the application is still used, updating the vulnerable dependency is usually the preferred approach.

For example, if a dependency has a security fix available, update the package manifest and lockfile to a compatible patched version.

For ecosystems supported by Dependabot security updates, GitHub can automatically create a pull request when a suitable fix is available.

A typical workflow looks like this:

Dependabot detects vulnerability
          |
          v
Security alert is created
          |
          v
Fixed version is available
          |
          v
Dependabot creates pull request
          |
          v
CI tests and compatibility checks
          |
          v
Developer reviews the changes
          |
          v
Pull request is merged
          |
          v
Alert is resolved

Even if the repository is inactive, a security-only dependency update may be necessary when the application remains deployed.

Before merging, verify that the update does not introduce breaking changes or unexpected behavior.

Enable Dependabot security updates

Dependabot security updates can automatically create pull requests for vulnerable dependencies when suitable fixes are available.

A repository can configure Dependabot through its settings and a dependabot.yml file.

For example:

version: 2

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

  - package-ecosystem: "nuget"
    directory: "/"
    schedule:
      interval: "weekly"

This configuration defines update schedules for npm and NuGet dependencies.

It is important to distinguish Dependabot alerts from Dependabot version updates and security updates:

Dependabot alerts identify known vulnerable dependencies.
Dependabot security updates create pull requests to address supported vulnerabilities.
Dependabot version updates help keep dependencies current even when no known vulnerability has been reported.

Enabling version updates does not automatically guarantee that every security alert will be resolved. Review the relevant settings and pull requests separately.

Archive repositories that are genuinely no longer needed

If a repository is no longer used, has no active deployment, and does not need further maintenance, archiving may be appropriate.

Before archiving, verify that:

No production application depends on it.
No other repository consumes its packages.
No deployment pipeline references its source.
No active team relies on its scripts or configuration.
Required source code and documentation have been retained.
Repository ownership and business approval are clear.

There is an important security distinction here: GitHub documentation states that Dependabot does not scan archived repositories.

Therefore, archiving should not be treated as a way to preserve continuous vulnerability monitoring. If a repository must remain security-monitored, evaluate the available alternatives before archiving it.

Keep monitoring enabled for production dependencies

Some repositories may not receive regular commits but still support business-critical applications.

For these repositories, consider keeping Dependabot alerts enabled through the appropriate security configuration.

An enforced security configuration can also protect eligible repositories from the announced inactivity-based deactivation.

The decision should be based on whether the code remains operationally important, not simply on how recently someone pushed a commit.

Managing Dependabot Alerts Across Multiple Repositories

Organizations with hundreds of repositories need a repeatable process instead of relying on individual developers to inspect every project.

GitHub provides APIs and organization-level security capabilities that can help centralize this work.

Use the GitHub REST API

The GitHub REST API provides endpoints for retrieving Dependabot alerts.

For example, the following endpoint retrieves alerts for a repository:

GET /repos/OWNER/REPO/dependabot/alerts

An authenticated request can retrieve alert information programmatically.

Example using GitHub CLI:

gh api \
  repos/OWNER/REPO/dependabot/alerts \
  --paginate

The response contains information about alerts, including their state and affected dependency details.

The authenticated user or application must have the required repository permissions, and Dependabot alerts must be available and enabled for the repository.

Build a centralized security inventory

For larger organizations, combine repository information with Dependabot alert data.

A useful inventory can include:

Field	Purpose
Repository name	Identifies the project
Repository owner	Establishes accountability
Last push date	Helps identify inactivity
Archived status	Identifies repositories no longer under active development
Dependabot enabled	Shows whether alert monitoring is active
Open alert count	Indicates outstanding vulnerabilities
Highest severity	Supports risk-based prioritization
Production usage	Identifies operational impact
Remediation owner	Establishes responsibility
Review date	Supports periodic assessment

This inventory can be exported to a dashboard or reporting system.

For example, a security team could review all repositories with production usage, no recent development activity, and unresolved high-severity alerts.

That provides a more useful view than simply counting inactive repositories.

Use organization-level security configurations

Organizations can use security configurations to apply consistent security settings across multiple repositories.

Depending on the available plan and configuration, these settings can help standardize features such as Dependabot alerts and other code security capabilities.

An enforced configuration is particularly relevant to the inactive-repository change because repositories covered by an enforced configuration that enables Dependabot alerts are excluded from automatic deactivation.

For organizations with important legacy applications, this can reduce the risk of losing monitoring simply because a repository has not received recent commits.

Common Mistakes to Avoid

Mistake	Why it causes problems	Better approach
Treating inactive repositories as unused	Production applications may still depend on them	Verify actual application usage
Assuming archived alerts are resolved	Archiving does not fix vulnerable dependencies	Review and remediate vulnerabilities
Archiving repositories without checking dependencies	Other projects or deployments may still rely on them	Perform dependency and deployment checks
Ignoring security updates in legacy applications	Known vulnerabilities can remain exploitable	Prioritize production-facing projects
Treating every alert as equally important	High-risk vulnerabilities may be overlooked	Use severity, exposure, and reachability evidence
Relying only on recent push dates	Other qualifying activity can affect the inactivity policy	Review the complete policy and repository history
Assuming Dependabot scans archived repositories	GitHub documentation identifies archived repositories as outside Dependabot scanning	Choose an appropriate monitoring strategy

Best Practices for Managing Inactive Repository Security

A consistent process helps engineering teams avoid losing track of older projects.

Maintain a central inventory of active, inactive, and archived repositories.
Assign an owner to every repository that remains operationally important.
Review production usage before disabling security monitoring.
Keep Dependabot alerts enabled for repositories that still support deployed applications.
Use security configurations to enforce monitoring where appropriate.
Prioritize vulnerabilities based on severity, exposure, dependency scope, and business impact.
Review security update pull requests before merging them.
Archive only repositories that have been confirmed as unnecessary.
Periodically check whether archived projects are still referenced by other applications.
Document why an alert was dismissed or why a repository was excluded from active maintenance.

A periodic repository review should be part of the organization's software maintenance process. It helps teams identify abandoned projects, forgotten dependencies, and security risks that may otherwise remain unnoticed.

Conclusion

Inactive GitHub repositories can still contain vulnerable dependencies and create security risks, particularly when their applications remain deployed or their packages are consumed by other projects.

The announced change to Dependabot alerts makes repository ownership and security inventory management even more important. Most repositories without qualifying activity during the previous year will have their alerts turned off, while existing alerts will be archived rather than deleted.

Engineering teams should not respond by pushing meaningless commits simply to keep alerts active. Instead, they should identify repositories that still matter, verify their usage, review outstanding vulnerabilities, and apply the appropriate security configuration.

For production dependencies, keep monitoring enabled and remediate vulnerabilities. For projects that are genuinely no longer needed, verify their dependencies and archive them through an approved process.

The goal is not to keep every repository active forever. It is to ensure that every repository with a continuing security or business responsibility has an owner and an appropriate monitoring strategy.