When the package is deleted, your own records become the evidence. Rebuild the story from lockfile history, build logs, proxy and cache contents and stored inventories, and say plainly which parts you cannot verify. Do not rely on the registry page, because it may no longer exist.
The problem
Registries usually remove confirmed malicious versions quickly. That helps everyone going forward, but it takes away the thing you wanted to inspect. Names, versions and descriptions may vanish or be replaced with a notice. Anyone writing a postmortem a week later may find nothing.
What still exists
- Lockfile history. Shows which version your builds asked for and when.
- Build logs. Show what was installed and what scripts ran, if retention allows.
- Proxy or mirror. Your own package proxy may hold the archive and the access log. Preserve both before the proxy purges its own copy.
- Local caches. Developer machines and CI caches may hold the archive. Hash it, then quarantine it.
- Stored inventories. A per build inventory is the cleanest record of which version you had.
- Third party write ups. Public advisories and researcher posts. Treat them as claims, link them with the date you read them, and say where you have confirmed them and where you have not.
How to word what you cannot verify
| Situation | Wording |
|---|---|
| You hold the archive and hash | "We retrieved the archive from our proxy and confirmed its hash." |
| Only a lockfile entry remains | "Our lockfile shows version X was requested on this date. We could not inspect the archive." |
| Only external reports exist | "A published advisory states Y. We have not independently verified this." |
Never describe behaviour of code you never saw as if you had. Cite the source and its date.
Preserve before you purge
Resist the urge to clear caches as part of recovery. First copy the archive, its hash and the logs to a restricted location, with a note of who collected them and when. Do not run the sample outside an isolated analysis environment, and do not open it on a normal workstation.
Assume the worst on exposure, then narrow
If you cannot inspect the code, treat environments that ran it as exposed and rotate the credentials they could read. Then narrow using logs of what those credentials did. This is safer than waiting for certainty.
Fix the evidence gap
Deleted packages expose a weakness many teams share: they depend on the registry as their memory. Actions to consider: keep a mirror with retention, store inventories per build, and extend build log retention for the window your incident process requires.
Reuse the structure
Everything else in the postmortem stays the same: summary, impact, detection, causes, actions. The difference is a clear note on evidence limits near the top.
Quick check
Can we cite the registry page for the bad version?
Only if you captured it while it existed, with the date. Otherwise cite an advisory and say you could not verify it.
Should we run the cached archive to see what it does?
Not on a normal machine. Hash it, quarantine it, and analyse only in an isolated environment, ideally by someone trained for it.
Last reviewed: 19 October 2026.
