Vulnerability Lookup

Looks up known-vulnerability data — CVE records, CVSS scores, affected-product scope, and remediation references — from a public vulnerability data source, by keyword, CPE/product identifier, or exact CVE ID. This is a read-only lookup capability, not a scanning, tracking, or remediation one.

Why this skill is diagnostic-shaped, not CRUD-shaped

This skill does not create, read-as-a-single-record, update, or delete anything on a platform the caller owns — there is no “record” belonging to the caller to operate on in the CRUD sense. What it actually does is take a symptom-shaped question (“is product X, version Y, exposed to a known issue,” “what does CVE-XXXX-XXXXX actually affect and how severe is it,” “what’s been published against this product recently”) and route it to the query shape that answers it: an exact-ID lookup when a CVE ID is already known, a keyword/CPE search when only a product name or version string is known, or a severity/date-window listing when the question is “what’s new/critical for this product line.” The useful output is a diagnosis-style answer — which CVE(s) apply, their CVSS severity, and the evidence (the literal record returned) — not a single created/updated/deleted row with one success/failure outcome. So this skill is shaped as a decision tree, not a linear operation: pick the entry point that matches what the caller already knows (an exact CVE ID, a product/keyword, or a severity/date question), then follow that source’s own query rules to the answer. Because every operation here is a read against a public data source, there is also no destructive-action confirmation gate anywhere in this skill — nothing it does changes state on any system, the caller’s own or otherwise.

When to use this skill

• Given a product/component name (and optionally a version), determine whether known CVEs exist against it, and what their severity is.
• Given an exact CVE ID, retrieve its full record — description, CVSS score(s), affected configurations, and reference links.
• Given a Cisco product line, retrieve Cisco’s own PSIRT security advisories (which map to CVEs but carry Cisco-specific fields like Security Impact Rating and bug IDs) rather than the generic NVD record alone.
• Not for tracking a finding through a remediation workflow, filing a ticket against it, or patching the affected system — those are separate capabilities (change/ticketing, patch/config management) this skill only feeds evidence into.

Universal concepts (CVE/CVSS — genuinely shared standard across both sources)

Both sources covered here speak the same two open standards, not just similar-looking data:

• CVE (Common Vulnerabilities and Exposures) is the shared identifier namespace (CVE-<year>-<sequence>) both sources key their records by, so the same ID names the same underlying vulnerability wherever it appears. Whether an exact-ID lookup returns a record depends on each source’s own coverage (Cisco PSIRT covers Cisco products only), so an empty result from one source says nothing about the other. Where both return a record, description wording, scoring, affected-product scope, and freshness are maintained independently and can differ. Each source’s own field names for it are in its procedure.md.
• CVSS (Common Vulnerability Scoring System) is the shared open severity-scoring standard, but is not universally at one version across sources or even within a single source’s own records — one source can return multiple CVSS versions side by side on the same CVE record (because the standard itself has been revised over time and old scores are backfilled rather than discarded), while another surfaces only a single current score plus its own separate, non-CVSS-standard severity rating. Do not assume every record from either source carries every CVSS version — check which version(s) are actually present before comparing scores across two records, and do not silently compare one source’s own qualitative rating against the other’s CVSS severity string as if they were the same scale; see each source’s own procedure.md for its exact field names and whether its rating is CVSS-standard or source-specific.
• Neither source’s own documentation claims a single universal vulnerability-lifecycle status vocabulary across the two — each source has its own status/version fields and vocabulary, not a shared standard the way the CVE ID and the base CVSS numeric score are. Treat status/lifecycle fields as source-specific and always consult that source’s own procedure.md rather than assuming one source’s status word means the same thing in the other’s data.

See references/INDEX.md for which sources have a procedure, and each source’s own file for its documented limits and unknowns.

Procedure

1. Identify the target source — from the caller’s request or the source argument (nvd or cisco-psirt). Check references/INDEX.md; if no matching row exists, stop: this skill doesn’t cover it yet.
2. Identify the lookup type the caller’s question actually needs — an exact CVE ID lookup, a keyword/CPE/product search when no CVE ID is known yet, or a severity/date-window listing for a “what’s new/critical” question. This determines which entry point to use in references/<source>/procedure.md; that file is organized by lookup type, not a fixed linear sequence.
3. Open references/<source>/procedure.md and follow its steps for that lookup type exactly — it states which query parameters that source’s own API uses for the chosen lookup type, how to read the resulting CVE/advisory record, and how to page through results if there are more than one page’s worth.
4. Report the result — the matching CVE ID(s), the CVSS score/version (or Cisco SIR, if that source), a plain-language severity read, and the literal reference links the source’s own record provides — never report a severity conclusion without the record that supports it. If the lookup returned zero matches, report that plainly rather than treating it as an error; a genuine “no known CVEs found for this query” is a valid, useful answer.

Known limitations

• Covers NVD and Cisco PSIRT openVuln only — see references/INDEX.md. A vendor-specific advisory feed not listed there (e.g. another vendor’s own PSIRT-equivalent) needs a new reference file before this skill can be used for it.
• Read-only lookup only. Does not scan a live system for installed software/versions to compare against results, track a finding, or remediate anything — a caller who needs to act on a lookup’s result needs a separate capability for that.
• NVD’s data covers vulnerabilities broadly across many vendors and products; Cisco PSIRT’s data covers Cisco’s own products specifically and includes Cisco-specific fields (Security Impact Rating, affected Cisco bug IDs) that NVD’s generic record does not carry. Don’t assume NVD’s keyword/CPE search is a substitute for Cisco PSIRT’s product-specific advisory detail, or vice versa, for a Cisco product question — see each source’s own procedure.md for what it does and doesn’t cover.

Contributing to this skill

SKILL.md only changes for two reasons: a bug in the universal CVE/CVSS concepts or router logic above, or adding a pointer to a newly supported source. Source-specific detail — a new query parameter, a corrected field name, a changed base URL, an entirely new lookup type — belongs in that source’s own references/<source>/ files, never here.

Tools

Each source assumes its own authenticated API client — see references/INDEX.md for which, and that source’s procedure.md and endpoints.md for the exact wire-level calls.

Verification checklist

• Target source confirmed against references/INDEX.md before proceeding
• Lookup type (exact CVE ID, keyword/CPE/product search, or severity/date listing) correctly identified before opening that source’s procedure
• That source’s own procedure.md was followed for the identified lookup type, including its pagination handling if more than one page of results exists
• Result reported together with the literal record (CVE ID, score, references) that supports it — never a bare severity conclusion
• A zero-match result was reported as a valid answer, not silently dropped or treated as failure
• No CVSS value from one source was compared directly against a differently-scaled rating (e.g. Cisco’s SIR) from another source without noting they are different scales