Skip to main content
RunBook Academy

← All break/fix scenarios in Docker & Containers

advancedImage~25 min

Break/Fix 12: CVE drop — what to do when an image becomes vulnerable

Reported symptoms

  • Trivy / Grype / Docker Scout reports CRITICAL CVE in `myorg/base:1.4.x`.
  • Multiple downstream services share the vulnerable base.
  • No patched base image yet.

Evidence

  • · CI scan output: `libssl3 3.0.x: CVE-2026-XXXXX (CRITICAL)`.
  • · Image manifest: `FROM myorg/base:1.4.x`.
  • · No exploit traffic observed yet; the CVE is fresh.
Diagnosis and resolutionclick to reveal

Root cause

A CVE in a base image’s library propagates to every downstream service that inherits it. The fix is in the base image; the downstream services must rebuild.

Remediation

(1) Identify affected images via a registry-wide scan. (2) Assess whether the service actually exercises the vulnerable code path. (3) Patch the base image and rebuild downstream. (4) Scan the new images. (5) Deploy with a canary; observe. (6) Roll back if the new build is broken.

Verification

Re-scan after rebuild: no CRITICAL findings. Production metrics show no regression. Canary promoted to all replicas.

Prevention

Subscribe to base image CVE feeds (e.g. GitHub Security Advisories for the base repo). CI scans every image on every build. Quarterly review of base image freshness.

Step-by-step

  1. Identify affected images. Run Trivy against every image that inherits from the vulnerable base. Save the output.
  2. Assess impact. For each affected service, does the code path that uses the vulnerable library exist? A high CVSS in unused code is not the same as one in the request path.
  3. Patch the base. Bump the base image to a patched version (or rebuild the base locally if upstream is slow).
  4. Rebuild downstream. Rebuild every affected image against the new base. Sign the new images.
  5. Scan the rebuilds. Confirm no CRITICAL findings remain.
  6. Deploy canary. Roll out one replica first. Watch error rates, latency, health.
  7. Promote or roll back. If healthy, complete the rollout. If the rebuild broke a service, redeploy the previous image tag and document the issue.

What to record in the incident

  • The CVE ID and CVSS.
  • Which images were affected.
  • Which services exposed the vulnerable code path.
  • The patched base version.
  • Time to identify, time to patch, time to deploy.
  • Any postmortem action items.