Nessus is one of the most widely deployed vulnerability scanners on the planet. It is also, by default, one of the best tools for generating a queue of findings that no team can realistically work through. A mid-sized environment of 500 hosts will routinely produce 6,000 to 12,000 plugin findings per scan. Sorted by plugin severity, the top of that list is populated by theoretical vulnerabilities that threat actors have never bothered to exploit alongside genuinely urgent issues. They look the same.
The problem is not Nessus. Nessus is doing exactly what it is designed to do: find everything detectable on your network and report it with a severity derived from the underlying CVSS score. The problem is treating that severity as a remediation priority. It is not. It is a data attribute. Turning it into a priority requires enrichment, context, and an explicit scoring model.
What a Nessus XML Export Actually Contains
When you export a Nessus scan to XML (.nessus format), you get a structured document built around ReportHost and ReportItem elements. Each ReportItem represents one plugin firing on one host. Key attributes you care about:
- pluginID: Tenable's internal identifier for the detection plugin
- pluginName: Human-readable description (e.g., "Apache HTTP Server 2.4.x < 2.4.54 Multiple Vulnerabilities")
- severity: 0–4 integer (0=Info, 1=Low, 2=Medium, 3=High, 4=Critical), derived from CVSS
- cvss3_base_score: The CVSS 3.x base score, when available
- cve: Associated CVE ID(s), comma-separated
- risk_factor: String version of severity (Critical, High, Medium, Low, None)
- plugin_output: Free-text output showing what the scanner actually observed on the host
- solution: Tenable's recommended remediation step
What it does not contain: EPSS scores, KEV status, exploitation history, asset criticality, or any signal about whether threat actors are actively using this vulnerability today. That gap is where most VM programs lose the plot.
severity=3 (High) may correspond to a CVE with CVSS 7.1 or CVSS 8.9, the bucket is wide. More critically, severity is set at plugin creation time and does not update when exploitation data changes. A CVE with CVSS 7.5 that entered the CISA KEV catalog last Tuesday still shows as severity=3 in Nessus output with no indication it is being actively exploited in ransomware campaigns right now.
The Enrichment Stack: EPSS and KEV
Two publicly available, free data sources radically change what you can do with Nessus output once you join them against the CVE IDs in your scan results.
EPSS (Exploit Prediction Scoring System)
EPSS is published daily by FIRST.org. Every CVE receives a probability score (0–1) representing the likelihood of exploitation in the wild in the next 30 days, based on a machine learning model trained on threat intelligence feeds, PoC publication signals, malware samples, and historical exploitation patterns. Approximately 96% of published CVEs have EPSS scores below 0.1. The CVEs above 0.5 deserve your immediate attention.
CISA KEV (Known Exploited Vulnerabilities)
The CISA KEV catalog is a confirmed exploitation signal. These CVEs are not predicted to be exploited; they are being exploited, right now, by real attackers, with enough evidence that CISA has formally catalogued them. The catalog grows by several entries per week. Any KEV entry in your Nessus results should bypass your normal triage queue and go directly to the top of the priority stack.
Why Plugin Severity Misleads: A Concrete Example
The table below shows ten findings from a representative Nessus scan of a financial services environment, sorted first by plugin severity (how Nessus would rank them), then re-ranked by the TRIS™ score (TRIS™) after EPSS and KEV enrichment.
| CVE | Nessus Severity | CVSS 3.x | EPSS | KEV | TRIS™ | TRIS™ Band |
|---|---|---|---|---|---|---|
| CVE-2021-44228 | Critical (4) | 10.0 | 0.97 | YES | 95 | CRITICAL |
| CVE-2023-46604 | Critical (4) | 10.0 | 0.91 | YES | 93 | CRITICAL |
| CVE-2024-21762 | High (3) | 9.8 | 0.78 | YES | 88 | CRITICAL |
| CVE-2024-3400 | Critical (4) | 10.0 | 0.94 | YES | 95 | CRITICAL |
| CVE-2023-20198 | Critical (4) | 10.0 | 0.88 | YES | 94 | CRITICAL |
| CVE-2024-0001 | Critical (4) | 9.8 | 0.003 | No | 38 | MEDIUM |
| CVE-2024-0002 | Critical (4) | 9.6 | 0.001 | No | 35 | MEDIUM |
| CVE-2023-0003 | High (3) | 8.8 | 0.002 | No | 29 | MEDIUM |
| CVE-2022-0004 | High (3) | 7.5 | 0.001 | No | 18 | LOW |
| CVE-2021-0005 | Medium (2) | 6.5 | 0.41 | No | 54 | HIGH |
The Medium-severity CVE at the bottom of the Nessus list, CVSS 6.5, plugin severity 2, has an EPSS of 0.41. That means FIRST's model gives it a 41% chance of exploitation in the next 30 days based on observed threat actor activity. It ranks above six "Critical" Nessus findings once EPSS enrichment is applied. Without enrichment, it would have been deprioritized for months.
The Ingestion and Scoring Workflow
Turning a Nessus export into a prioritized queue involves four steps:
- Parse the XML. Extract all
ReportItemelements, deduplicate by CVE ID, and map each finding to its host(s). One CVE affecting 40 hosts is still one CVE to remediate, the patch is the same. - Enrich with EPSS. Join CVE IDs against the FIRST EPSS daily CSV or API. Add the EPSS probability and percentile to each finding. Flag any CVE with EPSS delta (7-day change) above 0.2, these are accelerating.
- Check against KEV. Join CVE IDs against the CISA KEV JSON feed. Any match gets a hard priority override flag.
- Apply the TRIS™ score. Combine CVSS, EPSS, KEV status, your industry multiplier, and asset criticality into a single 0–95 score. Sort descending. Your queue is now in exploitation-risk order, not CVSS-severity order.
What to Do With Plugin Output That Lacks a CVE
Roughly 20–30% of Nessus plugin findings do not have an associated CVE. These include configuration issues, SSL certificate problems, weak cipher suites, and informational findings. These still matter, weak TLS configurations are exploited regularly without a CVE identifier, but they require a separate scoring framework based on CIS Benchmark controls or your own policy baselines rather than EPSS/KEV enrichment.
The practical approach is to handle them as a separate category: process CVE-linked findings through the EPSS/KEV/TRIS™ pipeline, and process non-CVE findings through a configuration compliance baseline. Do not mix the two queues. The scoring models are different, and merging them produces a ranking that is incoherent for both categories.
Making the Output Usable
A ranked queue is only useful if it maps to something an engineer can act on. Three things make vulnerability data usable:
- Grouped by remediation action, not by CVE. If 15 CVEs are fixed by the same Apache 2.4.58 upgrade, that is one remediation task, not 15 tickets. Group by required fix before you create work items.
- Linked to affected hosts. The engineer implementing the fix needs to know which 40 servers to touch. Host lists from the plugin output need to flow into the ticket.
- With an AI-generated remediation guide. The NVD description of a CVE is written for the researcher who found it, not the engineer patching it. A remediation guide that explains the affected component, the patch command, the verification step, and the rollback procedure dramatically reduces the time-to-patch.
Nessus is an excellent scanner. The output it produces is raw material. The teams that treat it as a finished product, sorting by plugin severity and working down the list, are spending enormous time patching low-risk theoretical vulnerabilities while genuinely dangerous exploitable CVEs sit in the middle of the queue unaddressed. Enrichment is not optional. It is the difference between a vulnerability management program that reduces breach risk and one that just generates reports.
CVEasy AI is a perpetual license, you pay once and run it indefinitely on your own hardware. There are no per-asset fees, no annual true-up, and no module gates. Import your Nessus output, get a ranked queue, and start patching the things that actually matter.