What Is Runtime Reachability? A Guide for Kubernetes Security Teams

Definition

Runtime reachability is evidence, collected from a running system, that a vulnerable component was not only present but was loaded into a process and that the vulnerable code path executed, or could be reached from an entry point the workload actually exposes. It answers a narrower question than a scanner does. A scanner asks whether a package with a known CVE exists in an image. Reachability asks whether that package did anything in production.

The distinction matters because most vulnerable packages in a typical container image are never exercised. Base images carry shells, package managers, compression libraries and language runtimes that the application never calls. A CVE in one of those components is real in the sense that the code is on disk, but it is not exploitable through the application unless an attacker can already execute arbitrary code, at which point the CVE is no longer the problem.

Reachability therefore functions as a filter on top of vulnerability inventory. It does not replace the inventory. It ranks it.

Static reachability versus runtime reachability

There are two ways to establish reachability, and they answer different questions.

Static reachability analysis builds a call graph from source or bytecode and asks whether any path connects the application's entry points to the vulnerable function. It runs in CI, needs no production access, and can flag risk before deployment. Its weaknesses are the weaknesses of call graphs: reflection, dynamic dispatch, plugin loading, and code generated at runtime produce paths the analysis cannot see or, conversely, paths it assumes exist but that are never taken. Static analysis tends to over-approximate.

Runtime reachability observes the process as it runs and records which shared objects were mapped, which functions or syscalls executed, and what the process connected to. It answers what actually happened in the observed window. Its weakness is coverage: a code path that only runs on a rare error branch, a monthly job, or an unusual input will not appear in a short observation window. Runtime analysis tends to under-approximate unless the window is long and the traffic representative.

• Static: shift-left, no production dependency, over-approximates through dynamic language features.
• Runtime: ground truth for the observed window, under-approximates rare paths, requires a sensor in production.
• Mature programs use both: static to gate what ships, runtime to decide what to fix first among what already shipped.

How runtime reachability is measured

On Linux, the practical instrument is eBPF. Small programs attached to kernel tracepoints, kprobes, and uprobes observe events without modifying the application or injecting a sidecar. The events relevant to reachability fall into a few families.

• Library loads: which shared objects and language packages a process mapped into memory. A vulnerable library that was never mapped is unreachable for that process.
• Function execution: whether the specific vulnerable function or a caller of it ran, captured through uprobes or language-runtime hooks. This is the strongest signal and the most expensive to collect broadly.
• Process lineage: which parent spawned the process and with what arguments, which separates an application's own binary from a debugging shell someone opened in the container.
• Syscalls and file access: what the process opened, read, and executed, which reveals whether an interpreter parsed untrusted input or an archive library touched user-supplied files.
• Network paths: what the workload listened on and connected to, which establishes whether a vulnerable service is exposed and what it could reach if compromised.

How reachability combines with CVSS, EPSS, and KEV

Reachability is one input to prioritisation, not the only one. The public signals a team already has each answer a different question.

CVSS describes the intrinsic severity of a vulnerability under the assumption that it is exploitable in the environment. It says nothing about whether your workload exposes it. EPSS estimates the probability that a vulnerability will be exploited in the wild within a time window, based on observed exploitation activity across the internet. CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with confirmed exploitation. All three are environment-independent.

Reachability is the environment-dependent term. A defensible ordering therefore treats a finding as urgent when it is severe, likely or known to be exploited, and reachable in your production workload, and treats it as deferrable when any of those conditions is clearly false. A critical CVSS score on a library that is never loaded is a candidate for a suppression with evidence attached, not for an emergency patch.

Reachability, SBOMs, and VEX

A software bill of materials lists what a build contains. VEX, the Vulnerability Exploitability eXchange, lets a supplier assert whether a product is affected by a given vulnerability and why. Both are statements about the artifact, made before it runs.

Runtime reachability is the consumer-side counterpart. It lets the operator of a system make an evidence-backed statement of the form: this component is present, and in our deployment it is not loaded, or it is loaded but the vulnerable path has not executed under production traffic. That statement can populate a VEX document with a justification such as vulnerable code not present or vulnerable code not in execute path, which is exactly what downstream consumers and auditors ask for.

Where runtime reachability fails

Treating reachability as proof of safety is the most common misuse. Three failure modes matter in practice.

• Coverage gaps: paths that did not run during the observation window are unobserved, not safe. Batch jobs, failover code, and admin endpoints need either longer windows or static analysis to cover them.
• Wrong process boundary: a vulnerable library unused by the application but reachable by a cron job in the same image, or by an operator's shell, is still a lateral-movement asset. Lineage and blast-radius context are needed to reason about it.
• Kernel and platform CVEs: vulnerabilities in the kernel, the container runtime, or the node image sit below the application. Their reachability is a function of exposed interfaces and privileges, not of what a single workload executed.

Putting reachability to work

Teams that adopt reachability usually change three things about their vulnerability programme. First, the queue is sorted by observed execution and exposure rather than by CVSS alone, which shrinks the set that needs immediate engineering attention. Second, suppressions carry evidence: the observation window, the process, and the absence of the load or call, so that the decision survives an audit and can be revisited when traffic patterns change. Third, incident response uses the same telemetry to scope what a compromised workload actually touched, instead of reconstructing it from logs after the fact.

Primod implements this model with a per-node eBPF sensor that records library loads, execution paths, process lineage, and network activity, correlates them with CVE data and cloud posture, and presents the call stack behind each reachable finding. The platform page explains the architecture, and the blog covers the measurement trade-offs in more depth.