Beyond detection: Understanding vulnerability reachability in SCA

Jun 30, 2025 / 6 min read

Table of Contents

What is vulnerability reachability in SCA?
How reachability helps prioritize risk in SCA
Limitations of static reachability analysis
Black Duck’s comprehensive vulnerability triage framework

In 2024, more than 40,000 Common Vulnerabilities and Exposures (CVEs) were created and disclosed for vulnerabilities in open source software. Couple this with our own research indicating that the average commercial codebase contains 911 open source dependencies, and it’s easy to understand how security and development teams are becoming increasingly overwhelmed by the number of vulnerabilities they’re forced to content with on a daily basis. As a result, they need ways to prioritize which issues introduce the most risk and should be resolved first. This is where the concept of reachability comes into play.

Key takeaways

Vulnerability reachability assesses whether a vulnerable code path is actually executable in your application.
In 2024, over 40,000 new open source CVEs were disclosed, with an average commercial codebase holding 911 dependencies.
Reachability reduces alert fatigue by deprioritizing unreachable vulnerabilities—but dynamic code and injections can cause false negatives.
Black Duck augments SCA with reachability analysis (Java-only), BDSA mappings, Source Match View, CVSS, CISA KEV & EPPS scoring.
Combined metrics and customizable policy management let teams automatically triage and act efficiently.

Get a closer look at Black Duck SCA

What is vulnerability reachability in SCA?

Vulnerability reachability refers to the analysis of whether a vulnerable code path can be executed in a specific context. This helps draw a clear delineation between vulnerabilities that are associated with application dependencies, and those that can, or might, be executed.

For example, let’s say you include Apache Commons Collections in your Java web application. Here’s what your software composition analysis (SCA) tool might detect

Library: commons-collections 3.2.1
Vulnerability: CVE-2015-6420
CVSS score: 9.8 (Critical, remote code execution)
CVE description: The InvokerTransformer class can be exploited when used in Java deserialization chains (commonly with ObjectInputStream or other deserialization mechanisms)
Recommendation: Patch immediately

How reachability helps prioritize risk in SCA

When the SCA tool returns this finding, it would be a no-brainer for teams to drop everything they’re doing, treat this issue as a “priority 0” vulnerability, and do whatever they need to do to fix it, even if it means creating downstream issues to application functionality. However, performing a reachability analysis on this vulnerability might reveal a different story.

A call graph analysis finds that your application does not include any usage of the Java deserialization APIs (ObjectInputStream)
The InvokerTransformer class is never imported or referenced in the codebase
Despite the vulnerable class existing in the dependency, it is never invoked or accessible by any code path form the application

With these facts in mind, teams can reasonably conclude that the exploit conditions can’t be met given the current state of the application, which negates the risk and bumps this vulnerability down to a much lower priority. While there is always risk associated with high-severity vulnerabilities like this one, teams can use reachability to ensure that they’re not neglecting more-exploitable vulnerabilities by burning cycles on ones like these.

Limitations of static reachability analysis

There’s no question that reachability adds helpful context to the vulnerability prioritization workflow, but it’s important to recognize that it should never be used alone, and that it has several limitations and shortcomings.

False positives: Reachable but unexploitable code

When an SCA tool finds that a vulnerability is reachable, it means your application uses or calls a part of a library that contains a known library. This is an important detail, but it doesn’t mean that someone can actually exploit it. For vulnerability to be exploitable, an attacker must be able to actually trigger the vulnerable code and inflict damage via data leak, remote access, arbitrary code execution, etc. Simply put, reachable vulnerabilities aren’t always threats. Here are some examples.

Several vulnerabilities require specific, well-formed input to be exploited. If your application never accepts or processes user input in the way the vulnerable code expects, the danger isn’t present.
Some vulnerable functions or methods are only called in restricted features, available only to administrators or internal teams. If users or attackers can’t break that barrier, there is minimal threat.
Even if vulnerable code is exposed, your application may sanitize inputs, check permissions, or use firewalls that prevent certain attacks from succeeding.
Reachability analysis often errs on the side of evaluating if vulnerable code could be called. This often flags a vulnerability as reachable, and it might be in theory, but there is no danger under the production conditions.

False negatives in dynamic or injected code

False positives contribute to vulnerability overload and alert fatigue. Despite this, many teams would still prefer to err on the side of caution and deal with false positives. However, reachability analysis might also return false negatives, which gives teams a false sense of security when it incorrectly evaluates a vulnerability as not reachable.

When an application loads or invokes code dynamically at runtime, like Java, JavaScript, and Python, reachability analysis often struggles to accurately resolve their call paths.
Some frameworks, like Spring and .NET, use dependency injection to spin up classes and methods at runtime, which is not obvious in static code.
When an application calls into another language, like JavaScript calling native code, a reachability scan will likely miss the call paths that cross the language boundary.
Many static analysis tools miss deep transitive dependencies, prune complex or ambiguous flows, and ignore unusual control flows to keep scans fast.

Black Duck’s comprehensive vulnerability triage framework

Just like anything else in cybersecurity, there is very rarely a silver bullet that solves the problem. A comprehensive, tailored approach is often the recommendation. A combination of metrics and data, aggregated into a context-aware view will always be the most effective approach, offering more productive insights than a single point of view. This is why Black Duck offers customers several metrics for determining their exposure to the vulnerabilities our SCA solutions identify.

Comprehensive open source identification

Black Duck solutions provide multiple methods to accurately identify dependencies, and their effective versions, in projects, regardless of tech stack, language, or access to build systems and source code. Accurately identifying dependencies is the first step to avoiding false positives and false negatives in vulnerability alerts.

Black Duck Security Advisory (BDSA) mappings

Most vulnerabilities have an associated BDSA, which is human curated and tempered to remove any inaccuracies introduced by feeds like the NVD. BDSAs are issued, with full details, within hours of the public disclosure of a vulnerability.

Source match view

For every dependency identified, Black Duck provides information on how the component was identified, how it was introduced to the project, and where in the project structure it is being used. Development teams have a better idea of their project structure than any automated tool can ever have, so Black Duck arms them with the information needed to quickly assess whether a vulnerable component is actually being called or otherwise shipped with the application.

Reachability

Black Duck reachability data is populated using a mix of human curation and static analysis to determine the call path of certain dependencies. At this time, it is only available for Java projects, but it can be used as another key insight for vulnerability prioritization.

Common Vulnerability Scoring System (CVSS) scores

CVSS rates security vulnerabilities on a scale from 0.0 to 10.0, with higher scores indicating greater severity. The score considers factors like ease of exploitation, potential impact, and environment-specific risks to help prioritize security threats. BDSAs include custom CVSS scores; these scores include temporal metrics which give teams a more accurate snapshot of vulnerability severity.

CISA Known Exploited Vulnerabilities (KEV)

CISA KEV is a catalog of vulnerabilities that have been actively exploited in the wild. Black Duck tags associated vulnerabilities so users can apply this information in their triage efforts. Some software vendors are required to patch these vulnerabilities or face penalties from the U.S. government.

Exploit Prediction Scoring System (EPSS)

EPSS estimates the likelihood that a vulnerability will be exploited in the wild within the next 30 days. This scoring system helps prioritize vulnerabilities by considering real-world exploit data, machine learning models, and factors like CVSS scores, exploit code availability, and attacker behavior. EPSS scores range from 0 to 1, where higher values indicate a greater probability of exploitation. This metric is offered by Black Duck Binary Analysis, which helps teams on the operational side triage vulnerabilities.

Conclusion

All this information is equally important when evaluating the severity of a vulnerability and prioritizing which should be fixed and when. A combination of these metrics, which Black Duck SCA solutions automatically provide, helps teams determine whether to upgrade, fix, or override their findings. And custom policy management helps teams automate this process to remove the guesswork, standardize an approach, and make sure no issue goes unchecked.

Interested in learning more about how Black Duck evaluates vulnerabilities? Check out our webinar for a closer look at our vulnerability research team.

Watch the Webinar