How to Prioritize Vulnerabilities in Kubernetes: CVSS, EPSS, KEV and Runtime Evidence

01

Why sorting by CVSS fails as a work order

Run a scanner across a cluster and it returns every package with a known CVE in every image. The one number on every row is the CVSS base score, so it becomes the sort key. The CVSS v4.0 specification is precise about what that number is: the base score reflects the intrinsic characteristics of a vulnerability, which are constant over time and across environments, and assumes the reasonable worst-case impact across different deployments. It rates the vulnerability, not your cluster.

Used as a work order, it goes wrong in three ways. It does not move when attackers start exploiting a vulnerability. It gives the same score to a library the application calls on every request and to one that sits unused in a base image layer. And a large result set has many findings with the same score, so the sort does not tell a team which of them to start with.

CVSS itself anticipates this. Its Threat metrics adjust the score for exploit maturity and its Environmental metrics for your own deployment, and the specification makes applying them the consumer's responsibility. Public feeds such as the National Vulnerability Database typically publish only the base score. The answer is not to discard CVSS but to demote it: it becomes one input, answered after exploitation and after the facts of your own environment.

02

What CVSS, EPSS and KEV each tell you

The three public signals are often shown side by side as if they were three scales for the same thing. They answer different questions, and all three are identical for every organisation that runs the affected software.

• CVSS base score, 0.0 to 10.0: how severe the vulnerability would be if it were exploited, under a reasonable worst-case assumption. It is a severity rating, not a likelihood and not a measure of your exposure.
• EPSS probability, 0 to 1: FIRST's model estimate that exploitation activity for a CVE will be observed in the wild over the next 30 days, recalculated daily for published CVEs. FIRST treats the probability as the model's primary output; the percentile is a relative ranking of that probability against all scored CVEs. Because exploitation is rare, most probabilities look small, and a value that sounds low can still rank near the top.
• CISA KEV: the Known Exploited Vulnerabilities catalog lists vulnerabilities that have a CVE ID, reliable evidence of active exploitation in the wild, and a clear remediation action such as a vendor update. It is a confirmation, not a forecast. Attempted exploitation counts; scanning, security research and public proof-of-concept code do not. Each entry records the date it was added, a remediation due date for US federal agencies, and whether use in ransomware campaigns is known.

03

Where KEV due dates come from

The KEV catalog was created under Binding Operational Directive 22-01, issued in November 2021. It required US federal civilian agencies to remediate catalogued vulnerabilities within two weeks, or within six months for CVEs assigned before 2021, and those due dates are where the catalog's reputation as a deadline list comes from.

On 10 June 2026 CISA revoked BOD 22-01 and replaced it with BOD 26-04, Prioritizing Security Updates Based on Risk. The new directive keeps the KEV criteria but no longer sets a timeline from catalog membership alone. It asks four questions: is the asset publicly exposed, is the CVE in KEV, can an adversary automate every step of exploitation, and does exploitation give partial or total control. The shortest timeline is three calendar days plus a forensic triage for signs of compromise, for KEV vulnerabilities that give total control and are either publicly exposed or automatable. At the other end, a vulnerability that is not exposed, not in KEV and not automatable is fixed at the asset's next scheduled upgrade. CISA publishes the KEV, automation and technical impact answers per CVE; exposure is for each agency to establish.

The directive binds only federal agencies, but its structure is a useful template for anyone: it combines a public exploitation signal with facts about your own asset. It does not use EPSS, and it does not ask whether the vulnerable code is loaded or executed. Those are the gaps the rest of this guide fills.

04

The questions only your environment can answer

Public signals are the same for everyone. What turns them into a decision is a short list of facts about where the vulnerable component actually runs. Each can be answered with evidence rather than opinion, and each can be wrong in a known way.

• Does it run? An image in a registry that no pod runs is inventory, not exposure. Map findings to the clusters, namespaces and workloads that are running the image today, by digest rather than by tag.
• Is it loaded? For a library, whether any process in the workload mapped it into memory. A package that is installed but never loaded cannot be reached through the application, though it remains usable by anyone who already has code execution in the container.
• Is the vulnerable code executed? Stronger than loaded: the vulnerable function, or a caller of it, ran. It is the most specific evidence and the most expensive to collect, and not every sensor can observe it for every language and runtime.
• Is it exposed? Whether the workload accepts traffic from the internet or from untrusted tenants, through a LoadBalancer or NodePort Service, an Ingress or Gateway route, or a listener reachable from outside the cluster. Internal-only lowers the priority; it does not remove it, because internal services are how attackers move laterally.
• What privileges does it hold? A container that runs as root or privileged, shares host namespaces, mounts host paths, or uses a service account that can create pods or read Secrets turns a partial compromise into a node or cluster compromise. It extends BOD 26-04's technical impact question from the vulnerable software to what that software can reach.
• Is there a fix? A fixed upstream version, a patched base image, or only a configuration mitigation. When there is no fix, the decision is about mitigation and monitoring, not about patching sooner.

05

Recording accepted risk: VEX, evidence and a review date

Anything below the top of the ladder is deferred, and a deferral that is not written down is rediscovered by every scan and argued about again. VEX, the Vulnerability Exploitability eXchange, is the standard shape for that record. A VEX statement gives a product's status for one vulnerability: not affected, affected, fixed or under investigation. CISA's minimum requirements say a not-affected statement should carry a justification, and must carry an impact statement when it has none, and that an affected statement must carry an action statement describing the remediation or mitigation.

CISA defines five justifications for not affected: component not present, vulnerable code not present, vulnerable code cannot be controlled by adversary, vulnerable code not in execute path, and inline mitigations already exist. Choose the one the evidence supports. CISA's definition of not in execute path is that the vulnerable code can never be executed in the context of the application, and it warns against assuming a single path of execution. Runtime observation that a library was never loaded over a representative window is strong support for that claim, but it is evidence from a window, not a proof, and the impact statement should say so.

Each deferral should carry the following, whether it is published as VEX or kept in an internal tracker.

• The status and justification, or, for a finding that is affected but deferred, the reason and the compensating control as the action statement.
• The evidence: the observation window, the workloads and image digests it covered, what was or was not seen, and any static analysis that supports it.
• An owner and a review date. VEX statements carry timestamps but no expiry, so set one in your own tracking, and review earlier if the image changes, the CVE enters KEV, or its EPSS probability rises.

06

Rolling it out: start with what you would patch anyway

Changing the order of a security queue is a policy change, and it is easier to agree on when the first version makes nothing worse. Keep every existing obligation, such as KEV deadlines, contractual or compliance remediation times, and critical findings on internet-facing services, and at first use the new signals only to order work within those obligations and to pull forward what the old sort missed.

• Start from running workloads, so each finding maps to something that runs rather than to everything in the registry.
• Add KEV and EPSS to every finding. Both are free: CISA publishes the catalog as CSV and JSON, and FIRST publishes EPSS scores daily through CSV downloads and an API.
• Add exposure and privilege from the Kubernetes API: Services, Ingresses and Gateway routes, pod security contexts, and service account bindings.
• Add runtime evidence last, and use it first to raise priority, moving findings that are loaded and exposed up the queue, rather than to suppress anything. Defer on the basis of not loaded only once the team has seen enough evidence to trust the sensor's coverage.
• Review the ladder on a fixed schedule against what happened: which deferred findings later entered KEV, which urgent ones turned out not to matter, and whether the thresholds still fit.

07

Where this approach breaks

Each signal fails in a known way, and a ladder built from them inherits every failure. These are the ones to keep in view.

• EPSS is not environment-aware: FIRST states that it is not a complete risk score and does not account for compensating controls or anything specific to your environment. A low probability for a CVE on an internet-facing service is still a forecast about the internet at large, not about your service.
• KEV lags and confirms rather than predicts: an entry needs reliable evidence of exploitation and a clear remediation action, so a vulnerability can be exploited before it qualifies. Absence from the catalog means CISA has not confirmed exploitation, not that none has happened.
• No observed execution is not proof of safety: observation covers a window and the traffic in it. Scheduled jobs, error handling and rarely used endpoints may not run, an attacker can divert execution, and a library the application never loads is still usable by someone with a shell in the container.
• Kernel and node vulnerabilities sit below the application: whether a workload loaded a library says nothing about a kernel or container runtime CVE. Judge those by node privileges and exposed interfaces, and fix them through node image updates.
• The inputs change: EPSS is recalculated daily, KEV grows, and images are rebuilt. A decision made on last month's data needs a review date, not a permanent suppression.

08

How Primod approaches it

Primod supplies the environment-specific half of this ladder with runtime evidence. A per-node eBPF sensor records library loads, execution paths, process lineage and network activity, and the platform correlates them with CVE data and cloud posture, so a finding shows the affected workloads, available fix information, and, where it was captured, the call stack behind a reachable finding. Missing execution evidence is shown as missing, not as safe: runtime evidence informs your remediation policy alongside severity, exposure and exploitation data, and does not replace it.

09

At a glance: a decision ladder

The table puts the signals in order. Read it from the top and stop at the first row that matches. The actions are relative, not deadlines: map them to the timeframes your own policy sets. Rows that depend on runtime evidence assume a sensor; without one, treat a component that is present in a running workload as loaded.