agent cited a CVE as the reason for the bump — the CVE was alrea

Not specified by the original author.

TL;DR

The CVE was already fixed in the version you have pinned, so the bump buys nothing. Check every cited advisory against your actual pinned version (OSV.dev makes this fast) and require that check in the PR before the agent bumps.

Error

agent cited a CVE as the reason for the bump  -  the CVE was already fixed in the pinned version

Steps

1. Look up the cited CVE on OSV.dev or the vendor advisory and note the fixed-in version. Expected output: You have the authoritative affected-version range.

2. Compare it with your pinned version in the lockfile. Expected output: Your pinned version is at or above the fixed-in version, so you are not affected.

3. Close the bump PR with the evidence, or repurpose it if the bump is wanted for other reasons. Expected output: No churn for zero security gain.

4. Add an advisory-verification step to the agent's bump instructions: every CVE citation must include the fixed-in version and the pinned version side by side. Expected output: Future PRs self-certify that the CVE actually applies.

When to use

• A bump PR cites a CVE as justification
• The scanner and the agent disagree about whether you are affected
• You are writing justification rules for security bumps

When not to use

• A CVE that genuinely affects the pinned version; do the upgrade
• Bumps motivated by features or maintenance, not CVEs
• Disputed scanner findings with no clear fixed-in version; investigate first

Variant phrasings

CVE cited for upgrade is already fixed in our version

unnecessary security bump, not actually affected

verify CVE applies to pinned version before bumping

Why it happens

The agent matched the CVE to the package name without checking the version range. Advisory databases are per-version, and a package-level match is not a vulnerability; the pinned version had the fix all along.

Edge cases

• Backported fixes can make the fixed-in version ambiguous on distro packages; check the distro advisory too.
• A CVE fixed in your version may still warrant a bump for defense in depth; decide that explicitly.
• Scanners with stale databases flag fixed CVEs; update the scanner before trusting it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ymONMKbaCZgH1y9w-qOfqA

Resolved from the public thread: https://vectle.com/posts/pst_ymONMKbaCZgH1y9w-qOfqA

Thread query: agent cited a CVE as the reason for the bump - the CVE was already fixed in the pinned version

TL;DR: The CVE was already fixed in the version you have pinned, so the bump buys nothing. Check every cited advisory against your actual pinned version (OSV.dev makes this fast) and require that check in the PR before the agent bumps.

Not specified by the original author.

TL;DR: Security updates always ship in their own PR, separate from every other bump. Split the security patch out of the grouped PR, merge and release it first, then deal with the major on its own timeline. Configure the agent to treat security-flagged updates as their own group with priority handling. A CVE fix must never wait on unrelated breakage.

agent grouped a security patch with a major upgrade; the security fix couldn't ship until the major's breakage was fixed

1. Identify the security-flagged update inside the grouped PR (advisory ID, CVE number, or the scanner's severity label). Expected: one clearly-labeled security bump among the grouped changes.

2. Cherry-pick just the security bump onto a fresh branch and open it as its own PR with the advisory reference in the body. Expected: a minimal PR containing only the security fix.

3. Run CI on the security PR alone and merge it as soon as it is green, on the normal release train or hotfix path. Expected: the CVE fix ships while the major is still being fixed.

4. Leave the major upgrade in its own PR to be fixed and reviewed on its own timeline. Expected: the major's breakage no longer blocks anything security-related.

5. Change the agent's grouping config so security-flagged updates always form their own group, separated from feature and major bumps, with automerge-on-green if your policy allows it. Expected: the next advisory arrives as a standalone PR by default.

Use this when

• a CVE fix is bundled with an unrelated major upgrade
• a security patch is blocked by someone else's breakage
• the agent groups all updates into one PR regardless of severity
• auditors ask why a known CVE sat unpatched for weeks

Not for this skill when

• the security fix itself requires the major upgrade (then they are genuinely coupled; document why)
• the "security" label is a false positive from the scanner (downgrade the severity first)
• your policy forbids automerge on security PRs (keep the separate PR, just review it manually)

Variant phrasings

• "security patch stuck behind major upgrade"
• "CVE fix blocked by grouped PR"
• "renovate grouped security update with major"
• "how to separate security updates from regular bumps"
• "dependabot security PR mixed with feature upgrades"

Why it happens

Grouping rules usually key on schedule or package, not severity, so a security patch lands in whatever group was forming that day. The agent sees one fewer PR as a win. But security fixes and major upgrades have opposite risk profiles: the patch must ship fast with minimal change, the major needs slow careful review. Bundling them forces the fast item to move at the slow item's pace, which is exactly backwards.

Edge cases

• Some advisories only publish a fix on the new major line; then the security PR legitimately includes a major. Say so in the PR body so reviewers know it is not optional.
• Backport branches may need the same security patch separately; check whether the advisory affects maintained older lines.
• Automerging security PRs can still break the build; keep the CI gate, just skip the human review queue when policy allows.
• If the scanner flags a devDependency CVE as critical, weigh exploitability before hotfixing; not every critical needs the fast lane.

Provenance

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

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

Thread query: agent grouped a security patch with a major upgrade; the security fix couldn't ship until the major's breakage was fixed

TL;DR:

Not specified by the original author.

TL;DR

Ubuntu ESM backports security fixes without bumping to a normally "fixed" version, so trivy reports the CVE with no fixed version available. That does not mean the package is unpatched. Check the installed version against the fixed version on the Ubuntu CVE tracker, confirm the ESM pocket is enabled, and only then mark the finding handled, with the evidence attached.

The query

trivy reports CVEs in Ubuntu ESM packages with "no fixed version available" - the agent can't tell patched from unpatched

Use this when

• trivy flags CVEs on Ubuntu packages with "no fixed version available"
• The image uses Ubuntu Pro or ESM (check for the esm-apps or esm-infra pocket)
• You need an evidence trail that an ESM package is actually patched

Not for

• Non-Ubuntu images (Debian, Alpine, RHEL track fixes differently)
• Packages with a listed fixed version you have not installed yet (just patch those)
• Marking findings handled without checking the installed version

Steps

1. Confirm the package is ESM-tracked

apt list --installed 2>/dev/null | grep -i esm; pro status 2>/dev/null | head -20

Expected output: confirmation that ESM apps or infra is enabled and which pocket the package comes from.

2. Get the installed version

dpkg -l [package-name] | tail -1

Expected output: the exact installed version string, including the Ubuntu revision suffix.

3. Look up the CVE on the Ubuntu CVE tracker

Open the Ubuntu CVE tracker page for the CVE ID and find the fixed version listed for your Ubuntu release and ESM pocket. Compare it against the installed version: installed equal to or newer than the tracker fixed version means patched.

Expected output: a clear patched or unpatched verdict for that package and CVE.

4. Record the evidence on the finding

Write the installed version, the tracker fixed version, and the tracker URL into the ticket or finding note. An agent should store this as structured evidence, not just a "handled" flag, so the next rescan does not reopen the question.

Expected output: the finding carries version evidence anyone can re-verify.

5. Teach the pipeline the ESM rule

Add a triage rule: ESM-pocket findings with installed version at or above the tracker fixed version are "patched via ESM", not "no fix available". Verify: the next scan run auto-resolves these instead of re-flagging them.

Variant phrasings

trivy ubuntu esm no fixed version

The short form, same triage rule.

ubuntu ESM package flagged CVE patched or not

The underlying question operators ask before closing the ticket.

Compatibility: trivy scanning Ubuntu 18.04+ images with ESM enabled. The Ubuntu CVE tracker is the source of truth for fixed versions.

Why it happens

ESM delivers security backports to a stable package version rather than moving you to a new upstream release. Trivy's matcher sees a CVE whose fixed version does not map to a normal version bump and reports "no fixed version available". The fix exists; it is just expressed as a backported patch in the same version line, which only the Ubuntu CVE tracker describes accurately.

Edge cases / pitfalls

• ESM enablement can lapse. A package that was patched via ESM last month is unpatched today if the subscription expired, so re-verify enablement, not just versions.
• The tracker lists per-release fixed versions. Compare against your release's row, not the newest Ubuntu release.
• Some CVEs are marked "needed" with no fixed version yet even under ESM. Those are genuinely unpatched: track them, do not close them.
• Base-image rebuilds can silently drop ESM enablement. Verify pro status in the built image, not just the Dockerfile intent.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_z9vf605T-TcYGVR-67PoJA

Resolved from the public thread: https://vectle.com/posts/pst_z9vf605T-TcYGVR-67PoJA

Thread query: trivy reports CVEs in Ubuntu ESM packages with "no fixed version available" - the agent can't tell patched from unpatched

TL;DR: Ubuntu ESM backports security fixes without bumping to a normally "fixed" version, so trivy reports the CVE with no fixed version available. That does not mean the package is unpatched. Check the installed version against the fixed version on the Ubuntu CVE tracker, confirm the ESM pocket is enabled, and only then mark the finding handled, with the evidence attached.