If a compromised dependency is inside a release customers already run, you cannot pull it back. You can identify which releases contain it, ship a clean release quickly, tell customers what is affected and what to do, and keep a record. Speed depends on knowing exactly what each release contained.
Why shipped software is different
For a hosted service, a fix replaces the running code. For software customers install, such as desktop apps, mobile apps, agents, CLIs or self-managed packages, old versions stay in the field until customers update. Some never will. That changes the job from "fix it" to "fix it, make the fix easy to get, and help people understand their exposure."
Step 1: Map the bad version to releases
You need a release by release answer, not a repository answer.
- Match the compromised version against the build inventory or SBOM stored for each release.
- Note the build dates. The bad version may have entered after one release and left before the next.
- Check each distribution channel: direct download, app stores, package managers, container registries, internal portals.
If you did not keep a per release inventory, rebuild one by inspecting the shipped artifacts themselves. This is slower, and it is a gap to close afterward.
Step 2: Decide whether the code runs for customers
Not every inclusion means customer exposure. Ask three questions.
- Is the package part of the shipped bundle, or just a build tool that ran on your machines?
- If it is in the bundle, does the malicious behavior depend on install time, build time, or runtime?
- Does the behavior need access, such as credentials or network, that exists in the customer environment?
Where you cannot answer with confidence, assume exposure and say so internally. Your security team and an independent reviewer should check the reasoning, not a single engineer.
Step 3: Ship the clean release
Rebuild from a corrected lockfile pinned to a known good version, verify the artifact contents, and release through every channel where the bad build is live. Use the same checks as any release, plus an extra look at the final package listing. If a channel supports pulling or hiding a release, consider that too, but check what it does to people who already installed it.
Step 4: Communicate facts
Draft the customer notice from confirmed facts: which versions are affected, what the issue is, what to do, and where to get the fixed release. Keep guesses out. Update the notice as facts change, with dates. Have counsel and your accountable executive review before it goes out, since notice duties depend on your contracts and jurisdictions.
Step 5: Prepare for the long tail
Plan for customers who stay on old versions: a support macro, a documented upgrade path, and a note on how you will measure uptake. Revisit after a set period and decide whether additional outreach is justified.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how an inventory ties a package and version to the projects that contain it.
Quick check
Can we recall a release customers already installed?
Generally no. You can ship a fix, stop distributing the bad build where a channel allows it, and communicate clearly.
What do we need to scope this fast?
A stored inventory for each release. Without one, you must inspect shipped artifacts one by one.
Safeguard can help with the inventory side of this work. SBOM and dependency scanning show where a package and version appear across your projects, and policies and gates can stop a flagged version at the pull request. You can try a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
