VulnCheck für Wazuh-Vulnerabilities: Closed-Loop-Patch-Verifikation, dynamische Priorisierung und sichere Evaluierung eines Drittanbieter-Dashboards

von

Einleitung

Wazuh erkennt Schwachstellen zuverlässig, indem es Softwareinventar über Syscollector mit Vulnerability-Content korreliert. In vielen Umgebungen beginnt das eigentliche Problem aber erst danach: Wie werden Findings priorisiert, einem Owner zugewiesen, fristgerecht verfolgt, sauber dokumentiert und nach dem Patchen verifiziert – ohne dass das Team in Tabellenkalkulationen und manuellen Nachprüfungen versinkt?

In der Community wurde dafür ein neues, selbst gehostetes Open-Source-Tool vorgestellt: VulnCheck, ein Vulnerability-Management-Dashboard, das direkt mit Wazuh integriert und typische Workflow-Lücken schließen will. Gleichzeitig entstand sofort die richtige Diskussion: Supply-Chain-Risiko und Vertrauen bei Tools, die tief in Security-Infrastruktur greifen. Dieser Beitrag fasst die Technik zusammen und zeigt, wie man so ein Projekt fachlich korrekt und sicher evaluiert.

Ausgangslage / Problemstellung

In der Diskussion wurden typische Schmerzpunkte benannt:

  • Wazuh liefert CVE-Erkennung, aber kein vollwertiges Ticketing/Ownership/SLA-Tracking für Schwachstellen über Teams hinweg.
  • Manuelle Nachprüfung nach „Patch applied“ ist aufwendig und fehleranfällig.
  • Priorisierung nur nach CVSS erzeugt Rauschen und ignoriert Kontext wie Asset-Kritikalität oder Exploit-Verfügbarkeit.
  • Compliance erfordert Berichte und Audit-Trails.

VulnCheck adressiert das als separates Dashboard (Tech-Stack: Next.js, FastAPI, PostgreSQL, Docker Compose) und synchronisiert Assets/Vulnerabilities aus Wazuh. Laut Projektbeschreibung sind u. a. SLA-Policies, automatisierte Mail-Alerts, RBAC und Reporting enthalten.

Parallel wurde die Frage gestellt, wie man einem neuen Tool vertraut, das in kurzer Zeit veröffentlicht wurde und potenziell Zugriff auf SIEM/XDR-Daten und Automations bekommt. Die Antwort darauf ist nicht „blind vertrauen“ oder „pauschal ablehnen“, sondern: sauber isoliert testen, minimal berechtigen, nachvollziehbar verifizieren.

Technische Analyse

Wie Wazuh Vulnerabilities technisch entstehen

Wazuhs Vulnerability Detection basiert auf dem Inventar, das Agenten via Syscollector liefern. Der Server korreliert diese Inventory-Daten mit Vulnerability-Informationen und erzeugt daraus eine verwertbare Schwachstellen-„Inventory“-Sicht.

Damit sind zwei Dinge wichtig für jede externe „Vulnerability-Management“-Schicht:

  1. Sie muss sauber zwischen Vulnerability Events/States und Asset-Inventar unterscheiden.
  2. Sie sollte verstehen, dass „Patchen“ ohne erneute Inventarisierung eine Annahme bleibt. Genau hier setzt ein Closed-Loop an.

VulnCheck-Ansatz: Closed-Loop-Verifikation über Syscollector-Rescans

VulnCheck beschreibt als Kernfunktion eine automatisierte Verifikation: Wird eine Schwachstelle als „Patched“ markiert, triggert das Tool einen gezielten Rescan und bestätigt den Fix, bevor der Fall endgültig geschlossen wird.

Das ist konzeptionell sauber, weil Syscollector das Inventar als Quelle der Wahrheit aktualisiert. Wazuh dokumentiert die Syscollector-Inventardaten und deren Nutzung für Rules/Alerting – was die Grundlage für solche Workflows bildet.

Dynamische Priorisierung: CVSS + Exploit + Asset-Kritikalität + Alter

VulnCheck führt eine dynamische Formel ein und ergänzt CVSS um Exploit-Signale und Kritikalitätsfaktoren. Im README wird ein Score-Ansatz beschrieben, der Exploit-Verfügbarkeit und Asset-Criticality gewichtet und zusätzlich ein „Age Penalty“ berücksichtigt.

Das entspricht Best Practice im Vulnerability Management: CVSS allein ist selten ausreichend, weil Asset-Kontext und Exploit-Reife entscheidend sind, um echte Risiken von Rauschen zu trennen.

AI-Analyse: lokal oder Cloud – inklusive Ollama

Das Projekt bewirbt eine AI-gestützte CVE-Analyse mit Remediation-Hinweisen und listet mehrere Provider, darunter Ollama für lokale Inferenz. Außerdem findet sich ein konkreter Hinweis für den Docker-Betrieb mit Ollama auf dem Host (Base-URL via host.docker.internal).

Wichtig für den Betrieb: AI-Analyse darf nicht „heimlich“ Daten exfiltrieren. Ein lokaler Provider ist für viele Security-Teams deshalb attraktiv – allerdings muss man sauber dokumentieren, welche Daten an das Modell gehen und ob Prompts/Responses geloggt werden.

RBAC, Audit-Trail, Reporting als Compliance-Bausteine

VulnCheck beschreibt RBAC (Admin/Editor/Readonly), Audit-Logging und PDF/CSV-Reporting.
Das ist funktional plausibel: Genau diese Schicht fehlt häufig, wenn man Vulnerabilities zwar erkennt, aber nicht beweisbar managt.

Lösung / Best Practices

1) Drittanbieter-Tool sicher evaluieren: Vorgehen statt Bauchgefühl

Wenn ein Tool Zugriff auf Wazuh API, Indizes oder Active Response erhält, gilt es als supply-chain-relevant. Eine praxistaugliche Evaluation umfasst:

  • Isoliertes Lab: eigenes Testnetz, keine produktiven Tokens, keine produktiven SMTP-Relays.
  • Minimalrechte: eigener Wazuh-API-User nur mit den Endpunkten/Indizes, die für Read-Sync nötig sind; Write/Actions separat und erst später.
  • Netzwerk-Egress kontrollieren: standardmäßig „deny“, nur explizit benötigte Ziele erlauben. Das ist besonders wichtig, wenn AI-Provider konfigurierbar sind.
  • Container-Härtung: Images pinnen (Digest), keine „latest“-Tags, Read-only-Filesystem wo möglich, Secrets über Docker secrets/ENV nur in Runtime.
  • Reproduzierbarkeit: Build aus Source in eigener CI (statt fremde Prebuilt-Images blind zu übernehmen), Abhängigkeiten pinnen.
  • Telemetrie prüfen: welche Logs, welche Metriken, wohin werden sie geschrieben, gibt es externe Calls.

Dieses Vorgehen adressiert die Kernkritik aus der Diskussion: Vertrauen muss earned werden – und die Community kann helfen, indem sie reproduzierbare Checks teilt, statt nur „sicher/unsicher“ zu rufen.

2) VulnCheck Quickstart in kontrollierter Form

Das Projekt ist Docker-Compose-basiert und beschreibt einen Quick Start inklusive .env und JWT-Secret.
Für Lab-Tests empfiehlt sich dabei:

  • .env ausschließlich mit Lab-Secrets, kein Reuse produktiver Passwörter
  • Wazuh-Verbindung zunächst nur lesend konfigurieren
  • SMTP/Alerts erst aktivieren, wenn Rate-Limits und Empfängerlisten klar sind

3) Closed-Loop-Verifikation richtig aufsetzen

Damit ein „Rescan zur Patch-Verifikation“ zuverlässig ist:

  • Syscollector muss auf den Agenten korrekt laufen und Inventar regelmäßig liefern.
  • Rescan-Trigger muss im Tool-Workflow klar als „Verification pending“ modelliert sein, damit man nicht „Patched“ mit „Verified“ verwechselt.
  • Timeout/Failure-Handling: Was passiert, wenn ein Rescan scheitert oder ein Agent offline ist? Der Status muss sich sauber zurückrollen lassen.

4) AI-Analyse sicher betreiben

Wenn AI-Analyse genutzt wird:

  • Standardmäßig lokal starten, z. B. über Ollama, um Datenabfluss auszuschließen.
  • Prompts/Responses als potenziell sensitive Daten behandeln: Logging begrenzen, Retention definieren.
  • Ergebnisse als „Assistenz“, nicht als „Autorität“: Remediation-Vorschläge müssen immer gegen Change-Policies und Asset-Owner-Freigaben laufen.

Lessons Learned / Best Practices

  • Wazuh liefert die Detektion – nachhaltige Remediation braucht Ownership, SLA, Audit und Reporting als eigene Schicht.
  • Closed-Loop-Verifikation über Inventar-Rescans reduziert False-Closure und macht Compliance-Audits belastbarer.
  • Dynamische Priorisierung ist Pflicht: CVSS ohne Kontext führt zu Backlog-Explosion.
  • Bei neuen Tools ist die Sicherheitsdiskussion kein Störgeräusch, sondern Teil des Produktreifeprozesses: Lab, Minimalrechte, Reproduzierbarkeit und Egress-Kontrolle sind die Baseline.
  • Self-hosted und Open Source sind gute Voraussetzungen, ersetzen aber keine operative Due Diligence.

Fazit

VulnCheck adressiert ein reales Praxisproblem: Zwischen „Wazuh erkennt CVEs“ und „Team hat nachweisbar gepatcht“ fehlt oft ein Workflow- und Compliance-Layer. Die im Projekt beschriebenen Funktionen – insbesondere Closed-Loop-Verifikation via Syscollector-Rescan, dynamisches Risiko-Scoring und RBAC/Audit – passen fachlich zu typischen Enterprise-Anforderungen.

Genauso berechtigt ist die Supply-Chain-Perspektive: Ein Tool, das in Security-Infrastruktur integriert, muss zuerst in einem isolierten Lab mit Minimalrechten und kontrolliertem Netzwerk-Egress bewiesen werden. Wer diese Evaluierungsdisziplin einhält, kann aus solchen Community-Projekten echten Mehrwert ziehen – ohne die eigene Sicherheitslinie zu verwässern.

Quellen (Copy & Paste)

https://gitea.isuit.ch/vulncheck/vulncheck
https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/how-it-works.html
https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/index.html
https://documentation.wazuh.com/current/user-manual/capabilities/system-inventory/using-syscollector-information-to-trigger-alerts.html

Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

https://wazuh.slack.com/archives/C0A933R8E/p1770543752967769