agent's remediation advice referenced the wrong CVE for a finding

Not specified by the original author.

TL;DR

Remediation text is usually fetched or generated from the CVE identifier, so a wrong identifier, a lookalike CVE from a related component, or advice carried from a neighbouring finding sends the client patching the wrong thing. Bind the advice lookup to the finding's stored CVE id, render the CVE summary beside the advice for a sanity check, and gate the report on every advice block naming the same CVE as its finding.

agent's remediation advice referenced the wrong CVE for a finding

Use this when

• A finding's remediation paragraph names a product, version, or CVE that differs from the finding's own header.
• The advice is oddly specific about software the affected host does not run.

Not for this skill when

• The finding legitimately covers two CVEs for one weakness and its advice addresses both, with both named in the finding. That is complete, not wrong.
• The advice is vendor guidance that supersedes the CVE, for example a newer advisory. It should cite that advisory explicitly.

Steps

1. For the affected finding, write down three values: the CVE in the finding header, the CVE the advice addresses, and the affected product and version from the evidence. Verify: Verify: the mismatch is pinned to specific values, not a feeling.
2. Trace where the advice came from: a lookup keyed by CVE, a template, or generated prose, and find how the wrong identifier entered, such as a fuzzy title match or an off-by-one row in a data file. Verify: Verify: the entry point of the wrong CVE is identified in the pipeline.
3. Fetch the correct advice for the finding's own CVE from the authoritative advisory source, and replace the block, keeping the source reference with it. Verify: Verify: the advice, its CVE, and the affected product now agree, checked against the advisory.
4. Add the binding in the builder: advice is retrieved using only the finding's stored CVE field, and free-text advice must cite the advisory it follows. Verify: Verify: a test finding cannot render advice fetched for a different CVE.
5. Sweep the rest of the report with the same three-value check, since a systematic lookup bug rarely strikes once, and correct any delivered draft in writing. Verify: Verify: every finding in the report passes the CVE agreement check.

Variant phrasings

remediation advice wrong cve finding mismatch

The symptom phrasing.

bind remediation lookup to finding cve id gate

The binding phrasing.

agent advice copied neighbouring finding patch wrong product

The carryover phrasing.

Compatibility: Compatibility: any agent reporting pipeline that attaches CVE remediation; authoritative sources are the vendor advisory and the national vulnerability database entry for the CVE.

Why it happens

A finding and its advice travel through different paths: the finding comes from scanner evidence, the advice from a knowledge lookup. If the lookup key is a fuzzy title rather than the exact identifier, near neighbours win, especially in families of CVEs for one product. The prose reads fluently, so the error survives skim review, and the client acts on confident, wrong instructions.

Edge cases / pitfalls

• Some findings have no CVE at all, such as configuration issues; their advice must come from the configuration guidance, and the builder should not force a CVE lookup for them.
• Check version applicability in the advice: a correct CVE with advice for the wrong branch still misleads.
• If the wrong advice was followed by the client, the correction is urgent and should say plainly what to undo and what to do instead.

Provenance

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

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

Thread query: agent's remediation advice referenced the wrong CVE for a finding

TL;DR: Remediation text is usually fetched or generated from the CVE identifier, so a wrong identifier, a lookalike CVE from a related component, or advice carried from a neighbouring finding sends the client patching the wrong thing. Bind the advice lookup to the finding's stored CVE id, render the CVE summary beside the advice for a sanity check, and gate the report on every advice block naming the same CVE as its finding.

Not specified by the original author.

TL;DR

The scanner flagged a production dependency and the agent bumped the devDependency with a similar name. The finding is still there because the vulnerable code path never changed. Revert the wrong bump, make the agent read the scanner's package path before editing any manifest, and require the security PR to clear the flagged finding on rescan before it can merge.

the agent's remediation PR bumped the devDependency instead of the prod dependency - the scanner still flagged it

Use this when

• A "fix" merged but the rescan still flags the same CVE.
• The PR diff shows a devDependency change for a finding reported against dependencies.
• Package names are similar across scopes and the agent picked the wrong one.

Not for this skill when

• The finding is genuinely in a devDependency (some scanners flag those). Then the bump was right and the rescan config is the problem.
• The version bump failed to resolve. That is a dependency-resolution problem.

Steps

1. Revert the devDependency bump; it was unrelated to the finding. Verify: the diff is clean and unrelated tests still pass.
2. Read the scanner output for the exact package path: which manifest, which section, which version is installed. Verify: you can point to the line in package.json (or equivalent) the scanner means.
3. Bump the correct entry to the fixed version. Verify: the lockfile shows the production dependency at the fixed version.
4. Rescan and confirm the finding is gone. Verify: the specific CVE no longer appears for that package path.
5. Add the gate: a security PR must reference the finding ID and CI must show that finding cleared on rescan before merge. Verify: a PR that bumps the wrong scope fails the gate.

Variant phrasings

bumped devDependency instead of dependency

The short phrasing.

npm audit fix wrong dependency

The tool-specific search.

fix PR wrong scope scanner still flags

The symptom phrasing.

Compatibility: npm, pip, cargo, Go modules; every ecosystem has scope concepts (dev vs prod) that agents confuse.

Why it happens

The agent matched on package name, not on the scanner's package path. Similar names across scopes (foo in dependencies vs foo in devDependencies, or a similarly named transitive dep) made the name match ambiguous, and the agent edited the first match instead of the exact one the scanner reported.

Edge cases / pitfalls

• Monorepos multiply this: the same package name can appear in several workspace manifests. The scanner's file path is the disambiguator; always use it.
• If the vulnerable package is transitive, bumping the direct devDependency does nothing; the fix is overriding or bumping the direct dependency that pulls it in.
• Some findings need the lockfile regenerated, not just the manifest edited; verify the installed version, not just the declared range.

Provenance

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

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

Thread query: the agent's remediation PR bumped the devDependency instead of the prod dependency - the scanner still flagged it

TL;DR: The scanner flagged a production dependency and the agent bumped the devDependency with a similar name. The finding is still there because the vulnerable code path never changed. Revert the wrong bump, make the agent read the scanner's package path before editing any manifest, and require the security PR to clear the flagged finding on rescan before it can merge.

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.