A widely used internal package version has a serious flaw — when is withdrawing it worse than deprecating it?

## Reframing the decision The instinct on discovering a flaw in a version you own is to make it go away. On an internal registry you actually can, which is exactly why the decision needs governing. The question to put to yourself is not "can I remove it" but **"what does removal buy, and who pays for it?"** ## What removal costs Removing a version changes the resolvable universe for every consumer at once: - **Builds break immediately.** Any pipeline that resolves that version fails on its next run. On an estate of a few hundred services, a mid-morning removal produces a wave of red pipelines within the hour, none of whose owners know why. - **Rebuilds of the past stop working.** Reproducing a build from last quarter, rebuilding a base image, or regenerating an artifact for an audit all depend on old versions still resolving. Removal quietly makes history unbuildable. - **Rollback paths can be severed.** The known-good release you would fall back to may itself depend on the version you just removed. Removing the bad version to reduce risk, and thereby destroying the escape route, is a genuine own-goal. - **The failure is uninformative.** A resolution error names a missing version, not a security decision. Consumers experience a mystery outage rather than a notification. ## What removal buys For an ordinary vulnerable version: very little. The teams already running it have it in lockfiles, caches and built images, and none of those are affected. New adopters can be stopped by flagging alone, which costs nothing. Removal reaches a population that is nearly empty. It buys something real in exactly three situations: the artifact carries a **live secret**; it carries **malicious or sabotaged code**, so continued distribution is itself harm; or a **legal or licensing obligation** requires it not be distributed. Notice all three share a property — the hazard is the artifact's continued availability, not the flaw's presence in running systems. ## The defensible default policy For an internal registry, a policy that holds up under scrutiny looks like this: 1. **Publish the fixed version first.** Never flag or remove anything before consumers have a destination; otherwise you have created work with nowhere to put it. 2. **Flag the bad version so it is not selected by new resolution.** Cheap, reversible, and it stops the population growing. 3. **Push an advisory into the channel consumers' tooling reads**, keyed to the affected version range, so affected teams are told by their own scanners rather than by a broken build. This is the step that actually moves people, and it is the one most often skipped. 4. **Set a deadline proportionate to real exposure**, not to a severity number. A base severity score describes the flaw in the abstract; it does not know whether the vulnerable code path is reachable in your services, whether the component is exposed to untrusted input, or what the compensating controls are. Deriving a company-wide removal deadline from a base score alone produces both fire drills and complacency. 5. **Require a named approver for hard removal**, with the justification recorded. Make the decision visible rather than a capability any maintainer exercises alone at 09:00. 6. **Communicate before, not after.** If removal is going ahead, the affected owners hear it first, with a window and a migration path. ## The organisational layer The part that makes this a leadership question rather than a technical one is that the person who decides is rarely the person who pays. A platform team removing a version absorbs no cost; a few hundred service teams absorb all of it, and they were not consulted. That asymmetry is why the capability should be gated by policy rather than by permissions alone. The second-order fix is to make withdrawal less necessary. If adoption is measurable — you know which services resolve which versions — you can drive migration precisely instead of using removal as a blunt forcing function. If services are able to take a patch release quickly, the fixed version does the work and the bad one simply stops being used. Estates that reach for deletion tend to be estates that cannot see or move their consumers, and that is the actual problem to invest in. ## The one-line stance Withdrawal is a control over **future adoption** that costs **current availability**. Use the cheap, reversible version of it by default; spend the expensive, irreversible version only when the artifact's existence is the hazard, and only with a name attached to the decision.