Scan severity measures how serious a vulnerability looks in isolation, usually through scores such as CVSS or exploitability indicators. Runtime risk reflects what is actually exposed in your environment, including whether the affected workload is running, reachable, internet-facing, or already mitigated by configuration. Runtime context narrows remediation to the vulnerabilities that can truly be exploited.
Why the distinction matters in Kubernetes prioritisation
Scan severity is useful for triage, but it is still a product of the vulnerability record, not your cluster. Runtime risk answers the harder question: can this flaw actually be reached, abused, or chained in the environment where the workload is running? That difference matters because Kubernetes adds deployment state, network exposure, and policy controls that can make a high-severity finding irrelevant or make a moderate one urgent.
Practitioners usually get burned when they treat scanner output as a remediation queue instead of a starting point. A pod that is never scheduled, a workload with no reachable path, or a package with a known issue but no exploitable exposure should not be prioritised the same way as a live service with external traffic and broad permissions. The useful prioritisation signal is the intersection of vulnerability seriousness and actual exposure.
For Kubernetes teams, the practical outcome is simpler than it sounds: severity tells you what could matter in theory, while runtime risk tells you what is worth fixing first in production. In practice, many teams discover the difference only after chasing low-value findings instead of the workloads most likely to be exploited.
How the two signals work together
Scan severity usually comes from CVE metadata, CVSS, exploitability indicators, or scanner-specific heuristics. It is environment-agnostic, so it does not know whether the vulnerable image is deployed, whether the container is even running, or whether the affected path is blocked by network policy, admission controls, or runtime segmentation. That makes it valuable for broad inventorying, but weak for final prioritisation.
Runtime risk adds the missing context. In Kubernetes, that context typically includes whether the workload is live, where it is exposed, what sits in front of it, and whether the vulnerable component is actually invoked. A library flaw inside a dormant image may remain a backlog item. The same flaw inside an internet-facing ingress path may become a same-day fix. NIST SP 800-190 Container Security is a good reference point here because it separates image, registry, orchestrator, and runtime concerns instead of treating them as one control plane. NIST SP 800-190 Container Security
A practical prioritisation flow usually looks like this:
- Start with severity to understand intrinsic vulnerability seriousness.
- Overlay exposure data, such as running state, ingress, service reachability, and namespace placement.
- Check whether compensating controls reduce exploitability, including segmentation, read-only constraints, and limited privilege.
- Escalate findings where the vulnerable component is both active and reachable.
This approach works best when scanner data is enriched with cluster telemetry and deployment metadata, because raw image findings alone cannot distinguish theoretical exposure from exploitable exposure. These controls tend to break down when runtime visibility is incomplete or when ephemeral workloads change faster than the prioritisation pipeline updates.
Common variations and edge cases
Tighter prioritisation often reduces noise, but it also increases the chance that teams miss latent exposure in workloads that are not obvious from the scan alone. That tradeoff is especially visible in Kubernetes because workloads are frequently redeployed, scaled, and replaced, so a once-low-risk image can become high-risk when its placement or exposure changes.
One common edge case is a critical vulnerability in a container image that is present in the registry but not deployed. Scan severity may still look alarming, but runtime risk is low until that image is scheduled or pulled into a reachable path. The opposite edge case is a medium-severity issue in a service that handles real traffic or sits near sensitive data. In that case, runtime context can outweigh the raw score because exploitability is materially higher than the scanner suggests.
Another nuance is that runtime risk is not only about internet exposure. Internal lateral movement, service-to-service trust, overly broad service exposure, and insecure defaults can make an apparently internal workload just as important to prioritise. CISA’s Known Exploited Vulnerabilities Catalog is useful when you want to separate theoretical severity from vulnerabilities that are already being abused in the wild. CISA Known Exploited Vulnerabilities Catalog
The best practice is evolving toward risk-based prioritisation, not score-based cleanup. That means using severity as the first filter, then letting runtime exposure, exploitability, and business reachability decide what moves to the top of the queue.
Risk and Threat Considerations
Severity-only prioritisation creates exposure because it can overstate harmless findings and understate reachable ones. In Kubernetes, the real threat is that attackers do not exploit scores, they exploit deployed services, reachable paths, and weakly isolated workloads.
Failure mechanism: A vulnerable package, base image, or application component becomes dangerous when the workload is running, exposed, or reachable through an internal trust path. Scanner severity ignores those conditions, so teams may delay fixes on exploitable services while burning time on dormant or blocked workloads.
Impact: The result is misallocated remediation effort, longer exposure for live attack paths, and a false sense of security when scan dashboards look clean even though the highest-risk workloads remain unpatched.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while 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 | GV.RM — Risk Management Strategy | Prioritisation must weigh vulnerability severity against actual exposure and business risk. |
| ID.RA — Risk Assessment | This topic is fundamentally about assessing exploitable risk in environment context. | |
| PR.DS — Data Security | Runtime risk in Kubernetes often depends on whether exposed workloads protect sensitive data paths. | |
| Recommendation — Use risk criteria to rank exploitable Kubernetes findings above theoretical ones. Assess live exposure, reachability, and mitigations before assigning remediation priority. Protect exposed workloads and data paths that make vulnerabilities materially harmful. | ||
| CIS Controls v8 | 07 — Continuous Vulnerability Management | Kubernetes prioritisation depends on combining vulnerability severity with exposure and exploitability. |
| 05 — Account Management | Workload access scope affects whether a vulnerability becomes exploitable in runtime. | |
| Recommendation — Enrich scan results with runtime telemetry before setting remediation order. Limit access paths and permissions that expand exploitability in running workloads. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Runtime exposure matters most when a vulnerable service is reachable to attackers. |
| Recommendation — Hunt and patch exposed services that present exploitable entry points. | ||
Practitioner Guidance
What to prioritise: Use severity to sort the universe of findings, but prioritise only the subset that is live, reachable, and not effectively shielded by configuration or segmentation. Treat runtime exposure as the deciding factor when two findings have similar scores.
What to verify: Confirm whether the affected container image is actually deployed, whether the workload is receiving traffic, and whether the vulnerable code path is reachable in the current cluster state. If any of those answers is unclear, the finding should stay open until runtime context is proven.
Decision rule: If a finding is high severity but not running or not reachable, defer it behind exposed workloads with lower scores. If a lower-severity issue is on a production path with external or sensitive internal reachability, escalate it above the nominal score.
Practitioner takeaway: The right question is not “How bad is the vulnerability?” but “How exploitable is it here, right now?” Runtime context should decide remediation order, or severity scores will keep producing the wrong queue.
Related resources from NHI Mgmt Group
- What is the difference between static vulnerability scanning and runtime risk management?
- What is the difference between vulnerability severity and remediation risk in dependency management?
- What is the difference between vulnerability severity and prioritisation in SCA?
- What is the difference between theoretical vulnerability and reachable risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
