漏洞注册表 MCP 服务器

作者：Or Cohen

一个 MCP（模型上下文协议）服务器，它封装了一个遗留漏洞数据库，并将其作为工具暴露给任何兼容 MCP 的 LLM 客户端。它构建在自定义管道分隔数据文件之上的智能访问层，使安全分析师能够使用自然语言查询漏洞。

快速入门

先决条件

• Node.js 18+

• Claude Desktop（或任何兼容 MCP 的客户端）

设置

git clone https://github.com/orcohen5/vulnerability-registry.git
cd vulnerability-registry
npm install
npm run build

连接到 Claude Desktop

添加到您的 Claude Desktop 配置中（Windows 上为 %APPDATA%\Claude\claude_desktop_config.json，macOS 上为 ~/Library/Application Support/Claude/claude_desktop_config.json）：

{
  "mcpServers": {
    "vulnerability-registry": {
      "command": "node",
      "args": [
        "<FULL_PATH>/vulnerability-registry/dist/index.js",
        "<FULL_PATH>/vulnerability-registry/data"
      ]
    }
  }
}

将 <FULL_PATH> 替换为克隆仓库的绝对路径。

重启 Claude Desktop，然后询问：

“你有哪些用于漏洞查询的 MCP 工具？”

Claude Desktop 发现了所有 6 个漏洞注册表工具

可用工具

示例查询

“有多少严重漏洞仍未修复？”

使用 search_vulnerabilities，参数为 severity: "critical" 和 status: "open"。

“Log4Shell 的 CVSS 评分是多少？”

使用 get_vulnerability，参数为 cve_id: "CVE-2021-44228"。

“向我展示微软的风险概况”

使用 get_vendor_risk_summary，参数为 vendor_id: "V1"。

“2022 年之后在 Linux Kernel 中发现了哪些漏洞？”

此查询演示了多工具编排 — Claude 首先调用 list_vendors 将“Linux Kernel”解析为供应商 ID V5，然后使用 vendor_id: "V5" 和 published_after: "2022-01-01" 调用 search_vulnerabilities。

架构

┌─────────────────┐     ┌──────────────┐     ┌──────────────┐
│  Claude Desktop │────▶│  MCP Server  │────▶│  Data Files  │
│  (MCP Client)   │◀────│  (stdio)     │◀────│  (.db)       │
└─────────────────┘     └──────┬───────┘     └──────────────┘
                               │
                    ┌──────────┼──────────┐
                    ▼          ▼          ▼
               tools.ts   repository.ts  parser.ts
              (MCP layer)  (query engine) (file reader)

代码库遵循严格的三层分离原则：

• parser.ts — 动态读取自定义管道分隔格式。对 MCP 一无所知。

• repository.ts — 带有索引 Map 的内存数据存储，用于 O(1) 查找。对 MCP 一无所知。

• tools.ts — 使用高级 McpServer API 注册 MCP 工具。在 MCP 和存储库之间进行转换。

这意味着更换数据源（文件 → 数据库）只需更改 parser.ts，而无需对 MCP 层进行任何更改。

设计决策

动态元数据解析 — 文件解析器在运行时从 # FORMAT: 头部读取列名，而不是硬编码字段位置。结合版本检查 (# VERSION: 1.0)，这确保了服务器可以在不修改代码的情况下检测并警告格式更改。

带有内存索引的存储库模式 — 数据在启动时加载一次，并索引到多个 Map 中 (vendorById, vulnByCveId, vulnsByVendor, vulnsBySeverity, vulnsByStatus)。主要查找操作为 O(1)。过滤搜索从最小的索引子集开始并进行交集运算，即使在大规模数据下也能使组合查询保持高效。

高级 McpServer API — 使用带有 Zod 模式的 McpServer.registerTool() 进行类型安全的输入验证，而不是使用带有手动 JSON Schema 定义和请求路由的低级 Server 类。

带有可选过滤器的灵活搜索 — search_vulnerabilities 接受所有参数作为可选参数，允许任意组合。一个工具即可处理从“显示所有严重漏洞”到“查找 2023 年 CVSS 高于 8 的 Linux CVE”等各种查询。结果始终按 CVSS 评分排序（最高分优先），以便最严重的问题首先显示。

丰富的响应 — get_vulnerability 在返回 CVE 数据时会同时返回完整的供应商对象。get_vendor_risk_summary 包含未修复漏洞的列表。这减少了 LLM 回答常见问题所需的工具调用次数。

严格的类型安全 — Severity 和 Status 是派生自 as const 数组的联合类型，并带有运行时类型保护 (isSeverity, isStatus)。相同的真值数组同时为 TypeScript 类型和 Zod 枚举验证器提供支持。

已知数据异常

在使用源数据文件时，我发现至少存在一个归属不一致问题： CVE-2024-21762 (Fortinet SSL VPN OOB) 在 vulnerabilities.db 中被映射到供应商 V4 (Google)， 尽管这是一个 Fortinet 的漏洞。服务器忠实地返回存储的数据 — 纠正源数据超出了只读查询层的范围。在生产系统中， 我会在加载时添加一个数据验证步骤，以标记此类不一致之处供人工审查， 例如通过交叉引用 NVD API 来获取规范的供应商归属。

如果有更多时间我会构建的功能

• SQLite/PostgreSQL 持久化 — 对于超过可用 RAM 的数据集，替换内存存储，并使用连接池进行并发访问。

• 分页 — 为 search_vulnerabilities 添加 limit/offset 参数，以处理大型结果集。

• 模糊文本搜索 — 对漏洞标题进行 Levenshtein 距离匹配，以实现容错查询。

• NVD API 集成 — 从 NIST 的国家漏洞数据库自动更新 CVE 数据。

• MCP 资源 — 将原始数据文件作为 MCP 资源暴露，以便在需要全文上下文时供 LLM 直接访问。

• 结构化日志记录与可观测性 — 带有相关 ID 的 JSON 格式日志，用于调试工具调用链。

• 身份验证与速率限制 — 在共享部署场景中保护服务器。

• CI/CD 流水线 — GitHub Actions 在每次推送时运行 lint、类型检查和测试。

技术栈

测试

npm test        # Run all tests (30 tests across parser + repository)
npm run build   # Compile TypeScript
npm start       # Start the MCP server (stdio mode)