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

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.

CVE backporting: when the fix isn't in your version

TL;DR

First verify the fix is actually missing from your version, not just undocumented. Then pick the cheapest safe path in order: upgrade to a fixed release, cherry-pick the upstream commit, take a vendor backport, or mitigate without the patch. Staying on an unfixed version with no mitigation is the one option that is never fine.

CVE backporting: when the fix isn't in your version

Use this when

• A CVE fix exists upstream but your pinned version predates it
• You maintain or depend on an LTS or stable branch that lags upstream
• A vendor advisory lists fixed versions and yours is not among them
• You are deciding whether a cherry-pick is safe or an upgrade is required

Not for this skill when

• The fix is already in your version (just upgrade to the patched release)
• There is no fix anywhere yet (that is the no-patch-available playbook)
• You are planning a general version upgrade with no CVE driving it

Steps

1. Verify the fix is really missing

Find the upstream fix commit and check whether your version contains it or an equivalent. Advisories sometimes understate backport coverage.

git log --oneline --grep="[fix-keyword]" [your-branch]

Expected: either the fix commit (or its backport) in your history, which ends the exercise, or its confirmed absence. Also check the vendor's security tracker; distro and vendor backports do not always appear in upstream git history.

2. Prefer upgrading to a fixed release

If a fixed release exists on your line, upgrade to it. It carries the maintainer's testing, not just yours.

Expected: the patched version installed and the reproduction from the advisory no longer triggering. This is the default answer; only move past it with a reason.

3. Cherry-pick when you cannot upgrade

If upgrading is blocked, cherry-pick the upstream fix commit onto your branch. Review the commit first: security fixes sometimes depend on earlier refactors that your branch lacks.

Expected: a clean cherry-pick with tests passing. If it conflicts heavily, that is signal: the fix does not apply cleanly to your version, and a partial backport can be worse than none.

4. Ask the vendor or distro for a backport

For commercial or distro-packaged software, the backport may already exist as a vendor patch even if upstream never cut a release on your line. Check their security portal before doing the work yourself.

Expected: a vendor patch or a clear statement of support status. If the version is end-of-life, the answer will be "upgrade," and you should treat that as a migration project, not a patch task.

5. Mitigate when no patch path exists

Block the vulnerable code path with configuration, network controls, or a wrapper until you can move versions. Document it as temporary with an owner and a date.

Expected: the reproduction blocked by the mitigation, verified by test. A mitigation is a bridge, not a destination; put the version move on the roadmap with a deadline.

Variant: backporting across a big version gap

The wider the gap, the more likely the fix depends on other changes. Budget real review time, run the upstream security tests if they exist, and prefer the upgrade path; heroics on ancient branches usually cost more than the migration.

Variant: vendored code with no upstream

When the code was copied, not depended on, there is no release to upgrade to. Port the fix by hand into the vendored copy and add a comment noting the source commit, so the next person knows where it came from.

Why this happens

Maintainers fix the current release line first and backport when they have capacity, which means older versions sit exposed for a while or forever. Pinning to an old version trades upgrade pain for exactly this situation, so the backport decision is the bill coming due on that trade.

Edge cases and pitfalls

• Partial backports: applying half a fix can change the bug's shape without closing it; verify with the actual reproduction.
• Fix dependencies: the security commit may rely on an earlier refactor; read the full commit, not just the diff hunk.
• Silent backports: vendors sometimes patch without a new version number; verify by testing, not by reading changelogs alone.
• EOL versions: no backport is coming, plan the migration instead of hoping.
• Cherry-pick without tests: if the fix has no test coverage on your branch, add a regression test with the backport.

Provenance

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

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

Thread query: CVE backporting: when the fix isn't in your version

TL;DR: First verify the fix is actually missing from your version, not just undocumented. Then pick the cheapest safe path in order: upgrade to a fixed release, cherry-pick the upstream commit, take a vendor backport, or mitigate without the patch. Staying on an unfixed version with no mitigation is the one option that is never fine.

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.