Insights
10 minutes

Reachability in AppSec: What Each Type Really Tells You

Not all reachability is equal. The post explains how package-level, function-level, internet, and runtime reachability each shape AppSec accuracy and prioritization, and how Hopper combines them with exploitability and business context to cut 93% of noise and focus teams on real risks.

Published on
October 9, 2025
Written by
Valerie Zargarpur

Not All Reachability Is Created Equal

Traditional SCA tools overwhelm teams with hundreds of “critical” vulnerabilities, most of which are never actually reachable in the application. Reachability analysis changes that. It separates theory from reality, helping AppSec teams cut through noise, focus on the vulnerabilities that matter, and build trust with developers.

But not all reachability works the same way. Some methods provide only a rough filter, while others deliver precision down to the function level. The best programs start with function-level analysis at build time, then layer contextual signals such as exposure, policy, and image hygiene.

The challenge? Vendors use “reachability” to mean different things. Let’s clarify the major types of reachability in AppSec, their value, and their limits.

Terminology Note:
In this post, reachable means there is a code path from your application into the vulnerable code. Exploitability is distinct. From a code perspective, it depends on preconditions like input, permissions, architecture, compensating controls, and runtime context. In practice, most security teams layer this with signals such as EPSS scores, CISA KEV listings, or External Attack Surface Management (EASM) findings to assess the real-world likelihood of exploitation.

Package-Level Reachability

Package-level reachability is measured in two ways and asks two simple questions: is the package imported, and is it referenced? 

Package-level reachability methods include: 

  • Import presence: looks for the package in manifests and import statements. Quick triage, especially in ecosystems where dependency trees bloat, such as JavaScript.
  • Call presence: analyzes code to see if any function or API from the package is actually called at least once.
Strengths Limitations Example
Easy to implement.

Removes some noise from libraries that aren’t referenced at all.
Import presence does not verify usage. Imports can be unused.

Call presence is still broad. It does not tell you whether the vulnerable function is reachable or under what conditions.
You import 20 libraries but only use 10. Package-level reachability trims the unused half, but you’re still left with dozens of theoretical CVEs in the 10 libraries you use.

Function-Level Reachability

This is the gold standard. Function-level reachability identifies whether the specific vulnerable function is actually callable in your application. 

Strengths Limitations Example
Cuts false positives by 90% or more, confirming whether vulnerable functions are actually callable in the application.

Provides developers with evidence: call paths, root causes, line of code, and the exact file.
Scans are more intensive and take longer than classic SCA tools that rely only on version matching.

Most function-level tools are unable to handle complexities like reflection, dynamic loading, shaded libraries, or framework-driven calls, but Hopper handles these with ease.

Does not observe runtime behavior directly.
In the Log4j crisis, many teams didn’t know whether lookup() was actually called in their applications. Function-level reachability could show exactly where (and if) the vulnerable method was invoked, turning chaos into clarity.

Internet Reachability

Internet reachability focuses on exposure: is the vulnerable service or workload internet-facing?

Strengths Limitations Example
Useful as a prioritization signal.

Helps surface the “fix these first” list in large orgs.

Aligns with FedRAMP RFC 0012*, which emphasize visibility into externally reachable components as part of vulnerability management attestations.
Oversimplification: not every internet-facing vulnerability is high risk, and some internal services may be higher priority based on privilege and data.

Determining what is truly reachable from the internet is difficult in microservices and cloud-native environments, where data flows and service interactions are complex and often opaque.
A deserialization issue in an internet-facing API is more urgent than the same issue in an isolated batch-processing job.

*As outlined in the FedRAMP RFC 0012 proposal on secure software development attestation, exposure awareness is becoming a formal compliance requirement.

Runtime Reachability, Including eBPF

Runtime reachability tracks which code paths actually execute when an application runs. It relies on agents, language-level hooks, or kernel telemetry to observe live behavior in production or staging environments. These methods provide high-certainty confirmation of execution, but their visibility depends on runtime coverage.

eBPF: Runtime Clarity, Reachability Gaps

The Extended Berkeley Packet Filter (eBPF) is one of the most transformative kernel technologies in modern Linux. It allows small, sandboxed programs to run safely inside the kernel, enabling developers to trace functions and  monitor performance.

But despite its flexibility, eBPF is still a runtime technology, not a code analysis tool. It observes what executes, but cannot infer the broader logical or static structure of an application. For example:

  • It cannot build a complete dependency graph or determine which code could execute under different conditions.
  • It lacks context on both direct and transitive dependencies, making it impossible to trace how a vulnerability propagates through the dependency tree. Because of this, it also cannot calculate the personalized fix for the specific direct dependency that needs to be updated.
  • Its visibility is further limited by traffic coverage and sampling; dormant paths or code that never executed during observation remain invisible (a typical sample rate goes as high as 20 times per second only).

In short:

  • eBPF captures runtime activity, not build-time reachability.
  • It offers execution evidence, but no code-level traceability for root cause or remediation.
  • It’s most effective when paired with static or hybrid reachability analysis that maps the potential paths before deployment
Strengths Limitations Example
Confirms that specific code paths actually ran.

Useful for incident response and runtime defense.
Too late in the lifecycle: the code is already released and often in production.

Lacks code context such as dependency trees, origins, or fix recommendations. Dormant or rare paths remain invisible.

Requires runtime agents, hooks, or kernel access, which add operational friction and can impact performance.

Typically limited to Linux cloud-native workloads, with blind spots in Windows, client-side, serverless, on-prem, and embedded environments.

Prone to false negatives when runtime sampling fails to hit the vulnerable path.
A YAML deserialization path may exist in your codebase. Runtime reachability confirms if load() executed in staging or production, but only if sampled state / traffic triggered that path.

Pulling It All Together: The Reachability Matrix

Here’s how the main types of reachability compare at a glance:

Type Context Provided Best For Common Limits
Package-level Package is imported (or called at least once) Quick triage, trimming obvious noise Does not prove the vulnerable function is used; unused imports still flagged
Function-level Specific vulnerable function is callable High precision, developer trust, major noise reduction Scans are slower than version matching; most struggle with dynamic loading, reflection, or framework-driven calls (Hopper handles these with ease)
Internet Service or workload is internet-facing First-pass prioritization across large environments Over-simplifies risk; difficult to determine true exposure in cloud-native and microservices
Runtime (eBPF or agents) Vulnerable code executed during observed runs Incident response, runtime defense, proving execution Too late in lifecycle; coverage depends on traffic; lacks code context; requires agents or kernel access; mostly Linux-focused

The Hopper Point of View

At Hopper, we see reachability as more than a single filter. It is a layered methodology that combines precision, context, and developer usability.

  • Function-level reachability: Cuts more than 93% of noise by analyzing whether vulnerable functions are actually callable. Powered by Hopper’s proprietary vulnerability database, which includes function-level context for every CVE, delivering unmatched accuracy.
  • Exploitability context: Incorporates signals like EPSS scores and CISA KEV to prioritize vulnerabilities more effectively.
  • Business context: Highlights issues in crown-jewel applications and maps findings against SLA commitments.
  • Framework and code complexity support: Handles dynamic loading, reflection, shaded libraries, and framework-driven calls with ease, even in complex environments such as Spring, Django, and ASP.NET where conventional tools miss critical paths.
  • Internal library detection: Surfaces risks in proprietary or shared internal packages.

From there, Hopper pairs reachability insights with developer-friendly remediation: call graphs that trace vulnerable functions, direct links to manifest and source files (for example, pom.xml), and references back to the relevant function calls in Git for first-party code.

This combination of methodologies makes Hopper the most accurate and developer-friendly reachability platform. Trusted by security teams to reduce wasted cycles, and by developers to fix only what matters.

Noise Reduction Starts with Reachability

Reachability helps teams cut through noise and focus on vulnerabilities that truly matter. Among the different types, function-level reachability delivers the precision AppSec programs need when paired with business context and developer-friendly remediation.

Hopper brings these elements together in a way that is both accurate and usable, giving security teams clarity and developers guidance they can trust.