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.

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.

1. 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.

1. 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.

1. 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.

1. 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