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.
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.
| Field | Description |
|---|---|
| Severity | Critical, High, Medium, Low — based on the CVE’s CVSS score. |
| Name | Short description, e.g., “OpenSLP as used in ESXi and the Horizon…” |
| Tags | Categorization (PrivilegedEscalation, RCE, DoS, BufferOverflow, etc.). |
| Exploit status | Whether a public exploit exists (Analyzed, Modified, Deferred). |
| Days open | Days since the CVE was first detected as relevant to your environment. |
| Hosts | Count of hosts in your fleet that match. |
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., patchingcurl 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 Packagesand/orPython Packagesnot 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.
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.