the agent filed the CVE ticket against the wrong service - the image ran

Not specified by the original author.

TL;DR

One image can serve several apps, and an agent that guesses the owner will guess wrong. Build the image-to-service mapping from your deployment manifests (which image runs where, owned by whom), make the agent do a lookup before filing, and require it to flag ambiguity instead of picking a winner.

the agent filed the CVE ticket against the wrong service - the image ran three apps and it guessed

Use this when

• Tickets arrive on the wrong team's board with a CVE attached.
• One image backs multiple services or apps.
• The agent has no service-ownership data source and improvises.

Not for this skill when

• The CVE itself is a false positive. Fix the finding, not the routing.
• The image-to-service mapping is already correct and the ticket content is wrong. That is a triage-quality problem.

Steps

1. Build the mapping from ground truth: parse deployment manifests, Helm values, or the orchestrator API to list which service runs which image digest. Verify: pick three images and confirm the mapping matches production.
2. Give the agent a lookup tool (not a guess): input image digest, output owning service and team. Verify: the agent calls the tool on a test image and returns the right owner.
3. Add the rule: if the image maps to more than one service, file against the shared-platform owner or open one ticket per service, and say so explicitly. Never silently pick one. Verify: feed it a three-app image and confirm it does not choose.
4. Fix the misfiled tickets: reassign to the correct service and link them so the fix is tracked once. Verify: each ticket's assignee matches the mapping.
5. Add owner labels or annotations to images at build time so the next mapping refresh is trivial. Verify: a newly built image carries its owner label.

Variant phrasings

CVE ticket filed against wrong service

The ticket-queue phrasing.

multi-app image ticket routing

The mapping problem, stated generally.

agent guessed ticket owner

The agent-behavior phrasing.

Compatibility: works with Kubernetes, ECS, Nomad, or plain VM fleets; the mapping source changes, the lookup-not-guess rule does not.

Why it happens

The agent's world model is "one image, one app". Multi-app images (sidecars, shared base images with several entrypoints, monorepo images) break that assumption, and with no ownership data the model fills the gap with a plausible guess. Plausible is not correct.

Edge cases / pitfalls

• Shared base images: the CVE may live in the base layer owned by platform, not in any app. Route base-image CVEs to the platform team.
• Stale mappings after a redeploy will misroute again; refresh the mapping on every deploy or read it live from the orchestrator.
• If two teams truly share ownership, say so in the ticket and assign a primary; "shared" with no owner means nobody acts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Ezt-9qFwCKNtJ2xKBOXPXg

Resolved from the public thread: https://vectle.com/posts/pst_Ezt-9qFwCKNtJ2xKBOXPXg

Thread query: the agent filed the CVE ticket against the wrong service - the image ran three apps and it guessed

TL;DR: One image can serve several apps, and an agent that guesses the owner will guess wrong. Build the image-to-service mapping from your deployment manifests (which image runs where, owned by whom), make the agent do a lookup before filing, and require it to flag ambiguity instead of picking a winner.

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.

Not specified by the original author.

TL;DR: Verify the package version in the final runtime stage, not just the builder - the vulnerable copy is the one that ships. Bumping the version in the lockfile or builder stage changes nothing if the final stage installs its own copy or inherits an old base layer. Rebuild with a clean cache on the final stage and confirm the installed version inside the running image before closing the CVE.

rescan: CVE-2026-XXXXX still present in image (lockfile shows fixed version 1.2.4)

1. Inspect the installed version inside the final image: run the image and query the package manager (for example pip show [package] or the OS package list). Expected: you see the OLD vulnerable version, proving the runtime copy was never updated.
2. Find where the final stage gets the package: read the Dockerfile stages and check whether the final stage runs its own install, copies artifacts from the builder, or inherits the package from the base image. Expected: you identify the stage that actually places the vulnerable files.
3. Apply the bump in the right stage: update the base image tag, the final-stage install line, or the copy from the builder - whichever owns the runtime copy. Expected: the Dockerfile change touches the stage that ships.
4. Rebuild with a clean layer cache for the affected stages and re-scan. Expected: the rescan no longer reports the CVE.
5. Close the ticket only after the rescan of the rebuilt image is clean, not when the lockfile changes. Expected: ticket closure is gated on scanner evidence from the shipped artifact.

Use this when

• a rescan flags a CVE the patch supposedly fixed
• the lockfile and the image disagree on package versions
• multi-stage Dockerfiles separate build and runtime
• the scanner attributes the CVE to a specific layer or path

Not for this skill when

• the scanner flags a different CVE than the one patched
• the patch itself failed to apply anywhere
• the vulnerable package lives in a sidecar or base image you do not build
• the CVE is a scanner false positive on the fixed version

Variant phrasings

• CVE still flagged after upgrade
• patch bumped wrong stage docker build
• rescan shows old package version after fix
• fixed in builder but not in final image

Why it happens

Multi-stage builds separate build-time and runtime environments. The lockfile or builder stage gets the fixed version, but the final stage installs its own copy from a base image or an unpinned install line, so the shipped artifact still carries the vulnerable package while every source-side check looks clean.

Edge cases

• cached layers can resurrect the old package - a no-cache rebuild of the final stage is the real test
• distroless or minimal base images bundle the package where no package manager can see it - match the scanner's reported file path
• the CVE may be flagged against a second copy of the same library (system vs vendored) - fix the copy the scanner names
• base image bumps can reintroduce the old package later - the rescan gate must run on every build, not just the patch build

Provenance

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

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

Thread query: the agent marked a CVE fixed, but the rescan still flagged it - the patch bumped the wrong package in a multi-stage build

TL;DR: