npm registry keeps removed-version timestamps but drops the reason (Sept 2025 campaign as evidence)
npm keeps timestamps for removed package versions but drops the removal reason, hindering supply-chain response.
An oss-security post reports a retention asymmetry in npm's public package documents that matters for supply-chain incident response. When a version is removed, it disappears from the versions map and direct fetches return 404, but its key usually remains in the time map of publish timestamps. The registry therefore preserves evidence that a version existed while dropping the reason for removal. The author points to a September 2025 campaign as evidence.
- Removed npm versions leave the versions map and direct fetches return 404.
- Their publish timestamps usually remain in the package time map.
- The registry keeps that a version existed but drops why it was removed.
- The author cites a September 2025 campaign as evidence for incident response.
From the original article
Posted by ezraax on Sep 23 Hi, Sharing a registry-metadata observation that matters for supply-chain incident response. I audited npm's public package documents and found a retention asymmetry. Each package document has a `time` map (per-version publish stamps) and a `versions` map (the manifests).
seclists.org
A short excerpt; the article and its images belong to the publisher. Summary, key facts and assessment above are AI-written from the article and can be wrong.