Beyond Packages: Precision with Function-Level Reachability

The False-Positive Flood in SCA

Software Composition Analysis (SCA) tools are essential for detecting vulnerabilities in open-source dependencies. However, traditional SCA tools overwhelm security teams with false positives - vulnerabilities that your application never actually executes. Studies indicate that about 90% of dependency vulnerability alerts are typically irrelevant because the vulnerable code is never used by the application.

Moreover, modern applications increasingly rely on open-source packages, but direct dependencies are only the tip of the iceberg. Each one introduces many transitive dependencies, where the majority of vulnerabilities often reside. As dependency trees deepen, accurate analysis of vulnerabilities in both direct and transitive dependencies becomes essential.

This flood of false positives, aggravated by the rising complexity of dependency structures, creates a significant operational burden for AppSec engineers, developers, and CISOs. When teams spend valuable time investigating non-issues, critical vulnerabilities can become obscured in the overwhelming noise, and ongoing alert fatigue undermines trust in the very tools meant to safeguard the application.

When “Reachability” Falls Short

Many SCA vendors now claim to reduce false positives using "reachability analysis,” however, not all “reachability” is created equal. The "reachability" family of analyses includes a wide range of variations, which can differ greatly in quality and most common approaches barely scratch the surface, resulting in only modest precision gains. Let’s examine where they fall short:

Package-Level or Class-Level Reachability

The simplest approach marks a vulnerability as “reachable” if any part of the vulnerable package or class is used in the application. In the case of package-level reachability, a vulnerability is considered reachable if any class within the same package as the vulnerable code is used, regardless of whether the actual vulnerable class or method is ever invoked. 

For example, if a vulnerability exists in com.acme.lib.Foo#vulnerableMethod, but your application only uses com.acme.lib.Bar, the vulnerability will still be flagged simply because both classes are in the same package. 

Class-level reachability improves on this slightly by narrowing the scope: it flags the vulnerability if the vulnerable class (e.g., com.acme.lib.Foo) is referenced anywhere, even if vulnerableMethod is never called.

This coarse granularity leads to a low noise-reduction rate (in our experience 20-40%), therefore to many false positives. Industry experts caution that a good SCA tool must go beyond class-level reachability and offer deep function-level insights while keeping false positives low.

Class Hierarchy Analysis (CHA) Reachability

Some function-level reachability tools attempt to build a call graph for your application to see if vulnerable functions are invoked. The quickest way to do this is using Class Hierarchy Analysis (CHA). CHA assumes that any method call could target any subclass of the declared type. It’s fast, but very imprecise. 

For instance, imagine your application uses a popular image parsing library capable of handling PNG, JPEG, and GIF images. A known vulnerability exists, but only in the JPEG parsing function (JPEGParser::parseImage()). Since your application references the generic image parser interface (parseImage()), CHA mistakenly flags all parsing functions in all image parsers (JPEG, PNG, GIF) as reachable, even if your code never processes JPEG files. It’s a recipe for alert fatigue.

Although this technique operates at the function level, offering an improvement over class- or package-level approaches, it may still not yield significantly better results in many common scenarios. 

During a head-to-head comparison against a function-level reachability vendor which relies on CHA, we analyzed the Shopizer open-source project. We found that the noise reduction achieved by the CHA methodology was no more than 25%. This limited effectiveness is typical for any application built using Spring or other popular web frameworks, highlighting the inherent shortcomings of CHA-based analysis tools in such contexts. 

Shallow SAST Rules (Direct Calls Only)

A few tools take a more pattern-based Static Application Security Testing (SAST) approach, essentially searching your code for direct calls to vulnerable functions. For example, if a vulnerability exists in Foo.doDangerousThing(), the tool might scan your codebase for any invocations of Foo.doDangerousThing. This can catch obvious direct usage, but it breaks down with anything indirect. 

Modern applications invoke library code through layers of abstraction, frameworks, and callbacks, not to mention reflection or dependency injection. Pure pattern-matching (regex) or AST-based approaches can miss reachable vulnerabilities that aren’t explicitly called by name in your code (i.e. false negatives).

Conversely, one vendor has shown that adding basic reachability analysis based on SAST reduced noise by only ~40% - dropping from 58 alerts to 34 in their own demonstration. That’s a start, but it still leaves a lot of unnecessary noise in the results.

This is exactly why SAST tools built for analyzing first-party code are poorly suited for SCA problems. They’re not designed to model the unique calling patterns and boundary-crossing behavior typical of third-party dependency usage. The result is poor accuracy - some real risks are missed, while still too many false alarms slip through.

The Illusion of Reachability

In summary, many “reachability” solutions today provide only a facade of analysis. They operate at the wrong granularity (package or class level) or use naive call graph construction. The outcome is that security teams still must sift through a lot of noise, or worse, develop a false sense of security despite incomplete analysis. What’s needed is a deeper, more intelligent approach to truly understand if and how vulnerable code is exercised by your application.

Hopper’s Approach: PTA for Precise Reachability

Our SCA platform leverages Points-To Analysis (PTA) for highly accurate reachability detection. PTA determines which objects a reference can point to at runtime, enabling a precise call graph that avoids the over-generalizations and false positives common in basic techniques like Class Hierarchy Analysis (CHA).

In the image parsing example, PTA can determine that the app never instantiates (creates a new instance of a class, essentially bringing a class's blueprint to life as an object) or calls into the vulnerable JPEG parser. So, a vulnerability in that component is correctly flagged as unreachable.

Hopper’s reachability engine operates at function-level precision and is interprocedural and transitive. We don’t just check your application’s direct calls, but also how your code calls into library A, which calls library B, which calls the vulnerable function in library C. Many critical issues lurk in transitive dependencies (deep in the dependency tree), and our reachability analysis traces those chains end-to-end. This ensures that only truly exploitable vulnerabilities are prioritized, while unreachable ones are safely deprioritized. This level of precision is what basic CHA or direct-call scanning fails to achieve.

Modeling the Hard Stuff: Frameworks, Reflection, and Dynamic Magic

One reason static analysis of real-world applications is challenging is the prevalence of dynamic and framework-driven behavior. Enterprise apps aren’t simple, linear programs. They use dependency injection frameworks, reflection, proxies, and other “magic” that can make it hard to determine what calls what. A hallmark of our platform is that we’ve invested heavily in custom modeling for these dynamic patterns, ensuring our reachability analysis doesn’t get tripped up by the tricks that modern frameworks use.

Consider Java’s reflection or dynamic class loading, as well as frameworks like Spring. Spring (and similarly, ASP.NET in the .NET world) will auto-discover controller classes or inject beans by type at runtime. Traditional static analysis might see no explicit function call in your code to the vulnerable function, because it is orchestrated by the framework at runtime. A naïve analysis could wrongly conclude a false negative that leaves you blind to a real exploit path. On the other hand, simpler tools might overcompensate by assuming any presence of the class means it could be called, which brings us back to the false positives problem. 

The key is a smart middle ground: modeling the framework behavior in the static analysis. Our engine does exactly that. We have built-in knowledge of common patterns in Spring (such as bean initialization and dependency injection), ASP.NET (e.g., dynamic controller instantiation), and other popular environments, so we simulate those calls in the call graph.

This kind of framework-aware analysis is non-trivial - it essentially means extending the static call graph with domain-specific knowledge. Many tools simply choose to ignore dynamic execution entirely because of the complexity. Our approach is far more comprehensive. We support not just a token set of frameworks, but continuously expand our models to cover common dynamic language features and patterns. Whether it’s Java reflection, .NET delegates, or even certain patterns in Python, our reachability engine is built to understand them.

Precision Matters in Reachability

Not all reachability analyses are equal. The technique and depth of analysis make all the difference between a nominal feature and a game-changing capability. By leveraging a sophisticated points-to analysis (PTA) engine, enriched with domain-specific models for frameworks and dynamic code, our SCA platform delivers reachability results that are both extremely precise and comprehensive. The outcome is a reduction of noise by over 93% across our customer base and virtually no blind spots in coverage.

For AppSec engineers, this means time back to focus on strategic security improvements rather than wading through false alarms. For CISOs and security leaders, it means a more accurate security posture - knowing that the vulnerability counts in your reports actually reflect exploitable risk, not just theoretical exposure. For Developers - this means evidence-based security findings backed by call stacks, therefore more trust in your AppSec teams and tools.

In summary, Hopper’s SCA solution distinguishes itself by doing reachability analysis the right way. Not as a checkbox, but as a core analytical engine rooted in program analysis research and real-world engineering. The difference is clear in the drastically quieter alert volume and the heightened confidence you can have in your security posture. When it comes to securing your software supply chain, accuracy is everything. By providing the most accurate reachability analysis on the market, we empower your team to move fast and fix things safely.

Last but not least, we invite AppSec teams to compare us against any other vendor on the same repository. Book a demo today. The difference will be obvious within minutes.