What runtime correlation adds to static reachability analysis

By Selin Kaya

Static reachability analysis gives you a conservative over-approximation of exploitable paths: every path that could be traversed from attacker-controlled input to a sensitive sink, given any legal execution of the application as written. That is a powerful starting point, but it has a known limitation. "Could be traversed" is not the same as "is currently being exercised in production." Runtime correlation closes that gap, and it changes the triage question in a way that matters operationally.

The change is from: "which paths are exposed in theory" to "which of those paths have evidence of current activity." A WAF alert touching service A, a RASP-detected deserialization attempt in service B, a SIEM event correlated to a specific API endpoint: these are signals that a particular path segment in your application graph is actively being probed or traversed right now. Overlaying those signals onto a static reachability model turns a risk inventory into a live alert prioritization layer.

The ambiguity problem that runtime signals resolve

Consider an application with 30 statically-reachable exposure paths, ranked by traversal depth and node sensitivity. Path 7 terminates at a database node containing payment records. Path 22 terminates at a configuration store with credentials. By static analysis alone, both are serious, and severity ordering from CVSS on the vulnerabilities involved will give you a relative ranking, but it cannot tell you whether either path is currently seeing traffic patterns consistent with exploitation or reconnaissance.

Now add a WAF alert: a specific IP has been sending requests to the entry point endpoint for path 7 with malformed JSON payloads over the past six hours. That signal, mapped to the graph, tells you that path 7 is not theoretical right now. There is external activity directed at its entry node. The alert alone, without graph context, tells you someone is poking at an endpoint. The graph context tells you that endpoint is on the most sensitive path in your application. The combination is actionable in a way that neither piece of information is on its own.

What runtime signals can and cannot confirm

Runtime signals confirm activity, not compromise. A WAF alert means something triggered the WAF's detection logic at that entry point. It does not mean the attacker successfully traversed the path to the sensitive data node. A RASP signal means an instrumented function detected a suspicious invocation pattern. It does not mean the vulnerability was exploited. The distinction matters for response decisions.

What runtime correlation correctly establishes is elevated urgency: a statically reachable path with a current runtime signal has a higher triage priority than a statically reachable path with no runtime signal. That prioritization is sound regardless of whether exploitation occurred, because the runtime signal indicates the path is operationally active and under scrutiny from the outside.

The limitation to be direct about: runtime correlation cannot improve the completeness of the reachability model. If static analysis missed a path, no runtime signal will compensate for that. Runtime signals are a priority layer on top of the static model, not a replacement for it. Teams that rely on runtime detection as their primary attack surface mapping tool will miss paths that are theoretically traversable but not yet being probed. Attackers probe selectively; the absence of runtime activity for a path does not mean it is not exploitable.

Signal types and their graph mapping fidelity

Different runtime signal sources map to the application graph at different granularities.

WAF alerts typically carry the source IP, the HTTP verb, the path, and in some configurations the matched rule. The HTTP path maps to a specific entry node in the application graph, assuming your graph construction included API endpoint inventory. This is high-fidelity mapping: you know which entry point was touched.

RASP signals carry execution context at the point of detection: the call stack at the time of the suspicious invocation, the process, and sometimes the thread or request ID. If the RASP instrument is positioned at a library boundary, you know both which vulnerable function was approached and, from the call stack, which application-layer path triggered the invocation. This is the highest-fidelity signal for matching to specific edges in the call graph.

SIEM aggregations are noisier. A SIEM rule might fire on a combination of events that collectively suggest lateral movement or credential stuffing. Mapping a SIEM alert to a specific graph path requires knowing which services generated the contributing events, which is possible if your service topology is correctly inventoried but requires more correlation work than direct WAF or RASP signals.

The operational loop

The way this works in practice at Cybret: the static reachability model is computed from the codebase and service topology. That model is the stable reference. Runtime signals are ingested continuously and matched to entry nodes, internal nodes, or edges in the graph depending on their fidelity. When a signal matches a node that is part of a high-severity reachable path, that path's priority score updates, and it surfaces in the triage queue above unreinforced paths of the same static severity.

The model does not need to be recomputed when a runtime signal arrives. The graph is queried: which paths include this node? Those paths get their urgency score elevated. When the signal window expires or clears, the urgency score returns to the baseline static severity. This separation of the static model (stable, computed at scan time) from the runtime urgency signal (dynamic, continuously updating) is what makes the correlation practical at production cadence.

What this does not solve

Runtime correlation does not reduce the static reachable path count. If you have 30 reachable paths, you still have 30 paths that need remediation planning. The correlation layer tells you which ones to handle first, not how many there are. Teams sometimes hope that adding runtime signals will reduce the overall remediation backlog. It does not. It changes the ordering. The backlog work is still driven by the static model.

It also does not substitute for understanding why a path exists architecturally. A path from an unauthenticated endpoint through three internal service hops to a database node is an architecture problem, not just a findings problem. Knowing that path has a current runtime signal makes it urgent today, but remediation requires understanding the service graph structure that creates the path, which is a design-level question. Runtime urgency escalation is a triage tool; it does not generate the architectural insight needed to eliminate the path.