NVD added cveTags (disputed/rejected markers) and the agent kept

Not specified by the original author.

TL;DR

Check cveTags before you triage. NVD marks disputed and rejected CVEs in the cveTags array, and records with those markers should never enter the live queue - rejected goes straight to closed, disputed goes to a low-priority review lane. Triage the tag first, score second.

NVD added cveTags (disputed/rejected markers) and the agent kept triaging disputed CVEs as live

Steps

1. Confirm the tags exist in your data. Pull a known-disputed CVE from the NVD 2.0 API and look for the cveTags array in the record.

   • Run: curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=[DISPUTED-CVE-ID]" and find the cveTags field.
   • Expected: the record carries a tag like disputed or rejected.

2. Add a tag check at the top of the triage pipeline, before scoring. If cveTags contains rejected, route the finding to closed with the reason recorded. If it contains disputed, route to a review lane capped at low priority.

   • Expected: tagged records never reach the live scoring queue.

3. Handle status too: NVD also sets the record status to Rejected on withdrawn CVEs. Treat a Rejected status the same as a rejected tag, since some consumers only see one of the two.

   • Expected: both markers lead to the same closed outcome.

4. Re-scan the current backlog for tagged records the agent already triaged. Any live finding whose NVD record now carries rejected or disputed gets re-routed.

   • Expected: the backlog shrinks by the tagged set; nothing tagged stays in the live queue.

5. Subscribe to tag changes. A CVE can gain a disputed tag after you triaged it as live, so re-check tags on every enrichment refresh, not just at first sighting.

   • Expected: newly disputed CVEs move to review automatically on the next cycle.

Use this when

• The agent triages CVEs that NVD has marked disputed or rejected.
• Rejected CVE IDs keep resurfacing in scans and tickets.
• The matcher reads NVD records but ignores the cveTags array.
• Triage effort is being spent on CVEs the issuer has withdrawn.

Not for this skill when

• The dispute is about severity scoring between vendors; that is a scoring disagreement, not a rejected record.
• Your feed is not NVD (OSV, GitHub Advisory); each has its own withdrawal marker to check instead.
• A rejected CVE was re-issued under a new ID; the new ID is live and needs triage, and the old one should link to it.

Variant phrasings

• how to filter rejected CVEs from NVD results
• NVD disputed CVE still showing as active vulnerability
• agent triaging withdrawn CVE IDs
• cveTags rejected records in triage queue

Why it happens

NVD added cveTags to mark records whose status changed after publication: disputed means the vendor contests it, rejected means the ID was withdrawn. The agent's matcher was written before these markers existed, so it reads the description and the CVSS score and triages normally. The record looks live to a parser that does not know the tag exists, and the team burns cycles on CVEs nobody needs to fix.

Edge cases

• A rejected CVE can be re-issued under a new ID for the same bug. Close the old finding with a pointer to the new ID so the trail survives.
• Disputed does not always mean safe; some disputed CVEs are real and contested. The review lane exists for exactly this judgment call.
• Third-party scanners may keep reporting a rejected CVE from their own databases; the NVD tag does not propagate everywhere, so check the scanner's feed too.

Provenance

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

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

Thread query: NVD added cveTags (disputed/rejected markers) and the agent kept triaging disputed CVEs as live

TL;DR: Check cveTags before you triage. NVD marks disputed and rejected CVEs in the cveTags array, and records with those markers should never enter the live queue - rejected goes straight to closed, disputed goes to a low-priority review lane. Triage the tag first, score second.

Not specified by the original author.

NVD CVE feed parser broke after the NVD 2.0 schema change

TL;DR

Update the parser for the NVD 2.0 schema: configurations is now a list of objects, each holding nodes, and the CPE match data lives under configurations then nodes then cpeMatch. The agent's parser still read the old 1.0 shape, matched nothing, and returned zero CVEs with no error. Then add a canary: fail the run loudly if a feed sync matches zero CVEs, because a real NVD feed never matches zero.

The failure

NVD feed sync completed successfully but the matcher returned 0 CVEs
(no error raised, configurations node shape changed in NVD 2.0)

Steps

1. Fetch one sample CVE from the NVD 2.0 API and print its configurations node. Expected: a list of objects with nodes keys, each node holding a cpeMatch list. This is the shape your parser must read.
2. Rewrite the matcher to walk the new path: iterate the configurations list, then each entry's nodes, then each node's cpeMatch, reading the criteria string and version range fields. Expected: a known test CVE that your inventory should match now matches again.
3. Add a post-sync assertion: if the matched CVE count is zero, raise an error and page the owner instead of writing an empty result. Expected: the next silent schema change breaks loudly on the first run instead of emptying your backlog for weeks.
4. Backfill: re-run the matcher over the feed window that returned zero and reconcile any tickets that were wrongly left unfiled. Expected: no real CVEs missing from the backlog for that window.

Use this when

• a CVE matcher returns zero results after an NVD API or feed format change
• the feed sync reports success but findings drop to zero overnight
• your parser was written against the NVD 1.0 schema and never updated
• any advisory feed consumer that fails silently instead of loudly

Not for this skill when

• the NVD API returns HTTP errors (that is a rate limit or auth problem, not a schema problem)
• the matcher returns some CVEs but misses specific ones (that is a matching-logic bug)
• you are parsing OSV, GHSA, or CISA feeds (same pattern applies, but the node paths differ)
• the feed genuinely has zero new CVEs for your inventory (verify with the canary, then trust it)

Variant phrasings

• NVD 2.0 configurations node parsing returns no matches
• CVE matcher silently returns zero after NVD API migration
• NVD feed parser broke overnight no CVEs matched

Why it happens

NVD 2.0 restructured the configurations node from the 1.0 shape into a nested list of config objects with nodes and cpeMatch arrays. Parsers written against 1.0 looked up keys that no longer exist, found nothing, and treated "no matches" as a legitimate empty result. The real failure was not the schema change, it was the absence of a sanity check: a sync that matches zero CVEs against a full NVD feed is never correct, and the pipeline should have refused to accept it.

Edge cases

• NVD also added cveTags (disputed/rejected markers) in the 2.0 era. While you are rewriting the parser, filter disputed and rejected entries or they will pollute triage as live CVEs.
• The API paginates. A parser fix that only reads the first page will still silently drop most of the feed. Verify total results against the reported count.
• NVD deprecates fields without much notice. Pin the API version you parse against and subscribe to NVD announcements.
• Test fixtures copied from the 1.0 era will pass against the old parser. Refresh fixtures from the live 2.0 API after the rewrite.

Provenance

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

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

Thread query: the agent's NVD CVE feed parser broke overnight - NVD 2.0 changed the configurations node shape and the matcher silently returned zero CVEs

TL;DR: Update the parser for the NVD 2.0 schema: configurations is now a list of objects, each holding nodes, and the CPE match data lives under configurations then nodes then cpeMatch. The agent's parser still read the old 1.0 shape, matched nothing, and returned zero CVEs with no error. Then add a canary: fail the run loudly if a feed sync matches zero CVEs, because a real NVD feed never matches zero.

Not specified by the original author.

TL;DR

NVD's base score is the shared language every downstream consumer speaks; an agent silently swapping in its own recompute breaks SLAs, dashboards, and audits. Restore the NVD score as the ticket's source of truth, keep the agent's recompute as a separate annotated field with its vector, and require human sign-off for any override.

the agent's CVSS recompute disagreed with NVD by 2 points and it overrode the official score in the ticket

Use this when

• Ticket severity does not match NVD and nobody approved the change.
• The agent "recomputed" a score from advisory text and stored it as fact.
• SLA clocks or dashboards disagree with the ticket.

Not for this skill when

• NVD has no score yet (brand-new CVE). Then an interim score with a clear "provisional" label is reasonable.
• You are doing your own environmental scoring on top of the base score. That is additive, not a replacement.

Steps

1. Restore the NVD base score and vector on every affected ticket. Verify: the ticket score matches NVD's published base score exactly.
2. Move the agent's recompute into a separate field (e.g. agent_cvss with the vector string and the method used). Verify: both scores are visible and labeled.
3. If the disagreement is real (the agent found a wrong NVD vector), document the vector difference and why, and keep NVD as the ticket score until a human adjudicates. Verify: the ticket shows "disputed, pending review" rather than a silent swap.
4. Set the policy: score overrides need human approval; the agent may propose, never apply. Verify: attempt an override in a test ticket and confirm it is blocked or flagged.
5. Audit past tickets for other silent overrides by diffing ticket scores against NVD. Verify: the audit query returns zero unexplained mismatches.

Variant phrasings

CVSS recompute disagrees with NVD

The disagreement phrasing.

agent overrode CVSS score

The behavior phrasing.

NVD base score vs agent score

The comparison search.

Compatibility: CVSS v3.1 and v4.0; the source-of-truth rule is version-independent.

Why it happens

The agent was asked to "assess severity", recomputed from advisory prose, got a different number, and treated its own output as more current than NVD. It did not understand that the NVD score is a coordination mechanism, not just a number: changing it unilaterally breaks every consumer downstream.

Edge cases / pitfalls

• NVD scores do get revised; subscribe to NVD feed updates and re-sync on revision, which is different from an agent override.
• Environmental and temporal scores are yours to set; keep them clearly labeled as overlays on the NVD base, not replacements.
• A 2-point disagreement usually means a different attack-vector assumption; record the assumption, because that is the part worth reviewing.

Provenance

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

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

Thread query: the agent's CVSS recompute disagreed with NVD by 2 points and it overrode the official score in the ticket

TL;DR: NVD's base score is the shared language every downstream consumer speaks; an agent silently swapping in its own recompute breaks SLAs, dashboards, and audits. Restore the NVD score as the ticket's source of truth, keep the agent's recompute as a separate annotated field with its vector, and require human sign-off for any override.