Build a table of every artifact that included the bad dependency: container images, packages, installers and releases. For each, record the version, where it is deployed or downloadable, and how and when it was replaced. This is the recall list, and it is the part of a postmortem most often left vague.
Why artifacts matter more than repositories
Removing a bad version from a lockfile fixes the next build. It does nothing for images already running, packages already published, or installers already downloaded. A supply chain postmortem has to cover what is still out there.
Your build records are the evidence. Each artifact should be traceable to the inputs that produced it. SLSA's provenance format describes this idea: the build records resolved dependencies, such as the specific commit a repository reference resolved to, alongside the artifacts it produced. Even if you do not use that format, keep the same pairing of inputs and outputs.
The recall table
| Artifact | Built on | Contained bad version | Where it lives | Replaced by | Replaced on |
|---|---|---|---|---|---|
| Service image, tag X | Date | Yes | Production cluster A | Rebuilt image | Date |
| Internal CLI v2.4 | Date | Yes | Internal download page | v2.4.1 | Date |
| Public package v1.8 | Date | No, verified | Registry | Not needed | n/a |
Add a column for "evidence" if the verified "No" rows need backing. A "No" without evidence is the same as "unknown".
Steps to fill it in
- List builds in the exposure window. Use CI history from the first possible install to the block time.
- Find the output of each build. Image digests, package versions, release tags.
- Check the dependency inside each output. Read the stored inventory, or inspect the artifact itself. Do not rely on the source branch alone.
- Find where each affected artifact is running or published. Clusters, registries, download pages, app stores.
- Replace and record. Rebuild from clean inputs, redeploy, and note the new digest.
- Retire the old artifact. Remove or deprecate it so it cannot be pulled again.
Things that get missed
- Cached layers. A rebuild that reuses a cached layer can carry the bad dependency forward. Rebuild without the cache for affected images.
- Mirrors and proxies. An internal mirror may still serve the removed version.
- Long lived environments. Staging, demo and customer facing sandboxes often run older builds.
- Downstream consumers. If you publish packages or images others use, they may need a notice. Plan that with your communications owner.
- Developer machines. Locally built tools are artifacts too.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how the findings are tied to a specific image, not a repository.
Where Safeguard fits
Safeguard's SBOM and dependency scanning records the components in each build, so the "contained bad version" column can be read from stored data rather than rebuilt by hand. The free scan shows the idea on one repository.
Quick check
Is fixing the lockfile enough?
No. It only protects future builds. Images and packages already built, deployed or published need to be found and replaced.
How do we know a rebuilt image is clean?
Check its inventory for the bad version, and rebuild without cached layers so nothing carried over.
Sources
Last reviewed: 19 October 2026.
