## TL;DR
You cannot patch someone else's image, but you can replace it: check whether the vulnerable package is even used at runtime, upgrade to the publisher's fixed tag if one exists, rebuild on a minimal base if it does not, and pin plus scan everything going forward. Waiting on the publisher with no plan is how a medium becomes an incident.

## The query
```text
how to handle a CVE in a base image you don't maintain
```

## Use this when
- The image scanner flags a CVE in a base image layer, not your code
- The publisher has not released a fixed tag yet
- You need to decide whether to rebuild, switch bases, or accept the risk
- Leadership asks why the scan is red on something you did not write

## Not for
- CVEs in your application dependencies (different owner, different fix)
- General container hardening guides
- Kubernetes control-plane security

## Steps

1. Identify exactly what is vulnerable and where: the package name and version, the image layer, and whether the flagged CVE is in the OS packages, the language runtime, or something bundled. Scanner output usually tells you; verify against the image's package list.
   Expected output: package, version, and layer named, not just a CVE number.

2. Assess reachability and exposure: does your container ever execute that package, is the vulnerable function reachable, and is the container internet-facing? An unused setuid binary with a local-only CVE on an internal job is a different priority from a network-reachable OpenSSL.
   Expected output: a reachability verdict that justifies the priority you assign.

3. Check for a fixed upstream tag first: publishers often patch within days. If a fixed tag exists, bump your Dockerfile, rebuild, rescan, and ship. This is the happy path; take it when offered.
   Expected output: rebuilt image, clean rescan, deployed.

4. If no fixed tag exists, rebuild the layer yourself or move: install the patched package version in your own Dockerfile layer on top of the base, or switch to a minimal base (distroless or slim variant) that does not include the vulnerable package at all. Prefer the minimal base; fewer packages, fewer future CVEs.
   Expected output: an image that scans clean, built from layers you control.

5. Pin your base images by digest, not just tag, and scan on every build plus on a schedule. Tags move; digests do not. Scheduled rescans catch newly disclosed CVEs in old images.
   Expected output: Dockerfiles reference digests; CI fails the build on new criticals.

6. Pressure the publisher in parallel: file the issue, watch their advisory feed, and set a date to revisit. If they stay slow, that is data for your next base-image choice.
   Expected output: a tracked upstream issue with a revisit date, not a forgotten hope.

## Variant phrasings
### "scanner flags CVE in docker base image"
Steps 1 and 2 first: most teams panic at the scanner line and skip the reachability check that would right-size the response.
### "base image publisher slow to patch"
Steps 4 and 6: rebuild the layer yourself now, track the publisher separately. Do not let their timeline become your exposure window.
### "distroless vs slim base image security"
Both shrink the attack surface; distroless goes further by dropping the shell and package manager. Either beats a full OS base for most services.

## Why this happens
Base images bundle an OS userland you did not choose, and every package in it is a CVE waiting for disclosure. Teams inherit this debt silently because the Dockerfile looked like one line. The scanner makes the debt visible; this skill is the repayment plan.

## Edge cases and pitfalls
- Rebuilding a layer on top of a vulnerable base leaves the vulnerable files in an earlier layer; scanners may still flag them. Prefer a clean minimal base when you can.
- Language runtimes in base images (a bundled Python, Node, or Go) need the same treatment as OS packages.
- Pinning by digest without a renovate-style updater means you freeze forever; pair pinning with automated update PRs.
- Accepting the risk is legitimate for truly unreachable findings, but write it down with a review date.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7doYf2eHUnEy4tQj-q13Aw