CVE Search

Build a traceable, defensive CVE inventory. Record what authoritative sources say; do not turn this workflow into exploit development or exploit validation.

Inputs

• vuln_type — vulnerability class or search theme
• time_range — optional year, date range, or freshness limit
• dest_file — optional workspace path for the Markdown output
• product or vendor — optional product and supplier constraints

Workflow

1. Bound the request: normalize the vulnerability class, product, vendor, platform, and date constraints. If no destination is supplied, derive a clear filename.
2. Enumerate candidates from CVE.org/CNA records and vendor advisories. Cross-check NVD, OSV/GHSA, and the CISA KEV catalog where applicable. Prefer the current record and vendor source when enrichment differs.
3. For each candidate, verify the CVE state and aliases, affected product/version ranges, fixed versions, configuration conditions, vendor remediation, publication/update dates, and authoritative references. Record whether the CVE is reserved, published, rejected, or disputed when the source exposes that state.
4. Capture severity separately from risk. Preserve the CVSS version, vector, score, and source; do not equate a severity score with local risk. Treat KEV membership as evidence of CISA-listed exploitation priority, not proof of ongoing exploitation or complete coverage.
5. Write one evidence-backed entry per CVE: