Vulnerability Registry MCP Server

Autor: Or Cohen

Ein MCP-Server (Model Context Protocol), der eine Legacy-Schwachstellendatenbank kapselt und sie als Tools für jeden MCP-kompatiblen LLM-Client verfügbar macht. Er wurde als intelligente Zugriffsschicht über benutzerdefinierten, durch Pipes getrennten Datendateien entwickelt und ermöglicht es Sicherheitsanalysten, Schwachstellen mithilfe natürlicher Sprache abzufragen.

Schnellstart

Voraussetzungen

• Node.js 18+

• Claude Desktop (oder ein beliebiger MCP-kompatibler Client)

Einrichtung

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

Verbindung zu Claude Desktop

Fügen Sie dies zur Konfiguration von Claude Desktop hinzu (%APPDATA%\Claude\claude_desktop_config.json unter Windows, ~/Library/Application Support/Claude/claude_desktop_config.json unter macOS):

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

Ersetzen Sie <FULL_PATH> durch den absoluten Pfad zum geklonten Repository.

Starten Sie Claude Desktop neu und fragen Sie dann:

"Welche MCP-Tools hast du für Schwachstellen?"

Claude Desktop erkennt alle 6 Schwachstellen-Registry-Tools

Verfügbare Tools

Beispielabfragen

"Wie viele kritische Schwachstellen sind noch offen?"

Verwendet search_vulnerabilities mit severity: "critical" und status: "open".

"Was ist der CVSS-Score von Log4Shell?"

Verwendet get_vulnerability mit cve_id: "CVE-2021-44228".

"Zeige mir das Risikoprofil für Microsoft"

Verwendet get_vendor_risk_summary mit vendor_id: "V1".

"Welche Schwachstellen wurden im Linux Kernel nach 2022 gefunden?"

Diese Abfrage demonstriert die Multi-Tool-Orchestrierung — Claude ruft zuerst list_vendors auf, um "Linux Kernel" in die Anbieter-ID V5 aufzulösen, und ruft dann search_vulnerabilities mit vendor_id: "V5" und published_after: "2022-01-01" auf.

Architektur

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

Die Codebasis folgt einer strikten Drei-Schichten-Trennung:

• parser.ts — Liest das benutzerdefinierte, durch Pipes getrennte Format dynamisch. Weiß nichts über MCP.

• repository.ts — In-Memory-Datenspeicher mit indizierten Maps für O(1)-Lookups. Weiß nichts über MCP.

• tools.ts — Registriert MCP-Tools unter Verwendung der High-Level McpServer-API. Übersetzt zwischen MCP und dem Repository.

Das bedeutet, dass der Austausch der Datenquelle (Dateien → Datenbank) nur Änderungen an parser.ts erfordert, ohne Änderungen an der MCP-Schicht.

Designentscheidungen

Dynamisches Metadaten-Parsing — Der Datei-Parser liest Spaltennamen zur Laufzeit aus dem # FORMAT:-Header, anstatt Feldpositionen fest zu kodieren. In Kombination mit der Versionsprüfung (# VERSION: 1.0) stellt dies sicher, dass der Server Formatänderungen erkennen und warnen kann, ohne den Code zu ändern.

Repository-Muster mit In-Memory-Indizierung — Daten werden beim Start einmal geladen und in mehrere Maps indiziert (vendorById, vulnByCveId, vulnsByVendor, vulnsBySeverity, vulnsByStatus). Primäre Lookups sind O(1). Gefilterte Suchen starten bei der kleinsten indizierten Teilmenge und schneiden sich, was kombinierte Abfragen auch bei großen Datenmengen effizient macht.

High-Level McpServer API — Verwendet McpServer.registerTool() mit Zod-Schemas für typsichere Eingabevalidierung, anstatt der Low-Level Server-Klasse mit manuellen JSON-Schema-Definitionen und Request-Routing.

Flexible Suche mit optionalen Filtern — search_vulnerabilities akzeptiert alle Parameter als optional, was jede Kombination ermöglicht. Ein Tool verarbeitet Abfragen von "zeige alle kritischen" bis "finde Linux-CVEs von 2023 mit CVSS über 8". Die Ergebnisse werden immer nach CVSS-Score sortiert (höchster zuerst), sodass die schwerwiegendsten Probleme zuerst erscheinen.

Angereicherte Antworten — get_vulnerability gibt das vollständige Anbieterobjekt zusammen mit den CVE-Daten zurück. get_vendor_risk_summary enthält die Liste der offenen Schwachstellen. Dies reduziert die Anzahl der Tool-Aufrufe, die das LLM benötigt, um häufige Fragen zu beantworten.

Strikte Typsicherheit — Severity und Status sind Union-Typen, die von as const-Arrays abgeleitet sind, mit Laufzeit-Typ-Guards (isSeverity, isStatus). Dieselben Single-Source-of-Truth-Arrays speisen sowohl TypeScript-Typen als auch Zod-Enum-Validatoren.

Bekannte Datenanomalien

Bei der Arbeit mit den Quelldatendateien habe ich mindestens eine Inkonsistenz bei der Zuordnung identifiziert: CVE-2024-21762 (Fortinet SSL VPN OOB) ist in vulnerabilities.db dem Anbieter V4 (Google) zugeordnet, obwohl es sich um eine Fortinet-Schwachstelle handelt. Der Server gibt die Daten getreu so zurück, wie sie gespeichert sind — die Korrektur von Quelldaten liegt außerhalb des Zuständigkeitsbereichs einer schreibgeschützten Abfrageschicht. In einem Produktionssystem würde ich beim Laden einen Datenvalidierungsschritt hinzufügen, um solche Inkonsistenzen für eine menschliche Überprüfung zu kennzeichnen, möglicherweise durch einen Abgleich mit der NVD-API für eine kanonische Anbieterzuordnung.

Was ich bei mehr Zeit bauen würde

• SQLite/PostgreSQL-Persistenz — Ersetzen des In-Memory-Speichers für Datensätze, die den verfügbaren RAM überschreiten, mit Verbindungspooling für gleichzeitigen Zugriff.

• Paginierung — Hinzufügen von limit/offset-Parametern zu search_vulnerabilities für große Ergebnismengen.

• Fuzzy-Textsuche — Levenshtein-Distanz-Abgleich bei Schwachstellentiteln für fehlertolerante Abfragen.

• NVD-API-Integration — Automatische CVE-Datenaktualisierungen aus der National Vulnerability Database von NIST.

• MCP-Ressourcen — Bereitstellung von Rohdatendateien als MCP-Ressourcen für den direkten LLM-Zugriff, wenn Volltextkontext benötigt wird.

• Strukturiertes Logging & Observability — JSON-formatierte Logs mit Korrelations-IDs zum Debuggen von Tool-Aufrufketten.

• Authentifizierung & Ratenbegrenzung — Schutz des Servers in gemeinsam genutzten Bereitstellungsszenarien.

• CI/CD-Pipeline — GitHub Actions, die bei jedem Push Linting, Typ-Prüfungen und Tests ausführen.

Tech-Stack

Testen

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