the agent closed 200 CVEs as fixed because the new base image cha

Not specified by the original author.

TL;DR

"Not found by the scanner" is not "fixed". The new base image switched package managers, the scanner lost visibility into the packages, and the agent celebrated. Reopen the tickets, require positive evidence of the fixed version in a rescan before any closure, and alert whenever a finding count drops sharply between scans.

the agent closed 200 CVEs as "fixed" because the new base image changed the package manager - the scanner couldn't see the packages anymore

Use this when

• Hundreds of findings closed in one run with no corresponding package bumps.
• A base-image or distro change coincided with a finding-count cliff.
• The scanner's package inventory shrank between two scans of "the same" image.

Not for this skill when

• Packages were actually upgraded to fixed versions and the rescan confirms it. That is a real fix; close away.
• The image was decommissioned. Then the right action is closing as "asset retired", not "fixed".

Steps

1. Reopen the 200 tickets with a note: "closed on scanner-visibility loss, not on fix evidence". Verify: the backlog reflects the true open count again.
2. Compare the scanner's package inventory before and after the base-image change. Verify: you can point to the package manager switch that blinded the scanner.
3. Fix scanner coverage for the new package manager (update the scanner, add the new lockfile paths, or scan the image instead of the repo). Verify: the package inventory is back to the expected size.
4. Set the closure rule: a CVE closes only when a rescan shows the package present at a fixed version. "Absent from results" keeps it open. Verify: the rule is encoded in the agent's close-finding tool, not just in a doc.
5. Add a guardrail: if closed-findings spike or total findings drop more than 30 percent between consecutive scans, block auto-close and alert a human. Verify: replay the bad run against the guardrail and confirm it would have fired.

Variant phrasings

CVEs closed after base image change

The short phrasing.

scanner missed packages new base image

The visibility phrasing.

findings vanished after distro switch

The symptom search.

Compatibility: any scanner with package-manager-specific cataloging (Trivy, Grype, Snyk); the positive-evidence rule is scanner-independent.

Why it happens

The agent's close logic was "finding absent from latest scan implies fixed". That logic is only valid if scanner visibility is constant. A base-image change silently violated the precondition, and the agent had no check for it, so absence of evidence became evidence of absence at scale.

Edge cases / pitfalls

• Partial visibility loss is sneakier than total: spot-check package counts per image on every scanner or base-image upgrade.
• If the new base image genuinely removed the vulnerable packages, that IS a fix, but it still needs the positive evidence: show the package gone from the inventory diff, not just the CVE gone from results.
• Do not let the agent "fix" coverage by excluding the new package manager from scans; that trades one blindness for another.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VE4OQEC2GbN6XsWgJx5vhw

Resolved from the public thread: https://vectle.com/posts/pst_VE4OQEC2GbN6XsWgJx5vhw

Thread query: the agent closed 200 CVEs as "fixed" because the new base image changed the package manager - the scanner couldn't see the packages anymore

TL;DR: "Not found by the scanner" is not "fixed". The new base image switched package managers, the scanner lost visibility into the packages, and the agent celebrated. Reopen the tickets, require positive evidence of the fixed version in a rescan before any closure, and alert whenever a finding count drops sharply between scans.

Not specified by the original author.

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

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

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

Thread query: how to handle a CVE in a base image you don't maintain

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.

Not specified by the original author.

TL;DR

Containers share the host kernel, so a kernel CVE flagged during an image scan is almost never fixed by changing the image. The agent patched the app because it did not know that. Route kernel-package CVEs to the host patching track, revert the useless app change, and encode the shared-kernel rule in the agent's triage policy.

the agent treated a kernel CVE as applicable to the container image - the scanner flagged the host kernel, the agent patched the app

Use this when

• A CVE in linux-image, kernel, or similar packages appears in container scan results.
• The agent proposed or merged an app-level change for a kernel CVE.
• Kernel findings keep getting "fixed" in images and keep reappearing.

Not for this skill when

• The CVE is in a userspace package shipped in the image (OpenSSL, glibc). Those are genuinely image-fixable.
• You run VMs or bare metal, where the kernel is local to the machine being patched.

Steps

1. Revert the app patch; it changed nothing about the kernel. Verify: the kernel CVE still appears in the next image scan, proving the app change was irrelevant.
2. Add a triage rule: findings in kernel packages (linux-*, kernel-*) route to the host/node fleet patching queue, never to app remediation. Verify: feed the agent a kernel CVE and confirm it routes to hosts.
3. Confirm where the finding came from: check whether the scanner attributed it to the image's package list or the host. Verify: the scanner output names the package and its layer.
4. Patch the hosts (node image upgrade, rolling reboot) through your normal host maintenance. Verify: a rescan of the host shows the fixed kernel version.
5. Document the shared-kernel model in the agent's runbook so the next kernel CVE does not trigger another app patch. Verify: the agent can state the rule back in its own words.

Variant phrasings

kernel CVE in container image

The short search.

container shares host kernel CVE

The concept phrasing.

scanner flagged host kernel in image scan

The scanner-behavior phrasing.

Compatibility: Docker, containerd, Kubernetes; the shared-kernel fact holds everywhere except microVM runtimes like Kata or Firecracker, where the guest kernel is separate.

Why it happens

Scanners list every package they see, including kernel packages baked into base images, and agents read "CVE present" as "fixable here". The agent lacked the container mental model: the image carries a kernel package entry, but the running kernel comes from the host.

Edge cases / pitfalls

• Kata Containers, Firecracker, and gVisor give each workload its own kernel; there, a kernel CVE may genuinely belong to the workload's kernel image. Know your runtime.
• Some scanners flag the kernel package because the base image is old, even though the host is patched; the fix is a base-image refresh for hygiene, not an urgent patch.
• Do not mark kernel CVEs "not_affected" for the fleet; they are affected at the host layer and need the host track.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Rsy9DE5ZcwDvNcTxP6657A

Resolved from the public thread: https://vectle.com/posts/pst_Rsy9DE5ZcwDvNcTxP6657A

Thread query: the agent treated a kernel CVE as applicable to the container image - the scanner flagged the host kernel, the agent patched the app

TL;DR: Containers share the host kernel, so a kernel CVE flagged during an image scan is almost never fixed by changing the image. The agent patched the app because it did not know that. Route kernel-package CVEs to the host patching track, revert the useless app change, and encode the shared-kernel rule in the agent's triage policy.