Skip to main content
The Vulnerabilities view shows OS-level CVEs from the National Vulnerability Database (NVD) matched against the packages installed on each managed host. Luumen takes the OS version, installed system packages, and Python dependencies reported by the agent, compares them against the NVD, and surfaces matching CVEs with the list of affected hosts.

How matching works

For each managed host, the agent reports:
  • OS family and version (e.g., RHEL 8.6, SLES 15 SP4, Windows Server 2019).
  • System packages with versions (curl 7.81.0, openssh-server 8.0p1, etc.) from the native package manager.
  • Python dependencies with versions, when relevant.
Luumen cross-references each of these against the NVD. A CVE matches when the affected product and version range from the CVE description overlap with what the host has installed.

Triage flow

Open System Alerts → Vulnerabilities to see the active list.
  • Active lists CVEs matched to at least one host in your fleet.
  • Resolved includes vulnerabilities auto-resolved because no host matches, plus any manually resolved.
Each row shows:
FieldDescription
SeverityCritical, High, Medium, Low — based on the CVE’s CVSS score.
NameShort description, e.g., “OpenSLP as used in ESXi and the Horizon…”
TagsCategorization (PrivilegedEscalation, RCE, DoS, BufferOverflow, etc.).
Exploit statusWhether a public exploit exists (Analyzed, Modified, Deferred).
Days openDays since the CVE was first detected as relevant to your environment.
HostsCount of hosts in your fleet that match.
Click into a vulnerability to see the affected packages, the affected hosts, and the recommended remediation (typically a package upgrade to a specific version or higher).

Auto-resolution

CVEs are auto-resolved when no host in your fleet matches the affected product and version range. This keeps the active list focused on what actually applies to you. After remediating a CVE (e.g., patching curl to a fixed version), the next agent run captures the new package version. The CVE no longer matches and moves to Resolved automatically. There’s no manual “mark as resolved” step required for a real fix — though one is available for cases where the fix doesn’t fit cleanly into a package version (e.g., a configuration mitigation).

Why a vulnerability might be missing

The matching engine needs OS version and package data. If either is missing on a host, no CVE will match against it. The two common causes:
  • OS Packages and/or Python Packages not collected. The agent didn’t successfully enumerate packages on the host. This typically means a connectivity or permissions issue — see Verifying capture.
  • OS version not reported. Without a known OS, version-specific CVEs can’t be evaluated.
The diagnostic flow is documented under Vulnerabilities troubleshooting.

Relationship to terminal-driven scanning

Luumen also offers a terminal-driven vulnerability scan: a manual, on-demand scan triggered while connected to a host. That scan covers the same NVD data but runs outside the agent schedule and is useful for one-off validation after applying a patch. The agent-driven view documented on this page is the continuous view — every managed host is re-scanned on every agent run, and the dashboard reflects the latest state without anyone triggering anything.

What’s not covered

A few intentional limits:
  • Software not visible to the agent. If a binary was installed outside the package manager (e.g., copied into /opt), the agent doesn’t see it and NVD can’t match against it. Track those installs separately or move them into managed packages.
  • Misconfigurations that aren’t CVEs. A weak SSH cipher suite or an exposed admin port isn’t an NVD entry — use compliance checks for those. See Creating checks.
  • Zero-day awareness. Luumen reflects NVD’s view of the world. CVEs not yet in NVD (or in pre-disclosure) won’t show up until they’re published.