ZEN SecDB MCP Server

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) - EPSS metadata (if present) - affected products and versions - vendor/security advisories - references and upstream sources - weakness classification (CWE) - exploit and patch information (if included in the record) All information is returned in a structured Markdown format suitable for direct display. ## 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 Markdown-formatted vulnerability information including: - detailed description - severity metrics (CVSS, vectors) - affected products list - advisory list - references - weakness (CWE) details - additional structured metadata from SecDB ## 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 enrich output with numerical CVSS/EPSS metrics - **`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 a specific CVE. ## 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 - **cve_id**: valid CVE identifier (`CVE-YYYY-NNNNN`). ## Outputs - `cvss_version` - `cvss_base_score` - `cvss_base_severity` - `cvss_vector_string` - `cvss_explain` - human-readable explanation of the CVSS vector - `epss_score` ## LLM usage guidelines - Never guess CVSS or EPSS values—always call this tool. - Use the `cvss_explain` field directly when the user wants an interpretation of the vector string. - If multiple CVEs are referenced, call the tool once per CVE. - 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 Results are formatted in Markdown and include a search summary. ## 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.) ## Outputs - **results**: array of Markdown-formatted search hits - **summary**: Markdown summary with counts and a link to continue searching on SecDB ## LLM usage guidelines - Use this tool instead of assuming whether a CVE/advisory/exploit exists. - Present `results` and `summary` directly to the user-they are already Markdown. - 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 - **summary**: Optional Markdown summary of the report results - **report**: structured JSON object containing: - `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. - Present `summary` directly to the user-it is already Markdown. - Use `report` 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`.

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. - **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 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. - **summary**: Markdown summary including total vulnerabilities, severity breakdown, and key findings. ## 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 an array of supported OS/version pairs, 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 Returns an array of objects: - **os**: supported Linux distribution identifier - **versions**: corresponding list of supported release or codename Example: [ {"os": "ubuntu", "versions": ["noble","focal"]}, {"os": "debian", "versions": ["bookworm","sid"]}, {"os": "redhat", "version": ["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 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`). ## Outputs - **series**: array of objects, each containing: - `date`: measurement date in ISO format - `score`: EPSS score - `percentile`: EPSS percentile - `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. - If no historical data is available, return an empty series and state that no EPSS history was found.

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]) ## 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. - **summary**: Markdown summary including total vulnerabilities, severity breakdown, and key findings. ## LLM usage guidelines - Never guess whether a package is vulnerable — always call this tool. - Only submit PURLs from the supported ecosystems listed above; others will be ignored. - 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, Metasploit modules, 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.) ## Outputs Returns an array of sightings, typically containing: - `cve_id` - `status` - `category` - `reference` - `details` (object with additional structured data) ## 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.

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.