If a public registry removes a package, your mirror or cache may still serve its copy, because it holds its own files. That is helpful when a maintainer deletes a harmless library, and dangerous when the removal was for malware. Set sync and retention rules so removals are noticed and acted on.
Why this is a real design question
A proxy or mirror stores the files. Whether it keeps serving them after upstream removal depends on how it is configured. Many teams never decide, and learn the default when something goes wrong.
There are two opposite fears. One is a deleted package breaking builds. The other is a malicious package staying available inside your network after the world has moved on. Your rules must handle both.
Two kinds of removal
| Removal type | Typical reason | What you want |
|---|---|---|
| Withdrawn by the maintainer | Rename, mistake, protest, cleanup | Keep serving cached copies so builds work, record the event |
| Taken down by the registry | Malware, policy violation, legal | Stop serving it, find who pulled it, check where it ran |
Your mirror cannot tell these apart by itself. A person or a feed has to.
Rules to write down
- Subscribe to a source of malicious package reports for the ecosystems you use and match entries against what your proxy has cached.
- Keep a blocklist at the proxy that overrides the cache, so a flagged name and version stop being served at once.
- Log every download with the requesting machine or pipeline, so a block triggers a lookup of who used it.
- Decide a retention rule for removed but harmless packages, such as keep for a fixed period while teams migrate.
- Make sync deletions visible. If your mirror deletes what upstream deletes, you lose the evidence of what you used. Prefer to mark and keep.
What to do when a flagged package is in your cache
- Block the version at the proxy.
- Search the logs for downloads and the builds that used it.
- Check whether the package ran at install time or only at use time.
- Rotate secrets that were reachable on affected build machines.
- Rebuild from clean inputs and record what you found.
A note on lockfiles
A lockfile with integrity hashes tells you exactly which artifact each build used. When a removal is reported, search lockfiles and SBOMs across repositories first. It is far faster than inspecting machines.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a new report is matched against what you already depend on.
Quick check
Should our mirror delete what upstream deletes?
Not automatically. Keep a record, and use a blocklist to stop serving anything flagged as malicious.
Does a cache protect me from a malicious release?
Only for versions you cached before the release. New requests would fetch the bad version unless a rule blocks it.
Safeguard scans dependencies and builds SBOMs, runs reachability analysis, and applies policies and gates on pull requests, so the rules in this post can be checked automatically. Autonomous fix PRs are off by default, with every category on Manual. You can run a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
