A poisoned base image tabletop asks whether you can list every image built from a given parent, decide what to rebuild first, and show that the rebuilt versions are clean. This script runs 60 minutes with four injects and a fictional image called acme/runtime-slim.
Why this scenario differs
A bad base image spreads quietly. Every service that inherits it carries the problem, and rebuilding one application does nothing if its Dockerfile still points at a mutable tag. The exercise exposes whether you know the parentage of what you run, and whether your registry and runtime tell the same story.
Setup
- Facilitator, scribe, platform engineer, two service owners, security lead.
- A fictional
FROM acme/runtime-slim:3tag shared by many services.
Injects
Inject 1, minute 5. A maintainer notice says a tag was repointed to a different image digest three days ago and the new layers contain an unexpected binary.
Ask:
- How do you list every image and deployment built from this parent?
- Do your Dockerfiles use tags or digests?
- Do you keep build metadata that records the parent digest?
Inject 2, minute 18. Your search finds 31 images in the registry, 12 running in production, 3 on customer premises.
Ask:
- Which do you rebuild first and why?
- What does the unexpected binary need in order to do harm: network, secrets, privileges?
- Can you tell running images from stored images?
Inject 3, minute 33. One service's container has outbound traffic to an unfamiliar address.
Ask:
- Do you isolate the container, kill it or watch it? Who approves?
- What evidence do you keep before you remove it?
- Which secrets were mounted in that workload?
Inject 4, minute 48. A rebuilt image is ready.
Ask:
- How do you prove it no longer contains the bad layer?
- Do you pin the parent by digest this time? Who updates the pin?
- How do you stop old images being redeployed from the registry?
Decision guide: what to rebuild first
| Priority | Criteria |
|---|---|
| 1 | Running in production with access to secrets or sensitive data |
| 2 | Internet facing but low privilege |
| 3 | Running internally with narrow scope |
| 4 | Stored but not deployed (delete or retag) |
| 5 | Shipped to customers, which needs a communication plan |
Discussion points
- Tags move; digests do not. Pinning to a digest makes a repointed tag harmless to builds that already use the digest, but you must update deliberately.
- An approved base image list reduces how many parents you track. See running an approved base image catalog.
- Keep a rebuild runbook: who triggers, how long it takes, what gets tested.
Debrief
Finish with the three fixes you will make this month and put them into an after-action report. If you want to rehearse the scan side before the tabletop, try the demo below.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are grouped by layer, then ask how you would trace a bad layer back to its parent.
Safeguard offers container image scanning, SBOM generation and policy gates for builds. A free scan is a quick way to see what is inside an image.
Quick check
Does pinning a base image by digest solve this?
It stops silent changes to a tag from reaching your builds, but a digest you pinned after the compromise could still be bad. You also need a process to review and update pins.
Should we delete the stored images?
Preserve what you need as evidence first, then remove or quarantine them so they cannot be redeployed.
Last reviewed: 19 October 2026.
