What is the difference between CVSS and runtime-based vulnerability prioritisation?

CVSS estimates severity in a mostly static way, while runtime-based prioritisation adds workload context, exploitability, fixability, and whether the vulnerable package is in use. In Kubernetes, that distinction matters because a severe vulnerability may be low priority if it is unreachable, unused, or not credibly exploitable. Runtime data helps separate noise from real risk.

Severity scores tell you how bad a flaw looks, runtime tells you whether it matters now

CVSS is a useful severity baseline, but it is still a mostly static score. Runtime-based prioritisation asks a different question: is this vulnerability actually exposed in the running workload, on a reachable path, with a package that is present, loaded, and plausibly exploitable? That is why it is often a better filter for Kubernetes triage than score alone.

In practice, the two approaches answer different operational needs. CVSS helps normalise cataloguing and reporting, while runtime signals help teams decide what to fix first in a live cluster. A high score can still be low priority if the affected component is not deployed, not in use, or isolated from the attack path. The runtime view is about effective risk, not theoretical severity.

For vulnerability discovery and exposure context, the FIRST CVSS specification defines the severity model, while the CISA Known Exploited Vulnerabilities Catalog shows why exploitability evidence can outrank a nominal score when deciding what to remediate first. In container environments, the NIST SP 800-190 Container Security Guide is useful context because runtime context, image content, and orchestrator behaviour all affect real exposure.

What runtime-based prioritisation adds in Kubernetes

Runtime-based prioritisation enriches vulnerability data with workload context: whether the vulnerable package is present in the running container, whether the code path is actually invoked, whether the service is reachable, and whether compensating controls or network boundaries reduce exposure. That makes it materially different from image-only or catalogue-only scoring, especially in ephemeral and tightly scoped Kubernetes deployments.

This matters because container images often carry more packages than the application truly uses. Without runtime signals, teams can spend time on dormant libraries, dev tooling, or transitive dependencies that never execute in production. With runtime data, the question shifts from “Is there a CVE?” to “Can this flaw be exercised in this workload, right now, from a realistic attacker path?”

That is why runtime-based prioritisation often pairs better with exploitability signals than with severity alone. If a package is present but unreachable, or a vulnerable code path is never loaded, the risk may be lower than the CVSS number suggests. If the package is loaded into a public-facing pod with known attack surface, the same CVE becomes a much stronger candidate for immediate action.

For teams comparing catalogue-based and exploit-based triage, the FIRST EPSS model is a useful companion because it adds likelihood-of-exploitation thinking, while the NIST National Vulnerability Database remains the common reference point for CVE metadata and CVSS scores. Runtime prioritisation sits closer to the workload than either source and therefore resolves a different layer of the decision.

Why this distinction reduces noise in container operations

The biggest operational benefit is noise reduction. Kubernetes teams are usually limited by attention, not by lack of CVEs. Runtime-based prioritisation helps separate vulnerabilities that are merely known from vulnerabilities that are materially exposed in the current workload, which improves patch sequencing and reduces churn from low-value remediation tickets.

It also improves decision quality when fixability matters. Some vulnerabilities are theoretically severe but difficult to exploit in a given deployment, while others are easier to remediate because the vulnerable package can be removed, replaced, or rebuilt quickly. Runtime-aware triage makes those trade-offs visible. It also helps teams avoid the false confidence that comes from a clean CVSS dashboard when the actual workload remains exposed through active, reachable components.

At scale, the difference becomes more pronounced because teams are no longer judging a single image in isolation. They are judging hundreds of pods, images, namespaces, and deployment patterns, each with different runtime paths and exposure profiles. In that environment, severity without context becomes a poor signal, while runtime evidence gives security and platform teams a way to focus on the few findings that can actually change the attack surface.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.IP-12 — Vulnerability Management	Runtime prioritisation improves how vulnerabilities are assessed and remediated in production.
Recommendation — Use operational context to prioritise remediation for vulnerabilities that are actually exposed.
CIS Controls v8	7.1 — Establish and Maintain a Vulnerability Management Process	The comparison is about how to prioritise vulnerabilities for remediation in real systems.
	4.2 — Establish and Maintain a Software Inventory	Runtime-based prioritisation depends on knowing which vulnerable components are present in workloads.
Recommendation — Prioritise remediation using exploitability and runtime exposure, not severity alone. Maintain accurate software inventory so remediation targets the components actually running.

Practitioner Guidance

What to verify: Before trusting a vulnerability queue, confirm whether the vulnerable package is present in the running workload, whether the affected code path is exercised, and whether the pod or service is reachable from a realistic attack path. If those answers are unknown, treat the finding as incomplete rather than benign.

Decision rule: If a flaw has a high CVSS score but no runtime presence or exposure, place it behind vulnerabilities that are both exploitable and active in production. If the vulnerable component is loaded, reachable, and central to the service, prioritise it even when the score is only moderate.

What practitioners underestimate: Runtime data does not replace severity scoring, it changes the meaning of the queue. The best programmes use CVSS for baseline classification and runtime context for remediation order, which is the difference between counting vulnerabilities and reducing actual exposure.

Practitioner takeaway: Use CVSS to describe the flaw, but use runtime evidence to decide whether the flaw deserves immediate engineering effort in the live cluster.

Risk and Threat Considerations

The risk in CVSS-only triage is not that scores are wrong, but that they are detached from deployment reality. In Kubernetes, that can leave teams chasing irrelevant findings while a reachable, loaded, and externally exposed vulnerability remains open.

Failure mechanism: Static scoring ignores whether the vulnerable package is actually in use, whether the code path is reachable, and whether the workload is isolated enough to make exploitation unlikely, so the prioritisation queue can overstate dormant issues and understate active ones.

Impact: The organisation spends remediation capacity on low-exposure findings, delays fixes for exploitable workloads, and increases the chance that a real attack path remains unpatched because it looked less urgent on paper.

Framework Alignment

The question maps most directly to vulnerability management and prioritisation controls, with runtime context improving the practical application of those controls in live container environments.

NIST-CSF, PR.IP-12, Vulnerability Management, maintain a plan to identify, assess, and remediate vulnerabilities based on operational context.
CIS-CONTROLS, 7.1, Establish and Maintain a Vulnerability Management Process, use prioritized remediation so live exposure drives fix order.
CIS-CONTROLS, 4.2, Establish and Maintain a Software Inventory, confirm which vulnerable components are actually present before assigning remediation priority.
NIST-800-63, null, null, null, null