What is runtime reachability?

Runtime reachability confirms that a vulnerability is not only present in your dependencies but that the vulnerable code path is reachable in your application and, at runtime, whether it is actually being exercised or exploited. It combines static reachability analysis (is the vulnerable function called?) with runtime observation (is that path being hit or attacked?).

How do you tell if a CVE is exploitable at runtime?

Two signals combine. Static reachability analysis checks whether the vulnerable function is invoked from your application’s entry points via the call graph. Runtime observation — via a kernel-level eBPF agent watching process trees, syscalls and network egress — confirms whether that path is actually exercised and whether an exploitation sequence (unexpected child process, reverse shell, attacker callback) is occurring.

What is the difference between reachability and runtime reachability?

Reachability analysis is static: it determines from the call graph whether the vulnerable code is invoked in your application. Runtime reachability adds the live dimension — using runtime telemetry (eBPF) to confirm whether the reachable path is actually being exercised in production and whether it is under attack. Static tells you what could be exploited; runtime tells you what is.

How does eBPF detect vulnerability exploitation?

eBPF programs attach to kernel hooks that fire on system calls, process creation, file access and network activity. Because eBPF runs in the kernel — not alongside your workloads — a compromised container or application cannot disable it. O3 uses this to recognise an exploitation sequence as it unfolds and to sever the malicious outbound channel, even for unpatched or end-of-life systems.

Why is reachability important for prioritising CVEs?

Most CVEs flagged by a dependency scanner are never reachable in your code, so acting on all of them wastes fix windows on non-exploitable issues. Reachability removes that noise by surfacing only the CVEs on paths your application actually invokes — and runtime confirmation narrows it further to what is genuinely being exercised or attacked.

Runtime reachability: is a CVE actually exploitable?

Runtime reachability is the practice of confirming that a vulnerability is not just present in your dependencies, but that the vulnerable code path is actually reachable in your application — and, at runtime, whether it is being exercised or exploited. It is the difference between “this CVE exists in a library you ship” and “this CVE is exploitable, right here, right now.”

Why “vulnerable” is not the same as “exploitable”

A dependency scan tells you a CVE exists in something you depend on. It cannot tell you whether your code ever calls the vulnerable function, whether that path is reachable from untrusted input, or whether anything is actually hitting it in production. Most flagged CVEs are never reachable — which is why raw SCA output is mostly noise, and why teams burn fix windows on vulnerabilities that were never exploitable in their context.

Reachability analysis answers the first half: static analysis of your call graph determines whether the vulnerable function is invoked from your code, directly or transitively. That alone removes the majority of false urgency. Runtime observation answers the second half: is that path actually being exercised, and is anything trying to exploit it?

Static reachability: is the vulnerable code called?

O3 builds a call graph of your application and its dependencies and checks whether the specific vulnerable symbol for a CVE is reachable from your entry points. A CVE in a function you never call is not your problem this sprint; a CVE on a path reached from an HTTP handler is. This is what turns a list of hundreds of dependency CVEs into the handful that can actually be triggered in your code.

The same signal drives prioritisation and VEX: reachable-and-exploitable CVEs get flagged as affected; unreachable ones can be justifiably marked not-affected, which is exactly the vulnerability status regulators (and CERT-In’s SBOM guidelines) want communicated rather than raw scan dumps.

Runtime reachability: is it being exercised — or exploited?

Static analysis can be conservative; some paths look reachable but are never taken in practice, and some exploits target the running system rather than your source. This is where O3 observes the workload directly. A kernel-level eBPF agent watches process trees, system calls, file access and network egress from inside the kernel — where a compromised container or application cannot disable it.

That runtime layer confirms which reachable paths are actually executed, and — more importantly — recognises an exploitation sequence as it unfolds: an unexpected child process, a reverse shell, a callback to an attacker-controlled host. O3 flags the exploit behaviour from runtime telemetry and severs the outbound channel, even on a vulnerability that has no patch yet or an appliance you cannot modify.

Why combining them is the point

Reachability without runtime tells you what could be exploited; runtime without reachability tells you what is happening but not why it matters to your code. O3 connects both into one verdict: this CVE is reachable in your application, here is the path, and here is whether it is being exercised or attacked in production — with the ability to block the exploit while you remediate.

That closed loop — find the reachable flaw, confirm it at runtime, block exploitation, open the fix PR — is the difference between a vulnerability backlog and an actually-managed risk.

How O3 does this

Impact-Aware SCA

Reachability-based SCA — which dependency CVEs are actually reachable in your code.

Workload Security

eBPF runtime protection for CI/CD runners and containers — no sidecars.

Egress Monitor

Catches the post-exploitation callback and severs the attacker’s outbound channel.

Vulnerability Database

Per-CVE exploit status, EPSS, KEV and reachability context.

Frequently asked questions

What is runtime reachability?: Runtime reachability confirms that a vulnerability is not only present in your dependencies but that the vulnerable code path is reachable in your application and, at runtime, whether it is actually being exercised or exploited. It combines static reachability analysis (is the vulnerable function called?) with runtime observation (is that path being hit or attacked?).
How do you tell if a CVE is exploitable at runtime?: Two signals combine. Static reachability analysis checks whether the vulnerable function is invoked from your application’s entry points via the call graph. Runtime observation — via a kernel-level eBPF agent watching process trees, syscalls and network egress — confirms whether that path is actually exercised and whether an exploitation sequence (unexpected child process, reverse shell, attacker callback) is occurring.
What is the difference between reachability and runtime reachability?: Reachability analysis is static: it determines from the call graph whether the vulnerable code is invoked in your application. Runtime reachability adds the live dimension — using runtime telemetry (eBPF) to confirm whether the reachable path is actually being exercised in production and whether it is under attack. Static tells you what could be exploited; runtime tells you what is.
How does eBPF detect vulnerability exploitation?: eBPF programs attach to kernel hooks that fire on system calls, process creation, file access and network activity. Because eBPF runs in the kernel — not alongside your workloads — a compromised container or application cannot disable it. O3 uses this to recognise an exploitation sequence as it unfolds and to sever the malicious outbound channel, even for unpatched or end-of-life systems.
Why is reachability important for prioritising CVEs?: Most CVEs flagged by a dependency scanner are never reachable in your code, so acting on all of them wastes fix windows on non-exploitable issues. Reachability removes that noise by surfacing only the CVEs on paths your application actually invokes — and runtime confirmation narrows it further to what is genuinely being exercised or attacked.