Prioritizing the CVEs that are actually running

A scan of a real cluster comes back with thousands of findings. Sorted by severity, the top of that list is a wall of CRITICALs — most of them in packages you do not run, or that have no fix, or that nobody is exploiting. Severity tells you how bad a CVE could be in the abstract. It does not tell you which one to open first.

Ephor now ranks findings instead of just listing them. The newest release reorders the whole vulnerability view around a simple question: of everything the scanner found, which handful is worth your morning?

Three signals Ephor already has

The ranking is built from three facts, each of which Ephor was already collecting:

• Deployed. The scanner runs inside your cluster, so it knows which findings are on workloads that are actually running — not sitting in a registry image nobody pulls.
• Exploitable. A CVE counts as exploitable if it is on the CISA KEV catalog, or if its EPSS score — the probability it will be exploited — is over a threshold you set.
• Fixable. The advisory carries a fixed version, so there is something you can actually do today.

Cross those three and most of the noise falls away. A finding that is running, exploited in the wild, and fixable is a different kind of problem than an identical CVE in an image you do not deploy.

Four tiers, not a made-up score

Findings land in one of four tiers:

P0  Act now   deployed + on KEV + fixable
P1  Urgent    deployed + exploitable + fixable
P2  Plan      deployed + exploitable, no fix yet
P3  Monitor   everything else

We chose tiers over a blended 0–100 risk number on purpose. A single score hides arbitrary weights behind false precision; a tier is legible and you can defend why a finding is in it. The dashboard leads with how many findings are P0 or P1 — the ones that need action now — and you can sort or filter the full list by KEV, EPSS, or whether a fix exists.

What this does and does not claim

It is worth being precise, because this is exactly where security tools oversell. Ephor knows a vulnerable package is deployed and running in your cluster, because the scanner sees the workloads and images. It does not claim the vulnerable code path is reachable or executed — that needs runtime instrumentation Ephor does not do. And KEV and EPSS describe exploitation in the wild, across everyone, not a proven exploit in your specific environment. "Running and exploitable" is a sharper filter than severity. It is not a promise that an attacker has a path in.

Where this sits

Prioritization is the layer on top of everything else Ephor does — the dashboard, triage, and remediation tracking that pick up where Trivy and Grype leave off. Self-hosted, AGPL, your data stays in your own database. The full tier rules and the threshold setting are in the Prioritization docs, and the in-between case — flagging a vulnerable image before its next scan even runs — is covered in Finding CVEs in images you haven't scanned yet.

The code is on GitHub, the scanner at holbein-io/ephor-scanner. If you run Kubernetes and your CVE list has become something you scroll past, I would like to hear whether this changes that. Open an issue, or email hello@holbein.io.