cve-search

# CVE Search Use this skill to turn vulnerability records into a scoped assessment lead. A public CVE record does not establish that a particular asset is affected. ## Workflow 1. Bound the query by product/vendor, version or build, platform, configuration, and assessment time range. For an asset review, capture the asset identifier, observed evidence source, and relevant exposure or control conditions. 2. Discover candidates from CVE.org/CNA records and vendor advisories. Cross-check NVD applicability data and, where useful, OSV/GHSA, CISA KEV, and FIRST EPSS. Prefer the current CNA and vendor record for product-specific claims; retain source disagreements as disagreements. 3. Verify record lifecycle metadata. Record whether the CVE is reserved, published, or rejected. Track a `disputed` tag or statement separately; it signals disagreement, not a lifecycle state or a CVE Program ruling on which party is correct. Preserve aliases without treating a similar identifier or title as proof of identity. See the [CVE Program CNA Rules](https://www.cve.org/ResourcesSupport/AllResources/CNARules) and [CVE record dispute guidance](https://www.cve.org/Resources/Media/Archives/OldWebsite/about/faqs.html). 4. Match the record's exact affected-product and configuration conditions to the evidence collected for the asset. Check vendor backports, package/build identifiers, optional components, mitigations, and deployment mode. NVD CPE applicability is a matching aid; unresolved match criteria and absent local evidence remain unknown, not confirmed findings. See [NVD CPE FAQs](https://nvd.nist.gov/general/faq-sections/cpe-faqs). 5. Separate technical severity and threat signals from local applicability and risk. Preserve the CVSS version, vector, score, and source. A CVSS Base score describes severity and should not stand alone as a local risk estimate ([FIRST CVSS User Guide](https://www.first.org/cvss/user-guide)). KEV means CISA lists the CVE as known exploited; it does not establish exploitation of the assessed asset or current activity there ([CISA KEV Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)). EPSS estimates the probability that a published CVE will be exploited in the wild in the next 30 days; record the daily score's date and do not treat it as asset-specific evidence ([FIRST EPSS](https://www.first.org/epss/)). 6. Assign an applicability result with its evidence: `matched`, `not matched`, or `unresolved`. Use `matched` only when the exact product, ecosystem/package, version or build identifier, and required conditions align with reliable local evidence. For distro or vendor backports, require that vendor's package advisory, changelog, or patch/build record identifying the fix; an upstream version string alone is insufficient. Use `not matched` when reliable evidence excludes the affected range or a required product/configuration condition. A WAF, firewall, or failed test may reduce exposure or block the observed path, but does not show that the vulnerable software is absent or fixed. A disputed record is `unresolved` only when the disagreement changes the affected product, version, or condition and current authoritative evidence does not settle it. For every `unresolved` result, name the next evidence check, such as package owner/build metadata, vendor backport advisory, enabled component/configuration, or a vendor-supported diagnostic. 7. Report the result in a compact entry and include retrieval date because records and signals change: ```md - **CVE-YYYY-NNNN — Title** - **Record:** reserved | published | rejected; disputed tag/statement: yes | no | unknown - **Assessment:** matched | not matched | unresolved; asset, ecosystem/package, exact build, and evidence - **Conditions:** affected range, configuration, exposure, mitigations, and whether controls only block access - **Severity:** CVSS version/vector/score and source; local risk context if assessed - **Threat signals:** KEV listed/not listed; EPSS value/date when used - **Remediation:** vendor fix or mitigation, with source - **Sources and checked:** authoritative URLs; retrieval date; unresolved question and next evidence check ``` ## Boundaries - Keep record facts, local observations, and analyst inferences distinct. Cite the source for every affected range, condition, and remediation claim. - Do not infer safety from absence in KEV, a low EPSS estimate, a missing NVD match, or an HTTP success. Catalogs and enrichments have coverage and freshness limits. - Public PoC availability is a reference signal, not proof of applicability or exploitability. When a task explicitly requires review of an existing PoC artifact, route to [PoC artifact review](../poc-weaponization/SKILL.md); this skill does not direct PoC execution or modification. - Report failed checks and collection gaps. Do not convert lack of evidence into a clean result.