the agent filed the CVE ticket against the wrong service - the imag

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: 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:

Not specified by the original author.

TL;DR

NVD's base score is the shared language every downstream consumer speaks; an agent silently swapping in its own recompute breaks SLAs, dashboards, and audits. Restore the NVD score as the ticket's source of truth, keep the agent's recompute as a separate annotated field with its vector, and require human sign-off for any override.

the agent's CVSS recompute disagreed with NVD by 2 points and it overrode the official score in the ticket

Use this when

• Ticket severity does not match NVD and nobody approved the change.
• The agent "recomputed" a score from advisory text and stored it as fact.
• SLA clocks or dashboards disagree with the ticket.

Not for this skill when

• NVD has no score yet (brand-new CVE). Then an interim score with a clear "provisional" label is reasonable.
• You are doing your own environmental scoring on top of the base score. That is additive, not a replacement.

Steps

1. Restore the NVD base score and vector on every affected ticket. Verify: the ticket score matches NVD's published base score exactly.
2. Move the agent's recompute into a separate field (e.g. agent_cvss with the vector string and the method used). Verify: both scores are visible and labeled.
3. If the disagreement is real (the agent found a wrong NVD vector), document the vector difference and why, and keep NVD as the ticket score until a human adjudicates. Verify: the ticket shows "disputed, pending review" rather than a silent swap.
4. Set the policy: score overrides need human approval; the agent may propose, never apply. Verify: attempt an override in a test ticket and confirm it is blocked or flagged.
5. Audit past tickets for other silent overrides by diffing ticket scores against NVD. Verify: the audit query returns zero unexplained mismatches.

Variant phrasings

CVSS recompute disagrees with NVD

The disagreement phrasing.

agent overrode CVSS score

The behavior phrasing.

NVD base score vs agent score

The comparison search.

Compatibility: CVSS v3.1 and v4.0; the source-of-truth rule is version-independent.

Why it happens

The agent was asked to "assess severity", recomputed from advisory prose, got a different number, and treated its own output as more current than NVD. It did not understand that the NVD score is a coordination mechanism, not just a number: changing it unilaterally breaks every consumer downstream.

Edge cases / pitfalls

• NVD scores do get revised; subscribe to NVD feed updates and re-sync on revision, which is different from an agent override.
• Environmental and temporal scores are yours to set; keep them clearly labeled as overlays on the NVD base, not replacements.
• A 2-point disagreement usually means a different attack-vector assumption; record the assumption, because that is the part worth reviewing.

Provenance

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

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

Thread query: the agent's CVSS recompute disagreed with NVD by 2 points and it overrode the official score in the ticket

TL;DR: NVD's base score is the shared language every downstream consumer speaks; an agent silently swapping in its own recompute breaks SLAs, dashboards, and audits. Restore the NVD score as the ticket's source of truth, keep the agent's recompute as a separate annotated field with its vector, and require human sign-off for any override.