The quiet repository problem: audit Dependabot coverage before December 8

An inactive repository can still be operationally important.

It might contain a deployment tool nobody has touched in months. It might hold the source for a service that is stable rather than abandoned. It might be an archived reference that teams still depend on during incidents. A quiet commit history tells you something about activity. It does not tell you whether the repository still matters.

That distinction is worth reviewing before December 8, 2026. GitHub says Dependabot alerts will turn off on most repositories that have had no activity in the past year. Existing alerts will be archived, not deleted. GitHub’s announcement applies to all plans on GitHub.com and to GitHub Enterprise Cloud with data residency; it does not apply to GitHub Enterprise Server. Read GitHub’s announcement beside these claims.

This is not a reason to manufacture commits across every quiet repository. It is a reason to make repository status explicit.

Start with scope, not remediation

Before building a list, establish which repositories are actually in scope.

GitHub describes two important exclusions. A repository is excluded when an enforced security configuration enables Dependabot alerts. An enterprise is also excluded when its policy does not allow repository administrators to enable or disable those alerts. Those details make a blanket “all inactive repositories are affected” message inaccurate.

Your first pass should answer three questions:

1. Is the repository on GitHub.com or GitHub Enterprise Cloud with data residency, rather than GitHub Enterprise Server?
2. Does an enforced security configuration already require Dependabot alerts?
3. Does enterprise policy remove the repository administrator’s ability to change the setting?

Record the answers. “We think the policy covers it” is not durable evidence.

Define activity the way GitHub does

Teams often use “inactive” to mean “nobody is working on it.” GitHub’s announced behavior uses a more specific test.

According to the announcement, activity includes a push to any branch or tag, creation of the repository, or enabling Dependabot alerts. GitHub also says a push or a repository settings change can restore alerts and restart the one-year clock. The source defines these triggers and the December 8 effective date.

That definition gives you a useful starting point, but not the final operational decision. A repository can pass the activity test and still have no clear owner. Another can fail it while remaining critical to a live system.

Run a six-field audit

For every quiet repository that may still matter, capture six fields:

• Operational purpose: What system, workflow, customer commitment, or recovery process still depends on it?
• Owner: Which named team is accountable for the repository now?
• Platform and policy scope: Which GitHub environment hosts it, and which security configuration or enterprise policy applies?
• Last qualifying activity: What event last reset the activity clock, and when?
• Alert state: Are Dependabot alerts enabled now, and can the repository administrator change that setting?
• Decision and evidence: Keep, archive, transfer, or restore—with a link to the evidence and a review date.

The point is not to create a perfect inventory in one sitting. The point is to separate quiet repositories that are intentionally governed from quiet repositories that have simply fallen out of view.

Use the least disruptive verification path

If a repository still matters and its coverage is unclear, start with read-only checks. Confirm the hosting environment, current alert setting, enforced configuration, enterprise policy, and owner. Capture screenshots or exported records where your process requires them.

If a change is needed, choose the lowest-risk authorized action. GitHub says a repository settings change can restore alerts and restart the one-year clock. A push can do the same, but a meaningless commit creates noise and may bypass the review you actually need. Prefer an intentional settings or configuration decision that leaves a clear audit trail.

Test the process on a low-risk repository before applying it broadly. Verify the saved state after the change. Record who approved it, what changed, and when the next review is due.

Do not confuse an alert setting with a security outcome

The GitHub announcement explains product behavior. It does not establish that the change will improve security, reduce alert volume, or affect a particular number of repositories in your organization.

Those outcomes require your own evidence. Track the number of repositories reviewed, the number found to be operationally relevant, current alert state, ownership gaps, and completed decisions. Avoid turning a vendor announcement into a result you have not measured.

A practical sequence for the next review

Use this order:

1. Confirm platform and policy scope.
2. List repositories with no qualifying activity in the past year.
3. Ask owners whether each repository still has an operational role.
4. Verify the current Dependabot alert state.
5. Choose keep, archive, transfer, or restore.
6. Test any change on a low-risk repository.
7. Read back the saved state and preserve the evidence.
8. Set a review date instead of relying on memory.

The quiet repository problem is not simply that code stopped changing. It is that ownership, policy, and operational importance can drift apart without a visible signal.

December 8 gives teams a useful deadline. The better outcome is a repeatable repository review that remains useful after the date passes.