What is the difference between static and runtime reachability analysis?

Static reachability analysis checks whether vulnerable packages could be executed based on code paths, container contents, and configuration. Runtime reachability analysis verifies what is actually called during execution in production. The first is broader and faster for triage, while the second adds higher-confidence evidence about live behavior. Used together, they give teams a clearer picture of real exploitability.

Why Static and Runtime Reachability Answer Different Security Questions

Static reachability analysis and runtime reachability analysis are both used to separate theoretical exposure from practical exploitability, but they do not answer the same question. Static methods look at code structure, dependencies, container contents, and configuration to infer whether a vulnerable component could be reached. Runtime methods look for evidence that the vulnerable path is actually exercised in a live environment. For security teams, that difference matters because it affects triage speed, confidence, and prioritisation.

Static analysis is valuable when teams need coverage across large software estates or want to reduce noise in vulnerability queues quickly. runtime analysis is more persuasive when leaders need proof that a weakness is not just present but active in production behavior. The important operational point is that neither view is complete on its own. A package can appear reachable in static analysis yet never be called in practice, while a live code path can be missed if runtime telemetry is sparse or incomplete. NIST guidance on control validation and continuous monitoring is useful context here, especially where teams need evidence that security decisions are based on observable system behavior rather than assumptions alone. NIST SP 800-53 Rev 5 Security and Privacy Controls

In practice, many security teams encounter false urgency or false reassurance only after they rely on a single reachability view instead of comparing both.

How Reachability Signals Change Triage in Practice

Static reachability analysis is usually the first-pass filter. It can scan source code, dependency graphs, build artifacts, and container images to estimate whether a vulnerable component sits on a path that could be invoked. That makes it useful for prioritising large vulnerability backlogs, especially when teams need to sort thousands of findings into those that deserve immediate review and those that are likely dormant. Its weakness is that it infers possible execution rather than observing actual execution, so it can overstate exposure when a dependency is bundled but never called, or when a code path is blocked by configuration.

Runtime reachability analysis adds evidence from execution. It observes whether the function, package, endpoint, or library is called in production, often through instrumentation, telemetry, traces, or security monitoring. That gives a stronger signal for exploitability because it reflects live behavior rather than design intent. It is especially helpful when a vulnerability is hard to reason about statically due to indirect calls, feature flags, dynamic loading, or complex service interactions. Runtime evidence can also reveal that a supposedly critical issue is not currently reachable in the deployed path, which changes remediation sequencing.

Static analysis is broader and better for early triage.
Runtime analysis is narrower but usually higher confidence.
Static results can include dormant paths and false positives.
Runtime results can miss exposure if telemetry is incomplete or the observed period is too short.

Used together, the two approaches help teams distinguish “present in the build” from “reachable in production,” which is often the difference between backlog cleanup and urgent response. The boundary breaks down when instrumentation is weak, environments differ from production, or the vulnerable code path appears only under rare conditions that neither scan nor telemetry captures well.

Where Reachability Assumptions Break Down

Tighter reachability filtering often reduces triage noise, but it can also hide important edge cases, so organisations have to balance speed against completeness. The main limitation is that reachability is not the same as exploitability. A path can be reachable without being practically exploitable if compensating controls block meaningful abuse, and a path can look unreachable until a configuration change, plugin load, or new integration activates it.

Guidance versus consensus matters here. There is broad agreement that runtime evidence strengthens prioritisation, but there is no universal standard for how much runtime observation is enough. Some teams treat any observed call as a strong indicator; others require repeated execution across representative traffic or environments. That difference is important because transient telemetry, canary releases, and short observation windows can produce misleading confidence. In regulated or high-assurance environments, teams often need to retain both the static rationale and the runtime proof so that prioritisation decisions are auditable later.

Another common edge case appears in distributed systems. A package may be unused in one service but critical in another, so a single reachability verdict can be misleading if teams do not scope it to the exact deployment unit, environment, and version. Static and runtime signals should therefore be interpreted as complementary evidence, not interchangeable labels.

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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	18 — Penetration Testing	Reachability analysis supports validation of whether weaknesses are actually exposed.
Recommendation — Use control validation to confirm which weaknesses are truly reachable in your environment.
NIST CSF 2.0	DE.CM — Security Continuous Monitoring	Runtime reachability depends on live observation and monitoring evidence.
	RA.VA — Vulnerability Management	Static reachability is a triage input for prioritising vulnerability remediation.
Recommendation — Instrument production monitoring to verify whether vulnerable paths are executed. Prioritise remediation based on whether a vulnerable component is plausibly reachable.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	Reachability determines whether exposed application paths can be abused.
Recommendation — Map reachable application paths to attack exposure and reduce externally callable risk.

Practitioner Guidance

What to prioritise: Use static reachability to reduce the initial vulnerability set, then reserve runtime analysis for findings that remain material after basic dependency and path checks. That sequence avoids overinvesting in live validation for issues that are clearly non-actionable.

What to verify: Confirm that the runtime sample reflects the actual production workload, deployment variant, and observation window you care about. A clean runtime result is only trustworthy if the telemetry could realistically have seen the vulnerable path.

Decision rule: Treat static-only reachability as a prioritisation aid, not a final proof of exploitability. Treat runtime reachability as stronger evidence, but not as a blanket guarantee that the issue is irrelevant across all environments or future releases.

Practitioner takeaway: The best use of reachability analysis is to separate “possible” from “observed” without confusing either one for the full security decision.