An archived upstream is read only, so no more fixes will arrive there. Your fork stops being a patch on a living project and becomes the only place security fixes can happen. Decide whether to adopt it as your own, replace it with another library, or freeze it and accept the risk in writing.
What archived means
GitHub's documentation says archiving makes a repository read only for all users and indicates that it is no longer actively maintained. Issues, pull requests, code, releases, commits, tags, branches, comments and permissions become read only until someone unarchives it. Archived does not mean deleted. The code stays readable and forkable, but nothing new is accepted.
Not every abandoned project is archived, and not every archived project is dead for good, since an owner can unarchive. Treat the status as a strong signal, not a verdict.
What changes for you
Before, you could send patches upstream and drop yours when they merged. Now you cannot. A new advisory for the library will not be fixed by the maintainers. Every fix is yours to write, or you must move away.
Also check the people around it. Is there a community fork that others have picked up? A well supported successor may be better than a private fork. Compare activity and ownership honestly, and apply the same checks you would to any new dependency.
Three options
| Option | When it fits | Costs |
|---|---|---|
| Adopt the fork as your own project | The library is core, small, and you have the skill | You own fixes, releases and advisories |
| Replace it | Alternatives exist with similar function | Migration work, testing |
| Freeze it with a documented exception | Low risk use, short remaining life | Growing exposure, needs expiry and review |
See when to fork an abandoned dependency for the fork decision itself, and vendor wont patch: accept, replace or wrap for the same logic with a commercial vendor.
If you adopt it
- Name an owner and add the fork to your register. See the fork register.
- Rename and re-version it so nobody mistakes it for the original.
- Check the license and keep all notices. See notices for MIT and Apache code.
- Create a security contact and a way to report issues to you, since there is no upstream to receive them.
- Review the code for known problems now, with static analysis and a dependency scan, because nobody else will.
- Publish your own advisories when you fix something, so downstream users learn about it.
If you freeze it
Write down the accepted risk, the compensating controls, an expiry date and an owner. Frozen forks without expiry are how old flaws live for years. See vulnerability exceptions and risk acceptance for what a good exception contains.
Where Safeguard fits
Safeguard's reachability analysis and dependency scanning help judge how exposed your build is to flaws in an abandoned library, and its policies can enforce expiry on exceptions. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. See how exposure is judged beyond the raw finding.
Quick check
Does archived mean the code is gone?
No. It stays readable and forkable. It becomes read only and signals that it is no longer actively maintained.
Can an archived repository come back?
Yes. An owner can unarchive it, so keep checking the status while you decide.
Sources
Last reviewed: 19 October 2026.
