ZEN SecDB MCP Server

List the known exploits, proofs of concept, and detection templates for a specific CVE. ## What this tool does Returns the exploit maturity of a CVE and the related public material known to SecDB: - Metasploit modules - Exploit-DB entries - Nuclei templates - proofs of concept published on GitHub ## When to use this tool Use this tool when the user asks: - "Is there a public exploit for this CVE?" - "Is there a Metasploit module or a Nuclei template for this vulnerability?" - "How mature is the exploitation of this CVE?" For other evidence (scanner plugins, social media, MISP), use `sightings_search`. ## Inputs - **cve_id**: valid CVE identifier (`CVE-YYYY-NNNNN`). - **limit**: maximum number of items to return for each kind of material (default 10, maximum 100). ## Outputs - **exploit_maturity**: `score`, `max`, and the `sources` that contribute to the score - **metasploit**: modules, each with `module`, `name`, `type` - **exploitdb**: entries, each with `id`, `description`, `type`, `platform`, `date_published` - **nuclei**: templates, each with `template`, `name`, `severity` - **poc**: repositories, each with `name`, `html_url`, `description` - **totals**: total number of items for each kind of material, before `limit` is applied ## LLM usage guidelines - Empty lists mean that SecDB knows no such material, not that the vulnerability cannot be exploited. - Report references and availability only: do not reproduce or write exploit code.

Get the timeline of events for a specific CVE. ## What this tool does Returns the dated events known to SecDB for a CVE, most recent first: - **published**: publication of the CVE - **nvd**: NVD changes (CVSS, CPE, CWE, references, description) - **advisory**: security advisories that mention the CVE - **nasl**: NASL detection plugins that cover the CVE - **cisa-kev**, **eu-kev**: addition to a Known Exploited Vulnerabilities catalog - **poc**: public proof-of-concept repositories on GitHub - **exploitdb**: Exploit-DB entries - **alias**: public disclosure under a known name Every event carries the date of the event itself, not the date it reached SecDB. Sources without a date are not included. EPSS changes are not included: use `epss_timeseries`. ## When to use this tool Use this tool when the user asks: - "What changed on CVE-XYZ since last week?" - "When was this CVE added to KEV?" - "When did the first PoC or detection plugin appear?" For the current state of a CVE, use `vulnerability_info`. ## Inputs - **cve_id**: valid CVE identifier (`CVE-YYYY-NNNNN`). - **types**: only return these event types (default: all). - **since**: only return events from this date, included (`YYYY-MM-DD`). ## Outputs - **cve_id**: CVE identifier. - **returned**: number of events returned. - **counts**: number of events for each type. It follows `since` but not `types`, so it also shows what `types` left out. - **events**: each with `type`, `timestamp`, and `change`. The fields of `change` depend on the type: - **published**: none - **nvd**: `source`, `event`, `action`, `type`, `old`, `new` - **advisory**: `advisory_type`, `advisory_id`, `advisory_severity`, `advisory_title` - **nasl**: `plugin_id`, `plugin_vendor`, `plugin_name` - **cisa-kev**: `vulnerability_name`, `due_date` - **eu-kev**: `vulnerability_name`, `patched_since` - **poc**: `name`, `description`, `url` - **exploitdb**: `id`, `description`, `file` - **alias**: `alias` ## LLM usage guidelines - The response is not paginated and can be very large for well-known CVEs, mostly because of `poc` and `nasl` events: use `types` and `since` to request only what you need. - An event dated before `since` can still be new to SecDB: do not use this tool to prove that nothing changed. - Do not guess dates or events: use what the tool returns.

Get detailed information about a specific CVE. ## What this tool does Retrieves the full vulnerability record for a CVE from SecDB, including: - official description and summary - CVSS metrics (all versions available) - current EPSS score and percentile (if present) - CISA KEV details (if listed) - affected products - vendor/security advisories - weakness classification (CWE) - number of known Metasploit modules and Exploit-DB entries ## When to use this tool Use this tool when the user asks: - "Give me details about CVE-XYZ." - "Which products are affected by this vulnerability?" - "Show me advisories or references for this CVE." - "Explain what this vulnerability is and how serious it is." This tool is ideal for **deep inspection of a single vulnerability**. For multiple CVEs, call the tool once per CVE. ## Inputs - **cve_id**: valid CVE identifier (`CVE-YYYY-NNNNN`). ## Outputs - **cve_id**, **url**, **title**, **description**, **cna**, **status**, **published**, **modified**, **aliases** - **cwe**: each with `id`, `name`, and `url` - **cvss**: one entry for each CVSS version available, with `version`, `score`, `severity`, and `vector` - **epss**: `score` and `percentile` (both as percentages) and `date`, or `null` - **exploits**: number of known `metasploit` modules and `exploitdb` entries - **kev**: `listed`, `in_cisa`, `in_eu`, `date` (first listing), `ransomware`, and `cisa` (`vendor`, `product`, `description`, `required_action`, `notes`, `added_date`, `due_date`, or `null`) - **affected_products**: each with `vendor`, `product`, `part`, `title`, and `url`, without versions - **advisories**: each with `id`, `source`, `severity`, and `url`. Use `advisory_info` for the details of an advisory ## LLM usage guidelines - Always prefer this tool when the user needs factual information about a specific CVE. - If multiple CVEs are mentioned, call the tool once per CVE. - Combine with: - **`vulnerability_score`** - to get the CVSS vector explained in natural language - **`vulnerability_exploits`** - to list the known exploits and PoCs - **`vulnerability_history`** - to get the timeline of events - **`sightings_search`** - to check real-world exploitation, PoCs, plugins, advisories - **`ssvc_calculator`** - to compute prioritization based on the vulnerability data - Do not hallucinate product lists, advisories, or details—use what the tool returns.

Get CVSS and current EPSS score for one CVE, or for a list of CVEs in a single call. ## What this tool does Returns a full risk snapshot for a CVE, including: - CVSS version - CVSS base score - CVSS severity - CVSS vector string - human-readable explanation of the CVSS vector - current EPSS score The field **`cvss_explain`** provides a natural-language interpretation of the CVSS vector (attack conditions, privileges, user interaction, impact breakdown). Example: For `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`, the explanation may read: *"The vulnerability can be exploited remotely over the network with low complexity, without authentication and without user interaction. Exploitation may lead to high impact on confidentiality, high impact on integrity, and high impact on availability."* ## When to use this tool Use this tool when the user asks: - "What is the CVSS/EPSS of this CVE?" - "Explain the CVSS vector of this vulnerability." - "What is the severity and why?" - "Give me the risk profile for this CVE." For EPSS historical trends, use `epss_timeseries`. ## Inputs Send one of these: - **cve_id**: valid CVE identifier (`CVE-YYYY-NNNNN`). - **cve_ids**: list of up to 100 CVE identifiers. ## Outputs With `cve_ids`: - `results`: one item for each CVE found, with `cve_id` and the fields below except `cvss_explain` - `not_found`: the CVEs that SecDB does not know With `cve_id`: - `cvss_version` - `cvss_base_score` - `cvss_base_severity` - `cvss_vector_string` - `cvss_explain` - human-readable explanation of the CVSS vector - `epss_score` - as a percentage (`94.36` means 94.36%) Any of these fields is `null` when SecDB has no such data for the CVE (for example a CVE not yet analyzed or scored). ## LLM usage guidelines - Never guess CVSS or EPSS values—always call this tool. - If a field is `null`, say that the value is not available. - Use the `cvss_explain` field directly when the user wants an interpretation of the vector string. - If multiple CVEs are referenced, send them all in `cve_ids`. To explain a vector from the results, use `cvss_explain`. - Combine this tool with `sightings_search` or `ssvc_calculator` for more complete risk assessments.

Perform a full-text vulnerability search in SecDB. ## What this tool does Searches across: - CVE entries - Security advisories - Exploit references - Product and vendor vulnerability data ## Searchable fields (Lucene syntax supported): - type: result type - cve, cwe, advisory, nasl, exploitdb - id: exact identifier, without wildcards (e.g. id:CVE-2021-44228) - title: resource title or name - summary: short summary - description: full description text - alias: known vulnerability names (e.g. alias:log4shell) - severity: critical, high, medium, low - kev: true/false — CISA KEV catalog membership - status: NVD status (CVE only) e.g. analyzed, modified - published: publication date (e.g. published:>="2026-01-01T00:00:00Z") - modified: last modification date (e.g. modified:>="2026-01-01T00:00:00Z") - cve: related CVE ID (e.g. cve:CVE-2026-44827) - cwe: related CWE ID (e.g. cwe:CWE-79) - attack_vector: network, adjacent, local, physical - cvss_score: CVSS base score (e.g. cvss_score:>=7) Default operator is AND. Use OR for alternatives, quotes for exact phrases, * for wildcards. For ranges use `>`, `>=`, `<`, and `<=`, repeating the field for both ends. Dates need a quoted date and time in UTC. ## Examples: - "apache struts rce" → RCE vulnerabilities in Apache Struts - "id:CVE-2026-44827" → exact CVE lookup - "type:advisory AND severity:critical" → critical advisories - "alias:log4shell" → Log4Shell by alias - "cve:CVE-2026-44827 AND type:exploitdb" → ExploitDB entries for a CVE - "cvss_score:>=9 AND kev:true" → critical KEV CVEs - "type:cve AND published:>=\"2026-10-01T00:00:00Z\" AND published:<=\"2026-10-31T23:59:59Z\"" → CVEs published in October 2026 ## When to use this tool Use this tool when the user asks: - to look up a CVE, advisory, exploit, or product - "show vulnerabilities for X" - "search for advisories about Y" - exploratory or broad vulnerability discovery ## Inputs - **query**: free-text search term (CVE ID, advisory ID, product name, exploit name, vendor, keyword, etc.) - **limit**: maximum number of results to return (default 10, maximum 50) - **page**: page of results to return (default 1) - **type**: only return results of this type (`cve`, `cwe`, `advisory`, `nasl`, `exploitdb`) - **sort**: `relevance` (default) or `date` (most recently modified first) - **since**: only return results modified since then: a period (`P7D`, `P1W`, `P3M`, `P1Y`) or a date (`2026-10-01`, included) ## Outputs - **results**: search hits, each with `type`, `id`, `title`, `description` (shortened), `severity`, `cvss_score`, `kev` (CVEs only), `source`, `published`, `modified`, and `url` - **facets**: number of records found for each `type` and `severity` - **total_results**, **total_pages**, **current_page**: use them to decide whether to ask for another `page` - **search_url**: link to continue the search on SecDB ## LLM usage guidelines - Use this tool instead of assuming whether a CVE/advisory/exploit exists. - If `total_results` is `null`, the query is not valid: fix its syntax. It does not mean that nothing was found. - Results are short: for the full record use `vulnerability_info`, `advisory_info`, or `cwe_info` with the `id` of the result. - Combine with `vulnerability_score`, `epss_timeseries`, or `sightings_search` for deeper analysis.

Run a public ZEN SecDB feed report. ## What this tool does Executes a predefined report on ZEN SecDB public feed data and returns structured results for analytics, trends, distributions, and top-N summaries. Supported reports can cover public datasets such as: - CVEs - security advisories - EPSS - weaknesses - CPE vendors and products - exploit references - sightings and IOC-related data Use `feed_report_catalog` to discover the list of available reports and their supported input parameters. ## When to use this tool Use this tool when the user asks about: - distributions, trends, or counts across public vulnerability data - top CVEs, top weaknesses, top vendors, or similar rankings - timeline-based summaries such as yearly or monthly trends - aggregated views over public SecDB feed data Do not use this tool when the user asks for details about a single CVE, advisory, or exploit. Use the dedicated lookup tools instead. ## Inputs - **report_id**: identifier of the report to execute - **filters**: optional object with report-specific filters - **limit**: optional maximum number of results to return, when supported by the selected report ## Outputs - **report_id**: executed report identifier - **filters**: applied filters - **data**: structured report rows or aggregated values ## LLM usage guidelines - Use `feed_report_catalog` when you need to discover which public reports are available or which parameters they support. - Do not guess report IDs-use the catalog when uncertain. - Use only the filters listed in the catalog: a report can ignore any other filter without an error, and return unfiltered data. - Use `data` for structured follow-up analysis, comparisons, or tool chaining. - If the selected report does not exist, return a clear not-found error instead of guessing an alternative.

List available public ZEN SecDB feed reports. ## What this tool does Returns the catalog of available ZEN SecDB public feed reports, including their identifiers, descriptions, and supported input parameters. This tool helps discover which reports can be executed through `feed_report`. ## When to use this tool Use this tool when: - the user asks what public reports are available - you need to discover the correct report ID before running a report - you need to inspect supported filters or input parameters - you are unsure which report best matches the user request ## Inputs This tool does not require any input. ## Outputs - **reports**: array of report definitions, each containing: - `report_id`: report identifier - `title`: human-readable report title - `description`: short explanation of what the report returns - `input_schema`: optional JSON schema describing supported input parameters ## LLM usage guidelines - Use this tool before `feed_report` whenever the correct report ID or supported parameters are not already known. - Do not invent report IDs or parameters not present in the catalog. - Prefer the most specific matching report for the user request. - When useful, briefly summarize the most relevant available reports before calling `feed_report`.

Check whether one or more CVEs are listed in the CISA KEV or EU KEV catalogs of known exploited vulnerabilities. ## What this tool does For each CVE, returns whether it is in a KEV catalog and, if so, the dates, the known use in ransomware campaigns, and the threat actors reported by the EU catalog. ## When to use this tool Use this tool when the user asks: - "Is this CVE in CISA KEV?" - "Which of these CVEs are known to be exploited?" - to prioritize a list of CVEs For a single CVE, this is lighter than `vulnerability_info`. To find the entries of a catalog by date, vendor, or product, use `kev_list`. ## Inputs - **cve_ids**: list of CVE identifiers (`CVE-YYYY-NNNNN`), up to 100. ## Outputs - **results**: one object for each CVE, containing: - `cve_id` - `in_kev`: whether the CVE is in at least one KEV catalog - when `in_kev` is true: `in_cisa`, `in_eu`, `vendor`, `product`, `vulnerability_name`, `ransomware`, `cisa_added_date`, `cisa_due_date`, `eu_reported_date`, `euvd_id`, `eu_exploitation_type`, `eu_threat_actors_exploiting` ## LLM usage guidelines - Send all the CVEs in one call instead of calling the tool once per CVE. - `in_kev: false` means that the CVE is not in these catalogs, not that it is not exploited: use `sightings_search` for other evidence. - `in_kev: false` does not confirm that the CVE exists: use `vulnerability_score` or `vulnerability_info` to check it.

List the entries of the CISA KEV and EU KEV catalogs of known exploited vulnerabilities, most recent first. ## What this tool does Returns the CVEs in the catalogs, filtered by listing date, catalog, vendor, product, and known use in ransomware campaigns. ## When to use this tool Use this tool when the user asks: - "What was added to KEV this week?" - "Which Fortinet vulnerabilities are known to be exploited?" - "Which KEV entries are used in ransomware campaigns?" To check CVEs that you already know, use `kev_check`. ## Inputs - **since**: only return entries listed since then: a period (`P7D`, `P1W`, `P3M`, `P1Y`) or a date (`2026-10-01`, included). - **catalog**: `cisa` or `eu` (default: both). It also selects the date used by `since` and by the order of the results. - **vendor**: part of the vendor name, for example `fortinet`. - **product**: part of the product name, for example `fortios`. - **ransomware**: `true` to only return entries with known use in ransomware campaigns, `false` for the others. - **limit**: maximum number of entries to return (default 25, maximum 100). - **page**: page of results to return (default 1). ## Outputs - **total_results**, **total_pages**, **current_page** - **entries**: each with `cve_id`, `in_cisa`, `in_eu`, `vendor`, `product`, `vulnerability_name`, `ransomware`, `first_listed_date`, `first_listed_by`, `cisa_added_date`, `cisa_due_date`, `eu_reported_date` ## LLM usage guidelines - Without `catalog`, `since` uses `first_listed_date`: a CVE already in CISA KEV that has just been added to EU KEV does not appear. To see the recent entries of a catalog, set `catalog`. - When `total_results` is greater than the returned entries, say so before drawing conclusions. - An empty list does not mean that nothing is exploited: the catalogs only contain confirmed cases. Use `sightings_search` for other evidence. - For the score of the CVEs, use `vulnerability_score`.

Perform a Linux package vulnerability audit using SecDB. ## What this tool does Analyzes the installed packages of a Linux system-identified by OS and OS version-and returns vulnerability information plus a Markdown summary. The audit results are based exclusively on the package list provided by the user. ## When to use this tool Use this tool when the user wants to determine: - whether installed packages contain known vulnerabilities - whether a host, VM, container, or base image is affected by security advisories - which packages require patching or upgrading If the user does not know the valid values for `os` or `version`, first call the `linux_os` tool to retrieve the exact supported combinations. ## Inputs - **os**: Linux distribution identifier supported by SecDB (use `linux_os` to obtain allowed values). - **version**: OS version or codename corresponding to the selected distribution, exactly as returned by `linux_os` (for example `focal`, not `20.04`). Any other value is rejected with the list of supported values. - **packages**: list of installed packages, **one per line**, generated using the appropriate system command: ### For RPM-based distributions (RHEL, CentOS, Rocky, Alma, SUSE) rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' ### For DEB-based distributions (Ubuntu, Debian) dpkg-query -W -f='${Package} ${Version} ${Architecture}\n' ### For Alpine Linux apk list -I ### For Slackware ls -1 /var/log/packages/ The raw output of these commands can be passed directly as the `packages` input (one package per line). ... python3 3.12.3-0ubuntu2.1 amd64 systemd 255.4-1ubuntu8.10 amd64 tmux 3.4-1ubuntu0.1 amd64 ... ## Outputs - **report**: structured objects describing the advisories affecting the audited packages. Packages without known vulnerabilities are not listed. - **summary**: Markdown summary including vulnerable packages, total CVEs, and severity breakdown. ## LLM usage guidelines - Never guess whether a package is vulnerable-always call this tool for Linux audits. - If `os` or `version` is unclear or missing, call `linux_os` and ask the user to choose a valid combination. - Normalize the package list to “one entry per line” if the user provides unstructured output. - The `summary` is already Markdown and can be shown directly. - Use `report` when deeper technical analysis is required.

List supported Linux operating systems and their corresponding versions for use with the `linux_audit` tool. ## What this tool does Returns the supported OS/version pairs in `supported`, each in the form: {"os":"name", "versions":["version or codename"]} This allows the LLM and the user to know exactly which inputs are valid for the `linux_audit` tool. ## When to use this tool Use this tool when: - the user does not know which OS names or versions are supported - the user provides unclear or ambiguous OS information - you need to validate `os`/`version` before performing a Linux audit This tool should typically be called **before `linux_audit`** whenever parameters are uncertain. ## Inputs This tool does not require any input. ## Outputs - **supported**: array of objects, each containing: - **os**: supported Linux distribution identifier - **versions**: corresponding list of supported release or codename Example: { "supported": [ {"os": "ubuntu", "versions": ["noble","focal"]}, {"os": "debian", "versions": ["bookworm","sid"]}, {"os": "redhat", "versions": ["redhat-9.0"]} ] } ## LLM usage guidelines - Use this tool to validate or suggest correct OS/version combinations before calling `linux_audit`. - If the user provides invalid or misspelled OS names, retrieve the official list here and ask them to select one. - Do not guess operating system identifiers-always rely on this tool to confirm correctness.

Get detailed information about a specific security advisory. ## What this tool does Retrieves a security advisory (for example RHSA, DSA, USN, GHSA) from SecDB, including title, publication date, severity, summary, description, linked CVEs, CVSS metrics, weaknesses, and the affected and fixed packages and products. ## When to use this tool Use this tool when the user asks: - "Give me details about RHSA-2026:1234." - "Which CVEs are fixed by this advisory?" - "Which package versions are affected, and which version fixes them?" For a CVE, use `vulnerability_info`. If the exact advisory ID is not known, use `vulnerability_search` with `type` set to `advisory`. ## Inputs - **advisory_id**: exact advisory identifier (e.g. `RHSA-2026:1234`, `GHSA-xxxx-xxxx-xxxx`). ## Outputs - **advisory_id**, **url** (page on SecDB), **source**, **source_url** (original advisory), **title**, **summary**, **description**, **solution**, **severity**, **published**, **modified**, **rights** - **cves**: identifiers of the linked CVEs. Use `vulnerability_info`, `vulnerability_score`, or `kev_check` for their details - **cvss**: one entry for each CVSS version available, with `version`, `score`, `severity`, and `vector` - **cwe**: each with `id`, `name`, and `url` - **packages**: each with `purl`, `status` (for example `affected` or `fixed`), `vers` (versions as a VERS range, for example `vers:maven/>=2.0.0|<2.0.11`), and `remediation`. It is `null` when the packages could not be read, which does not mean that no package is affected - **products**: each with `vendor`, `product`, `version`, `fixed_in`, `status`, `text`, `cpe22`, and `cpe23` - **tags**, **impacts** Fields that SecDB does not have for the advisory are `null` or empty. ## LLM usage guidelines - Do not guess advisory IDs: use the IDs returned by other tools or provided by the user. - If the advisory is not found, try `vulnerability_search` before saying that it does not exist. - An advisory can list packages of other projects that include the vulnerable code: check `purl` before saying that a package is affected. - Some advisories list thousands of packages or products, so the response can be very large.

Find the CPE vendor and product names that SecDB uses for a product, with the number of CVEs of each one. ## What this tool does Searches the vendor and product names in the CPE configurations of the CVEs, marked as vulnerable. Every result can be passed to `product_vulnerabilities`. Results go from the most to the least CVEs. ## When to use this tool Use this tool when the user asks: - "What is the CPE name of Apache HTTP Server?" - "Which Fortinet products have known CVEs?" Use it before `product_vulnerabilities` when the exact names are not known. For open source dependencies, use `purl_audit`. ## Inputs - **query**: words to search in the vendor and product names, for example `apache http server`. Every word must match the vendor or the product. - **vendor**: exact CPE vendor name, to search only its products. - **part**: `a` (application), `o` (operating system), or `h` (hardware). - **limit**: maximum number of results to return (default 25, maximum 100). - **page**: page of results to return (default 1). ## Outputs - **total_results**, **total_pages**, **current_page** - **results**: each with `vendor`, `product`, `parts`, `cve_count` - **note**: present when nothing matches ## LLM usage guidelines - When several products match, show them to the user or use the closest one and say which one you chose. Do not merge them. - `cve_count` shows how many CVEs have the name, not how relevant it is. - No result does not mean that the product has no CVEs: try fewer or different words, or `vulnerability_search`.

Calculate the score of any CVSS vector string and explain it in natural language. ## What this tool does Takes a CVSS vector string, not tied to a specific CVE, and returns its version, base score, severity, and a human-readable explanation. ## When to use this tool Use this tool when the user: - provides a CVSS vector and asks what it means - wants to see how the score changes when a metric changes - has adjusted a vector for their own environment For the official CVSS of a CVE, use `vulnerability_score`. ## Inputs - **vector_string**: CVSS vector string, e.g. `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`. ## Outputs - `cvss_version` - `cvss_base_score` - `cvss_base_severity` - `cvss_vector_string` - `cvss_explain`: human-readable explanation of the vector ## LLM usage guidelines - Never calculate CVSS scores by hand: use this tool.

Get information about a specific weakness (CWE) and its related attack patterns (CAPEC). ## What this tool does Returns the name and description of a CWE, its type, the related CAPEC attack patterns, and the number of CVEs linked to it, with how many of them are in the CISA KEV and EU KEV catalogs. ## When to use this tool Use this tool when the user asks: - "What is CWE-79?" - "Which attack patterns are related to this weakness?" - "How often is this weakness exploited in the wild?" ## Inputs - **cwe_id**: CWE identifier (`CWE-79` or `79`). ## Outputs - `id`, `name`, `type`, `description` - `capec`: related attack patterns, each with `id` and `name` - `cve_count`: number of CVEs linked to this CWE - `cisa_kev_count`: how many of these CVEs are in the CISA KEV catalog - `eu_kev_count`: how many of these CVEs are in the EU KEV catalog - `kev_count`: how many of these CVEs are in at least one of the two catalogs - `url`: link to the CWE on SecDB ## LLM usage guidelines - Do not explain a CWE from memory when the user needs the official definition: use this tool. - Do not add `cisa_kev_count` and `eu_kev_count`: a CVE can be in both catalogs. Use `kev_count` for the total.

Get the historical EPSS time series for a specific CVE. ## What this tool does Returns the historical EPSS score, percentile, and model version available for a CVE across time, ordered by date. Useful for analyzing how exploitability likelihood has evolved over time. ## When to use this tool Use this tool when the user asks about: - EPSS trend over time - how exploitability probability changed - whether EPSS spiked or dropped - historical comparison of risk If the user only wants the current EPSS score, use `vulnerability_score` instead. ## Inputs - **cve_id**: valid CVE identifier (`CVE-YYYY-NNNNN`). - **days**: optional number of days of history to return, counting back from today (default 365, maximum 3650). ## Outputs - **series**: array of objects, each containing: - `date`: measurement date in ISO format - `score`: EPSS score, as a percentage (`94.36` means 94.36%) - `percentile`: EPSS percentile, as a percentage - `model`: EPSS model version ## LLM usage guidelines - Never guess EPSS values-use this tool for all EPSS time-series questions. - If `cve_id` is malformed or incomplete, ask the user to correct it before calling. - If the user mentions multiple CVEs, call the tool once per CVE as needed. - Request a longer `days` window only when the user needs it: a full history is very large. - If no historical data is available, the tool returns an empty series: state that no EPSS history was found.

List the security advisories known for a package, with the affected and fixed versions. ## What this tool does Returns the advisories of a package across all its versions, most recent first. This covers more ecosystems than `purl_audit`, for example `github`, `cpan`, `apache`, and `freebsd`. ## When to use this tool Use this tool when the user asks: - "Which vulnerabilities has this package had?" - "Which version fixes this vulnerability?" - "Which version should I upgrade to?" To check whether a specific version is vulnerable, use `purl_audit` or `linux_audit`: this tool does not evaluate versions. ## Inputs - **purl**: Package URL. The version is ignored. For Linux packages, add the `distro` qualifier to limit the results to one release, for example `pkg:deb/ubuntu/curl?distro=noble`. - **limit**: maximum number of advisories to return (default 25, maximum 100). - **page**: page of results to return (default 1). ## Outputs - **total_results**, **total_pages**, **current_page**: advisories for the package across all pages - **advisories**: each with `advisory_id`, `title`, `severity`, `published`, `cves`, `status`, `affected`, `fixed_versions` - **affected**: version ranges, each with `versions` and, for Linux packages, `distro` - **fixed_versions**: each with `version` and, for Linux packages, `distro`. A version is either reported as fixed by the advisory or the exclusive upper bound of an affected range ## LLM usage guidelines - When `total_results` is 0, say that SecDB has no advisories for this package name, not that the package is safe. Names must match exactly. - To recommend an upgrade, consider all the advisories and check the resulting version with `purl_audit` when its ecosystem is supported. - `status` can include `malicious`: tell the user to remove the package instead of upgrading it. - If `fixed_versions` is empty, say that no fix is known. Do not guess a version.

List the CVEs of a product by its CPE vendor and product names, with the affected version ranges. ## What this tool does Returns the CVEs whose CPE configuration marks the product as vulnerable, most recent first. Use it for assets that have no Package URL, such as appliances, operating systems, and commercial software. ## When to use this tool Use this tool when the user asks: - "Which CVEs affect FortiOS?" - "What are the latest vulnerabilities of this product?" - "Is this product version affected by a known CVE?" For open source dependencies, use `purl_audit`. If the CPE names are not known, use `cpe_search` first. ## Inputs - **vendor**: CPE vendor name, for example `fortinet`. - **product**: CPE product name, for example `fortios`. - **limit**: maximum number of CVEs to return (default 25, maximum 100). - **page**: page of results to return (default 1). ## Outputs - **total_results**, **total_pages**, **current_page**: CVEs for the product across all pages - **cves**: each with `cve_id`, `published`, `severity`, `score`, `description`, `affected_versions` - **note**: present when no CVE matches ## LLM usage guidelines - This tool does not filter by version: compare the user's version with `affected_versions`, and say that the comparison is yours. An entry of `all` means that the configuration has no version limits. - When `total_results` is greater than the returned CVEs, say so before drawing conclusions about a version. - When `total_results` is 0, do not say that the product is safe: the vendor or product name may differ from the CPE one. Use `cpe_search` to find it.

Perform a software package vulnerability audit using SecDB. ## What this tool does Analyzes a list of software packages identified by PURL (Package URL) and returns vulnerability information plus a Markdown summary. The audit results are based exclusively on the package list provided. ## When to use this tool Use this tool when the user wants to determine: - whether application dependencies contain known vulnerabilities - whether a project is affected by security advisories - which packages require patching or upgrading ## Supported ecosystems - **npm** - Node.js packages (e.g. pkg:npm/[email protected]) - **maven** - Java/JVM packages (e.g. pkg:maven/org.apache.logging.log4j/[email protected]) - **pypi** - Python packages (e.g. pkg:pypi/[email protected]) - **gem** - Ruby gems (e.g. pkg:gem/[email protected]) - **cargo** - Rust crates (e.g. pkg:cargo/[email protected]) - **nuget** - .NET packages (e.g. pkg:nuget/[email protected]) - **golang** - Go modules (e.g. pkg:golang/github.com/gin-gonic/[email protected]) - **composer** - PHP packages (e.g. pkg:composer/symfony/[email protected]) - **pub** - Dart packages (e.g. pkg:pub/[email protected]) - **swift** - Swift packages (e.g. pkg:swift/github.com/apple/[email protected]) - **hex** - Erlang and Elixir packages (e.g. pkg:hex/[email protected]) ## Inputs - **purls**: list of Package URLs, one per entry. Generate them from your project manifest files: - Node.js: package.json / package-lock.json - Python: requirements.txt / Pipfile.lock / pyproject.toml - Ruby: Gemfile.lock - Go: go.mod / go.sum - Rust: Cargo.lock - PHP: composer.lock - Java: pom.xml / build.gradle - .NET: *.csproj / packages.lock.json ## Outputs - **report**: structured JSON objects describing the advisories affecting the audited packages. Packages without known vulnerabilities are not listed. - **summary**: Markdown summary including vulnerable packages, total CVEs, and severity breakdown. - **audited**: number of PURLs that were checked. - **ignored**: PURLs that were not checked because they are malformed or from an unsupported ecosystem. ## LLM usage guidelines - Never guess whether a package is vulnerable — always call this tool. - Only submit PURLs from the supported ecosystems listed above; others are returned in `ignored`. - Tell the user about any `ignored` PURL: they were not checked, so they are not known to be safe. - The `summary` is already Markdown and can be shown directly. - Use `report` when deeper technical analysis is required.

Search real-world vulnerability sightings in SecDB. ## What this tool does Retrieves information about where and how a vulnerability appears in the real world, including: - Exploit-DB references and PoCs - Scanner plugins (Nessus, OpenVAS/Greenbone) - Vendor advisories - Social/media references (Reddit, Mastodon, Bluesky) - MISP threat-intel sightings ## When to use this tool Use this tool when the user asks: - "Is this CVE exploited in the wild?" - "Is there a PoC or exploit available?" - "Does Nessus or OpenVAS have a plugin for this CVE?" - "Is this vulnerability being discussed online?" - "Show me all advisories/exploits for this CVE/product." ## Inputs Any of the following may be used: - **cve_id**: search by specific CVE - **query**: full-text search (name, product, advisory ID, exploit reference, etc.) - **category**: filter sightings by type (e.g., `exploit`, `nasl`, `advisory`, `scanner`, `poc`, `social`, `misp`) - **status**: filter by sighting state (`exploited`, `mitigated`, `seen`, `confirmed`, etc.) - **since**: only return sightings created since then: a period (`P7D`, `P1W`, `P3M`, `P1Y`) or a date (`2026-10-01`, included) - **limit**: maximum number of sightings to return (default 25, maximum 100) - **page**: page of results to return (default 1) ## Outputs - **sightings**: array of sightings, most recent first, typically containing: - `cve_id` - `status` - `category` - `reference` - `details` (object with additional structured data) - **total_results**, **total_pages**, **current_page**: use them to decide whether to ask for another `page` ## LLM usage guidelines - Use `cve_id` when the question targets a specific vulnerability. - Use `query` for broad or exploratory searches. - Only use valid enum values for `category` and `status`. - Use this tool instead of assuming exploitation, PoCs, or plugin availability. - Use `page` only when the user needs more than the first results. - For Metasploit modules, use `vulnerability_exploits`.

Compute CISA SSVC (Stakeholder-Specific Vulnerability Categorization) for a CVE. ## What this tool does Calculates the SSVC decision (Track, Track*, Attend, Act) using: - exploitation status - technical impact - automatable exploitation - mission prevalence (user-provided) - public well-being impact (user-provided) This reflects CISA's official SSVC prioritization model. ## When to use this tool Use this tool when the user asks about: - how urgently a CVE should be remediated - CISA SSVC priority or risk category - a structured decision model for remediation ## Inputs - **cve_id**: the vulnerability to evaluate (`CVE-YYYY-NNNNN`) - **mission_prevalence**: `M`, `S`, or `E` (must be provided by the user) - **public_well_being_impact**: `M`, `A`, or `I` (must be provided by the user) ## Outputs - `decision`: one of **Track**, **Track\***, **Attend**, **Act** - `exploitation` - `technical_impact` - `automatable` - `mission_prevalence` - `public_well_being_impact` - `mission_and_well_being_impact_value` - `vector_string` - `summary`: Markdown explanation of the outcome ## LLM usage guidelines - Always ask the user for **mission_prevalence** (M/S/E) and **public_well_being_impact** (M/A/I) before calling. - Never guess these values—SSVC depends on user context. - Use the `summary` to explain clearly why the decision was returned. - Combine with `vulnerability_score` or `sightings_search` if the user needs additional context.