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

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