the agent parsed Red Hat's CSAF feed by hand - the format update moved

Not specified by the original author.

TL;DR

Stop parsing CSAF by hand and use a real CSAF library. The spec locates fixed versions through the product tree and remediation entries, not through a fixed field position - hand-rolled field extraction breaks every time the feed layout shifts. Parse by the spec and the moves stop mattering.

the agent parsed Red Hat's CSAF feed by hand - the format update moved the fixed-version field and patches looked missing

Steps

1. Confirm the field moved, not the data. Download a current Red Hat CSAF document and search it for the fixed version string you expect; note the JSON path where it now lives.

   • Expected: the version is still published, just at a different path than the parser reads.

2. Replace the hand parser with a maintained CSAF library for your language. The library follows the CSAF 2.0 spec: producttree to fullproduct_names for product IDs, then vulnerabilities to remediations for the fix entries.

   • Expected: parsing follows product IDs and remediation categories instead of hardcoded paths.

3. Resolve fixed versions the spec way: for each vulnerability, take the remediation entries in the vendorfix category, read their productids, and map those IDs through the product tree to product names and versions.

   • Expected: fixed versions resolve correctly regardless of where the feed places the fields.

4. Validate every document against the CSAF JSON schema before parsing. Quarantine documents that fail validation instead of parsing them halfway.

   • Expected: malformed or half-migrated feed documents never produce fake "no patch" verdicts.

5. Add a canary check: track how many advisories per run report "no fixed version." Alert if the share jumps, because a silent parser break looks exactly like a patch drought.

   • Expected: the next feed layout change pages you within one run.

6. Re-run patch detection over the window the hand parser was broken and correct every "patch missing" verdict it produced.

   • Expected: the false "missing patch" findings get their real fixed versions.

Use this when

• Fixed versions appear missing after a CSAF feed format update.
• The agent extracts CSAF fields with hardcoded JSON paths.
• Patch-availability verdicts flipped from "fix available" to "no fix" with no code change.
• You consume Red Hat or other vendor CSAF/VEX feeds directly.

Not for this skill when

• No fixed version is genuinely published yet; the feed is correct and the patch really is missing.
• You already use a spec-compliant CSAF library; check its version and changelog first.
• The feed itself is stale or unreachable; that is a feed-availability problem, not a parser problem.

Variant phrasings

• CSAF parser broken after feed format change
• Red Hat VEX fixed version not found by parser
• hand-parsed CSAF feed returning wrong patch data
• remediations missing from CSAF vulnerability entries

Why it happens

CSAF is a rich linked format: products are defined once in the product tree and referenced by ID everywhere else, and fixes live in remediation entries keyed by category. A hand-rolled parser that grabs "the fixed version field" by position works until the publisher reorganizes the document, then it reads the wrong node or nothing at all. The failure is silent because a missing field parses as "no patch," which is a plausible-looking wrong answer.

Edge cases

• One CSAF document can carry multiple product branches (different RHEL versions); make sure the fixed version you report matches the product branch you actually run.
• Some remediations are workarounds or mitigations, not vendor fixes; only the vendor_fix category counts as a patch.
• CSAF documents get revised; always check the revision number and re-parse on revision bumps, or you will triage stale fix data.

Provenance

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

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

Thread query: the agent parsed Red Hat's CSAF feed by hand - the format update moved the fixed-version field and patches looked missing

TL;DR: Stop parsing CSAF by hand and use a real CSAF library. The spec locates fixed versions through the product tree and remediation entries, not through a fixed field position - hand-rolled field extraction breaks every time the feed layout shifts. Parse by the spec and the moves stop mattering.

Not specified by the original author.

TL;DR

Errata prose is written for humans; the fixed-version facts live in structured sources. Stop regexing the advisory text and read Red Hat's security API or OVAL data, compare installed NVRs against fixed NVRs, and close what is confirmed patched. Keep prose parsing only as a low-confidence fallback.

the agent couldn't parse "fixed in" from Red Hat errata text - it kept CVEs open that RHEL had patched months ago

Use this when

• RHEL CVEs stay open long after the patch shipped.
• The agent's errata parser returns nothing or garbage for the fixed version.
• The backlog is full of "open" CVEs that rpm -q shows as patched.

Not for this skill when

• The system is genuinely unpatched. Then the ticket is correct; patch the host.
• You are not on RHEL/CentOS/Rocky. Other ecosystems have their own advisory formats.

Steps

1. Pick a sample of the stuck CVEs and check the installed package NVR against the errata's fixed NVR by hand. Verify: the installed version is at or above the fixed one, confirming these are parser failures, not missing patches.
2. Switch the agent to the structured source: Red Hat's Security Data API or the OVAL definitions, which carry fixed package NVRs as fields. Verify: the agent returns a fixed NVR for a test CVE without touching prose.
3. Compare installed vs fixed with proper RPM version comparison (not string comparison). Verify: epoch and release segments compare correctly on edge cases.
4. Close the confirmed-patched CVEs with the evidence (installed NVR, fixed NVR, errata ID). Verify: each closed ticket cites the comparison.
5. Demote prose parsing to fallback with a confidence flag; anything it "finds" in prose needs the structured check before closing. Verify: a prose-only hit stays open pending verification.

Variant phrasings

Red Hat errata fixed in parse

The short phrasing.

RHEL patched CVE still open

The symptom search.

errata text fixed version extraction

The parsing phrasing.

Compatibility: RHEL 7/8/9, CentOS, Rocky, Alma; Red Hat's Security Data API covers the family.

Why it happens

Errata text varies in phrasing ("fixed in", "updated to", "resolves"), and a regex written for one phrasing misses the rest. The agent was parsing the human-readable layer instead of the machine-readable layer that Red Hat publishes for exactly this purpose. Structured data exists; use it.

Edge cases / pitfalls

• Kernel and userspace errata ship on different rhythms; a CVE can be fixed in userspace errata while the kernel fix is still pending. Compare per package, not per CVE.
• Backported fixes keep the version number looking old; the release segment carries the fix, which is why string comparison fails.
• Extended Lifecycle Support errata live in a different stream; make sure the agent reads the stream your hosts actually consume.

Provenance

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

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

Thread query: the agent couldn't parse "fixed in" from Red Hat errata text - it kept CVEs open that RHEL had patched months ago

TL;DR: Errata prose is written for humans; the fixed-version facts live in structured sources. Stop regexing the advisory text and read Red Hat's security API or OVAL data, compare installed NVRs against fixed NVRs, and close what is confirmed patched. Keep prose parsing only as a low-confidence fallback.

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.