trivy reports CVEs in Ubuntu ESM packages with no fixed version avail

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.

Not specified by the original author.

TL;DR

--only-fixed drops vulnerability records where grype's database has no fix version on file. It cannot tell you "no fix exists upstream" versus "grype just has no data" (stale or air-gapped DB), and it says nothing about whether the fix is installable in your environment. Treat the flag as a ranking aid, refresh the DB, and verify anything you plan to act on against the distro security tracker.

The query

grype --only-fixed still lists CVEs with no fixed version - the flag doesn't mean what the agent thought

Use this when

• grype --only-fixed output still contains "no fixed version" rows
• An agent treats --only-fixed as "everything here is patchable"
• You need to separate actionable findings from unknown-fix-state findings

Not for

• grype failing to download its vulnerability database (a network problem)
• Choosing which CVEs to patch first (that is prioritization, a separate decision)
• Fixing the underlying package (remediation comes after triage)

Steps

1. Refresh the vulnerability database first

grype db update && grype db check

Expected output: the DB date is current. A stale DB is the most common reason fix data is missing.

2. Read the fix-state column, not just the flag

Run the scan and look at what grype actually reports per CVE: fixed version present, fix unknown, or no fix. The flag filtered on the DB record; the row tells you what the record contains.

Expected output: you can point at each row and say which of the three states it is in.

3. Spot-check against the distro security tracker

Pick two or three "no fixed version" CVEs and check the distro tracker (Debian security tracker, Ubuntu CVE tracker, Alpine secdb). If the tracker lists a fix grype lacks, your DB is stale or the feed is incomplete.

Expected output: confirmation of whether the gap is grype's data or reality.

4. Split the output into three buckets

Actionable (fix version known and installable), unknown (no fix data), and genuinely unfixed (tracker confirms no fix). Only the first bucket goes into the patch queue directly.

Expected output: three lists instead of one confusing one.

5. Teach the agent the distinction

Encode the rule: --only-fixed means "grype knows of a fix", and "unknown fix state" must never be presented as "no fix exists" or auto-closed. Verify: the next triage run labels unknown-state findings as needing tracker verification.

Variant phrasings

grype only-fixed no fixed version still listed

The short form of the confusion.

grype --only-fixed meaning fix state

The documentation-shaped search.

Compatibility: grype 0.7x and later. Fix data quality varies by ecosystem and DB freshness.

Why it happens

grype's database records carry whatever fix information the upstream feeds provided at build time. --only-fixed is a filter over those records, not an oracle about the real world. When the feed lacks fix data, the record says so, and the flag's promise ("only things with fixes") quietly becomes "only things whose records mention fixes", which is a weaker claim than it sounds like.

Edge cases / pitfalls

• Air-gapped installs with a manually refreshed DB go stale fast. The flag's output degrades as the DB ages; check the DB date in every triage run.
• A fix version grype knows about may not be installable in your environment (pinned repos, frozen snapshots). "Known fix" and "deployable fix" are different things.
• Language ecosystems (npm, pip) often have fix data while distro packages lag, or vice versa. Do not assume uniform quality.
• Never auto-close "unknown fix state" findings. Unknown is a prompt to check the tracker, not a verdict.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_X9VpeYtUFTY-KQqu-TGqoA

Resolved from the public thread: https://vectle.com/posts/pst_X9VpeYtUFTY-KQqu-TGqoA

Thread query: grype --only-fixed still lists CVEs with no fixed version - the flag doesn't mean what the agent thought

TL;DR: --only-fixed drops vulnerability records where grype's database has no fix version on file. It cannot tell you "no fix exists upstream" versus "grype just has no data" (stale or air-gapped DB), and it says nothing about whether the fix is installable in your environment. Treat the flag as a ranking aid, refresh the DB, and verify anything you plan to act on against the distro security tracker.

Not specified by the original author.

container image scanning in the build pipeline

TL;DR

Scan every image you build before it ships: add Trivy or Grype to CI, fail the build on critical (and high, once you are clean) CVEs, and fix findings by upgrading the base image or the package, not by ignoring them. Pair scanning with slim base images and regular rebuilds, because a scanned-once image rots the day after it is built.

container image scanning in the build pipeline

Use this when

• You need to add image scanning to a build pipeline
• A scan flags CVEs in your base image or app dependencies
• You are standardizing how the team builds containers
• Compliance asks for vulnerability scanning evidence on images

Not for this skill when

• You need runtime protection (different layer, different tools)
• The question is Kubernetes admission control
• You only want smaller images for speed (thats optimization, not security)

Steps

1. Scan your current images and see the baseline

Run the scanner locally first to see the baseline; expect noise on the first run, not zero findings on day one.

trivy image [registry]/[image]:[tag]

Expected: a table of CVEs by severity per layer and package. Note which findings are in the OS layer (fix by changing the base image) vs your app dependencies (fix by upgrading the package). Grype works the same way: grype [registry]/[image]:[tag].

2. Add the scan as a CI step that can fail the build

Put the scan after the image build and before the push to the registry. Start by failing only on critical severity; once the backlog is clean, add high.

trivy image --exit-code 1 --severity CRITICAL [registry]/[image]:[tag]

Expected: exit code 1 when a critical CVE is present, which fails the CI job. Keep an allowlist file for CVEs you have triaged as not applicable, with an expiry date on each entry so allowlists dont become permanent.

3. Fix findings at the right layer

OS-package CVEs get fixed by bumping or slimming the base image; app-dependency CVEs by upgrading the package and rebuilding.

grep -i "^FROM" Dockerfile

Expected: your base image lines. Prefer minimal bases (distroless, alpine-based official images, or your distro's minimal variant) and pin the digest, not just the tag, so rebuilds are reproducible.

4. Rebuild regularly, not just on code changes

Base images get security updates constantly; an image built six months ago carries six months of CVEs no matter how clean it was at build time. Schedule weekly rebuilds of your base images even when app code hasnt changed.

printf 'base-image rebuild: weekly, [day]\nowner: [team or name]\n' | tee -a image-maintenance.txt

Expected: a documented rebuild cadence with an owner. CI rebuilds the image from the pinned Dockerfile, rescans, and pushes only if the scan passes.

5. Scan before push and keep the evidence

Make the registry the enforcement point too: only scanned-clean images get pushed to the production repository. Save scan reports as CI artifacts so audits and incident response can see exactly what shipped.

trivy image --format json --output scan-report.json [registry]/[image]:[tag] && ls -la scan-report.json

Expected: a JSON report artifact attached to the CI run. When a CVE drops next month, you grep the saved reports to answer "which of our images are affected" in minutes.

Variant: trivy vs grype which to use

Both are good and free. Trivy covers more (misconfigurations, secrets, licenses) in one binary; Grype pairs naturally with Syft SBOMs. Pick one, standardize, and move on; the scanner you actually run beats the theoretically better one.

Variant: too many vulnerabilities in base image

Switch to a slimmer base first (most findings live in packages your app never uses), then pin the digest, then set up the weekly rebuild. If the official image is still noisy, check whether your distro publishes a minimal or hardened variant.

Variant: scan docker image before docker hub push

The pre-push hook version: run the scan locally with --exit-code 1 before docker push, or better, push only from CI where the scan is mandatory. Humans forget; pipelines dont.

Why this happens

Images bundle an entire OS userland plus your app, and every package in there is a CVE waiting to be disclosed. Nobody reads the full package list of a base image, so vulnerabilities accumulate invisibly until someone scans. Scanning in the pipeline turns "we think our images are fine" into a checked fact on every build.

Edge cases and pitfalls

• Scanner database lag: fresh CVEs take hours to appear in scanner DBs; a clean scan is "clean as of the last DB update," not a guarantee.
• Unfixable OS CVEs: some findings have no fixed version yet; allowlist with expiry and revisit, dont just suppress forever.
• Distroless debugging: minimal images have no shell, which complicates debugging; keep a debug-tag variant with busybox for incidents.
• Multi-arch images: scan every architecture you ship; CVEs can differ between amd64 and arm64 builds.
• Secrets in layers: scanners flag leaked secrets too; a secret in an old layer is still in the image even if a later layer deletes the file.
• Scan time on huge images: multi-GB images make CI slow; slimming the image fixes both the CVE count and the pipeline speed.

Provenance

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

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

Thread query: container image scanning in the build pipeline

TL;DR: Scan every image you build before it ships: add Trivy or Grype to CI, fail the build on critical (and high, once you are clean) CVEs, and fix findings by upgrading the base image or the package, not by ignoring them. Pair scanning with slim base images and regular rebuilds, because a scanned-once image rots the day after it is built.