Published 2026-04-25 · 11 min read

How to triage CVE findings: critical, high, medium, and "ignore for now"

You ran a vulnerability scan on your homelab. It returned 800 findings. Now what? This is the practical triage guide nobody gave you — how to decide what to patch tonight, what fits in your normal patch cycle, and what you can defer indefinitely without losing sleep.

The triage problem

Every fleet scanner outputs a flat list ordered by CVSS score: criticals first, then highs, mediums, lows. That's a useful starting point but a terrible plan. CVSS 9.8s in software you don't run on the internet aren't the same as CVSS 7.5s in your reverse proxy. Treating them identically wastes evenings and creates patch-fatigue, which is how operators stop patching at all.

Real triage combines three signals: severity (how bad if exploited), exploitability (how likely is exploitation), and exposure (does this code actually reach attackers). Most fleet scanners surface only the first; you have to bring the second and third yourself. Here's how.

Signal 1: severity (CVSS)

The base CVSS 3.x score is the headline number. It comes from the vector — eight metrics describing attack vector, complexity, required privileges, user interaction, scope, and the C/I/A impact. The score buckets into:

• 9.0–10.0 critical — full compromise possible
• 7.0–8.9 high — significant compromise
• 4.0–6.9 medium — limited compromise or DoS
• 0.1–3.9 low — minor exposure

Two things to know about CVSS that the score itself hides:

1. The vector matters more than the score. A 9.8 with AV:N/AC:L/PR:N/UI:N (network, attacker needs nothing, no user click) is genuinely catastrophic. A 9.8 with AV:L/PR:H (local access required, attacker already has high privileges) is far less urgent. Read the vector.
2. Base scores don't model your environment. A scanner's "critical" finding on a service that's only bound to 127.0.0.1 isn't really critical for you. A scanner's "medium" on your internet-facing reverse proxy might be. CVSS doesn't know.

Signal 2: exploitability (KEV + EPSS)

Two databases turn "this is theoretically bad" into "this is actually being attacked":

KEV — Known Exploited Vulnerabilities

A US-CISA-maintained list of CVEs with confirmed in-the-wild exploitation. About 1% of all CVEs make the KEV catalogue, but those are the ones that actually compromise hosts. CISA mandates US federal agencies patch KEV-listed CVEs on fixed timelines (typically 7 to 21 days).

Triage rule: a CVE on the KEV list is a "patch this week" finding regardless of CVSS. A CVE not on KEV with CVSS 9.8 is "patch this month" — bad, but not currently being weaponised at scale.

EPSS — Exploit Prediction Scoring System

A FIRST.org probability (0.0 to 1.0) that a CVE will be exploited in the next 30 days. Computed from observable indicators: public exploit code, mentions in attacker tooling, references in threat-intel feeds. EPSS > 0.5 means "more likely than not to be exploited soon"; > 0.9 means "almost certain."

Triage rule: between two CVEs of equal CVSS, pick the one with higher EPSS. If both are below 0.05 (most CVEs are — exploit code never gets written), they can wait for the regular patch cycle.

Signal 3: exposure (your network and architecture)

The signal nobody publishes for you. Three filters:

Is the affected service reachable from the internet?

A CVE in nginx on your public-facing reverse proxy is materially worse than the same CVE in nginx sitting behind Tailscale on a host that only your VPN can reach. Same package, same version, vastly different blast radius.

Run ss -tulpn on each host (or let your scanner port-scan from outside) and tag findings by exposure class: public, lan-only, or localhost.

Is the affected service authenticated?

A CVE that requires authenticated access is mitigated almost entirely by an authenticating proxy in front. CVE-2024-3094 (the xz backdoor) ultimately required SSH login to trigger; hosts behind a key-only-no-passwords SSH config + IP allowlist were practically immune even on vulnerable versions.

What value does the host actually hold?

A compromise of your "Plex media server" is a different severity event than a compromise of your "secrets-vault Pi that holds the passphrase to your offsite backups." They might have the same CVE, but the consequence-of-failure is orders of magnitude apart.

The decision matrix

Combining the three signals:

Common triage anti-patterns

"Patch everything immediately"

Sounds responsible, isn't sustainable. You'll burn out within a quarter, then stop patching at all. Worse, every patch is a chance to break things — service interruptions caused by panicked patching cause more downtime than the CVEs they fixed would have.

"Sort by CVSS, work top-down"

Misses KEV-listed mediums (which DO get exploited) and wastes time on internet-facing-software CVEs that aren't actually internet-facing on your network.

"Ignore everything below critical"

Misses configuration drift and exposed-surface findings that no CVE will ever describe but that get hosts compromised every day.

"Wait for the distro to patch"

Often correct — distro maintainers are excellent. But for software outside the distro repos (Plex, Jellyfin, Grafana, Pi-hole, the *arr suite), nobody's patching for you.

What Noxen does

Noxen surfaces severity (CVSS bucket + numeric score) and package + fix-version per finding. It doesn't currently compute KEV/EPSS overlay or exposure-class tagging — those are on the post-launch roadmap. For now, the workflow is:

1. Open Noxen's morning report, filter to critical + high.
2. For each, paste the CVE ID into the KEV catalogue at cisa.gov/known-exploited-vulnerabilities-catalog and EPSS at first.org/epss. (~30 sec each.)
3. Match against your own knowledge of which hosts are public-facing.
4. Triage with the matrix above.

For a typical homelab finding count (5–30 critical+high across the fleet) this runs ~10 minutes weekly. The vast majority of findings will resolve on the next patch cycle — the matrix is mostly about deciding which 2 or 3 demand out-of-cycle attention.

The deeper rule: don't get triage-fatigued

The biggest risk to a homelab security posture isn't the occasional unpatched CVE. It's the operator who looks at the morning scan once, sees 800 findings, decides "this is too much," and never opens the dashboard again.

A scanner with good triage signals (only show what changed since yesterday, only show findings that pass the decision matrix above) makes the difference between "I glance at this in two minutes daily" and "I avoid this for months." Diff-from-yesterday reporting matters more than any individual feature for that reason.

Noxen is a Mac-native homelab scanner that defaults to diff-from-yesterday in the UI — not because it's missing data, but because daily review is what makes triage sustainable. $79 one-time at launch.