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.

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.