Find an owner first. If none exists, decide among four outcomes: archive the repository, adopt it with a named team, accept the risk with an expiry date, or delete it. Leaving it open with unread alerts is the one choice that always fails.
Why this happens
Teams reorganize, projects end, and repositories stay. GitHub notifies people with write, maintain or admin access when a Dependabot alert is raised. If those people have left the company or moved teams, the alert goes to nobody. The count grows, and it is mixed into your organization wide totals, which makes the numbers look worse and hides the repositories that matter.
Step one: classify every repository
| Signal | Meaning |
|---|---|
| Deployed to production | Needs an owner now |
| Library used by other repos | Needs an owner, and consumers need to know |
| No deploy, no commits for a year | Candidate for archive |
| Prototype or experiment | Candidate for delete |
| Documentation or content only | Low dependency risk |
Use deploy records, package registry download data and your software catalog to see which ones are live. See what is a software catalog and why vulnerability management needs one.
Step two: pick an outcome
- Adopt. A team takes ownership, updates the ownership file, and triages alerts within your normal target.
- Archive. Mark the repository read only so it can no longer be changed or released. Confirm that nothing deploys from it first.
- Delete. If the code has no value and no obligations apply, remove it, after checking retention rules.
- Accept. If it must stay live and nobody can fix it now, record the risk, name an approver and set a review date. See orphaned vulnerability exceptions.
Step three: stop it recurring
- Require an owner field for every repository. New repositories without one fail a check.
- Run a quarterly report of repositories with no activity and open alerts.
- Add an offboarding step: when someone leaves, reassign their repositories.
- Review the list of people with admin rights, since they receive the alerts.
What to watch for
A repository with no commits can still be in production through an old pipeline or a scheduled job. Do not archive on silence alone. Check for deploy jobs, cron entries and package publishing before you change anything. Also check whether other projects pull it as a dependency, since an archived library can still be shipped inside a product.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how components are tied to the projects that use them.
Quick check
Is archiving a repository enough to remove its risk?
Only if nothing deploys or consumes it. Check deployments and dependents before archiving.
Who receives alerts for an abandoned repository?
By GitHub's documented default, people with write, maintain or admin access, who may no longer be around.
Safeguard's asset discovery and SBOM generation help find repositories and components that nobody is tracking. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
