Block the name and version at the mirror first, purge any cached copy, search every lockfile and build record for it, then rebuild and rotate secrets on any machine that installed it. Removal stops new installs only. Anything already installed still needs attention.
Why removal is not the end
A mirror holds copies. Once a malicious version has been fetched, it may sit in the mirror, in build caches, in container layers and on developer laptops. Deleting it from one place does not undo the installs that already happened.
The runbook
- Block. Add a rule at the mirror refusing that exact name and version, so nothing can fetch it again. Block rather than delete at first, so you keep the record of the attempt.
- Purge. Remove the cached file and any metadata that lists it. Check every repository that proxies the same upstream.
- Search. Find every lockfile, SBOM and build log that references the version. Search both current branches and recent history, since old branches get rebuilt.
- Identify exposure. List the machines and pipelines that installed it, using mirror access logs for the time window.
- Contain. For affected runners and laptops, treat them as compromised until shown otherwise. Rotate any credentials that were present during the install.
- Rebuild. Rebuild artifacts and images that included it from clean caches, and replace what was deployed.
- Fix the lockfiles. Move to a safe version or remove the dependency, and commit the change.
- Write it up. Record the timeline, scope and what you changed.
What the mirror logs should tell you
| Question | Where to look |
|---|---|
| Who fetched it | Mirror access logs by client and time |
| When was it first fetched | Earliest log entry for that version |
| Which builds used it | Build logs and SBOMs by date |
| Was it fetched after the block | Blocked request entries |
If your mirror does not keep logs long enough to answer these, fix that before the next incident, not during it.
Prepare before you need it
- Know how to block a package at the mirror in minutes, and have two people who can do it.
- Keep SBOMs for released artifacts, so a search by package name returns every affected release.
- Decide in advance who can declare a package malicious and who gets notified.
- Practise once. A short tabletop with a fake package name finds gaps cheaply.
Do not forget the upstream
Report the package to the registry's security contact so it can be taken down for everyone. Follow the registry's reporting guidance rather than posting details publicly first.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a new threat is matched against the components you use, which is the search step in this runbook.
Where Safeguard fits
Safeguard's zero-day discovery, SBOM and dependency scanning help you find which projects use an affected package. A free scan shows how an inventory looks for one repository.
Quick check
Should I delete the bad version or block it?
Block first so you keep evidence and stop new fetches, then purge once you have recorded what you need.
Do container images need rebuilding too?
Yes, if the package was installed in a layer. Rebuild from clean caches and redeploy.
Last reviewed: 19 October 2026.
