grype --only-fixed still lists CVEs with no fixed version - the flag doesn

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.

TL;DR

Scan production artifacts, not the whole source tree. Point grype at the built image or a production-only package set, and add ignore rules for known dev-only paths so the agent only triages findings that can actually ship. Test fixtures and devDependencies are real files, so the scanner is doing its job - the scope is wrong, not the tool.

grype flagged CVEs in test fixtures and devDependencies - the agent's severity queue was 80 percent noise

Steps

1. Confirm the noise is really dev-only. Export the findings to JSON and count how many hit packages listed under devDependencies or in test fixture directories.

   • Run: grype dir:. -o json, saving the output to a temp file, then count entries whose location path contains test, fixture, or __tests__.
   • Expected: a large share (in the reported case, about 80 percent) sit in dev-only paths.

2. Switch the scan target from the source tree to the production artifact. Scan the built container image or the deployed bundle instead of the repo root.

   • Run: grype [REGISTRY]/[IMAGE]:[TAG] -o json, saving the output to a temp file, and compare the finding count against step 1.
   • Expected: the production scan shows a fraction of the source-tree findings; dev-only packages are gone.

3. For source scans you must keep, generate a production-only package set. Use your package manager to list runtime dependencies only (for example, npm with the omit-dev option) and scan that output instead of the full lockfile.

   • Expected: dev-only packages no longer appear in the finding list.

4. Add ignore rules for the dev-only paths that survive. Create a grype config file with ignore entries for the known test fixture directories and dev-only packages, then point grype at it with the config flag.

   • Run: grype dir:. -c .grype.yaml -o json, saving the output for comparison.
   • Expected: findings in the ignored paths disappear; the rest are unchanged.

5. Add --only-fixed to the agent's default scan so the queue only contains CVEs with an available patch. Unfixable dev-only findings are the noisiest slice.

   • Run: grype [IMAGE] --only-fixed --fail-on high.
   • Expected: the queue shrinks to actionable items with fixes available.

6. Wire a weekly review of the ignore list into the agent's loop. Every ignored path or package gets re-checked monthly in case a dev dependency became a runtime one.

   • Expected: the ignore list stays current and no real finding hides behind a stale rule.

Use this when

• The severity queue is dominated by findings in test fixtures, example apps, or devDependencies.
• The agent scans the repo root or a directory that includes dev tooling.
• Triage time is being spent on packages that are not in the shipped artifact.
• Findings reference packages only used by build scripts, linters, or test runners.

Not for this skill when

• The findings are in runtime dependencies of the production image - those are real and need triage, not filtering.
• A dev dependency is actually bundled into the shipped artifact (some build setups do this); verify before ignoring.
• The scanner is misfiring on package versions rather than scope; that is a matcher problem, not a noise problem.
• You need a compliance report that covers all dependencies; scope filtering breaks that.

Variant phrasings

• grype reports hundreds of CVEs in node_modules dev dependencies
• scanner flags vulnerabilities in test fixtures and sample code
• how to exclude devDependencies from grype scan results
• severity queue full of findings in packages we do not ship

Why it happens

Grype catalogs every package it can find under the scan target, including devDependencies, test fixtures, and vendored examples. It has no way to know which packages ship to production, so a source-tree scan treats a test-only package the same as a runtime one. The agent then inherits the full list and burns triage effort on findings with no reachable path to production.

Edge cases

• Some projects bundle devDependencies into the final artifact by accident (a misconfigured build). Re-verify scope after every build change.
• --only-fixed can hide a critical CVE with no fix yet. Keep a separate watch list for unfixed criticals in production scope.
• Ignore rules by package name can mask the same package when it appears as a real runtime dependency elsewhere. Prefer path-based ignores where possible.
• Monorepos often have per-workspace devDependencies; a repo-wide ignore list may miss a workspace that uses a different test directory name.

Provenance

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

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

Thread query: grype flagged CVEs in test fixtures and devDependencies - the agent's severity queue was 80 percent noise

TL;DR: Scan production artifacts, not the whole source tree. Point grype at the built image or a production-only package set, and add ignore rules for known dev-only paths so the agent only triages findings that can actually ship. Test fixtures and devDependencies are real files, so the scanner is doing its job - the scope is wrong, not the tool.

Not specified by the original author.

TL;DR

In a CSAF document, productstatus is stated per product, not per advisory. Your agent read a "fixed" status attached to some other product in the tree and closed CVEs that are still knownaffected on the release you actually run. Map your running version to its CSAF product ID first, then read the status for that product ID only. Close nothing on any other product's status.

The query

Red Hat CSAF: the agent read product_status fixed and closed CVEs that were still known_affected on the running release

Use this when

• CVEs were closed as fixed based on CSAF data but the running release is still vulnerable
• The CSAF document covers multiple products or releases
• An agent does the product-to-status matching

Not for

• CSAF files that fail to parse (a format problem)
• Deciding whether to patch (a remediation decision)
• Non-CSAF advisory formats (each has its own status model)

Steps

1. Reopen the wrongly closed CVEs

Any CVE closed on the basis of another product's status goes back to open with a note explaining the error. Do this before anything else; the closed state is actively misleading.

Expected output: the affected CVEs are open again with the correction recorded.

2. Map your running release to its CSAF product ID

Find your exact product and version in the document's product tree and note its product ID. Product names that look similar (different minor versions, different variants) are different IDs.

Expected output: one product ID that unambiguously means "what we run".

3. Read product_status for that ID only

In the vulnerabilities section, look at the productstatus entries keyed by your product ID. fixed, knownaffected, knownnotaffected, and first_affected are per-product statements; ignore every other product's entries.

Expected output: a status verdict per CVE for your product, and only your product.

4. Encode the rule in the agent

The agent's CSAF reader must take the running product ID as an input and filter all status reads by it. A status lookup without a product filter is a bug, full stop.

Expected output: the agent cannot produce a verdict without naming the product it applies to.

5. Verify on a known-affected CVE

Pick a CVE you know is still open on your release and run the fixed reader over it. Verify: it reports known_affected, not fixed.

Variant phrasings

CSAF product_status fixed wrong product closed CVE

The short symptom search.

red hat csaf known_affected running release triage

The cause-first search.

Compatibility: CSAF 2.0 documents as published by Red Hat and other vendors. The per-product status model is part of the CSAF standard.

Why it happens

CSAF documents are written for entire product families, so one advisory routinely carries different statuses for different releases: fixed on the newest, known_affected on the one you run. A reader that grabs the first "fixed" it finds, or that treats the advisory as having one status, collapses that per-product truth into a single wrong answer. The format is precise; the reader was sloppy.

Edge cases / pitfalls

• Product trees nest (product groups containing products). Make sure your ID resolution walks the full tree; a group-level status is not a product-level status.
• firstaffected and firstfixed add nuance: a product can be first_affected in one release and fixed in another. Read the whole status set for your ID.
• Do not infer "fixed" from the absence of known_affected. Absence of a statement is not a statement; only an explicit fixed for your product ID counts.
• When the vendor has not published a CSAF document for your product at all, say "no data", not "not affected".

Provenance

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

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

Thread query: Red Hat CSAF: the agent read productstatus fixed and closed CVEs that were still knownaffected on the running release

TL;DR: In a CSAF document, productstatus is stated per product, not per advisory. Your agent read a "fixed" status attached to some other product in the tree and closed CVEs that are still knownaffected on the release you actually run. Map your running version to its CSAF product ID first, then read the status for that product ID only. Close nothing on any other product's status.