Page 255 - Cyber Defense eMagazine September 2025

How does SCA Reachability Work in Practice?

Reachability analysis comes in different flavors, each offering a different balance of precision and
breadth. Understanding these helps you see why it’s such a powerful tool for security teams and
developers alike.

The most precise approach is code-level reachability. This method inspects your application’s call graph,
essentially a map of how functions call one another, and checks whether the vulnerable function is ever
invoked, either directly or indirectly. If the function doesn’t appear in any execution path, the vulnerability
is marked as not reachable.

A classic example comes from a well-known jQuery vulnerability, CVE-2014-6071, which allows remote
attackers to conduct cross-site scripting (XSS) attacks via vectors related to use of the text() method
when used together with after(). If your code never uses that exact combination, then the vulnerability
cannot be triggered in your environment. Your SCA tool might still flag it, but an SCA reachability analysis
would let you confidently deprioritize it.

The broader, less precise approach is dependency-level reachability. Here, the question is not “is the
vulnerable function called?” but rather “is the dependency itself used at all?” If the answer is yes, it’s
flagged as potentially reachable. This method doesn’t pinpoint exact execution paths, but it can still help
you understand whether a vulnerable component plays any role in your application.

Finally, there’s the distinction between always reachable and not reachable vulnerabilities. Some code
runs automatically at startup, on every request, or during critical initialization processes. If that code
contains a vulnerability, it’s inherently high priority because it’s executed every time the application runs.
By contrast, if a vulnerable function exists in a code path that is never called, it poses no immediate risk,
though it should still be monitored for future changes.

Why Exploitability Completes the Picture

Reachability tells you whether the vulnerable code can be executed in your application. Exploitability
takes it one step further: is there a practical, real-world way for an attacker to take advantage of it?

This matters because not all reachable vulnerabilities are equally dangerous. A reachable vulnerability
that has a known public exploit, especially one that’s being actively used in attacks, is an urgent, drop-
everything issue. A reachable vulnerability with no known exploit is still important, but its priority might be
lower in a high-volume environment where triage is essential.

Severity ratings alone don’t reflect this reality. A “low severity” reachable vulnerability in a login endpoint
with a known exploit can cause far more damage than a “critical” vulnerability in a rarely used admin
feature that’s not even exposed to the internet.

By combining reachability with exploitability, you start to see vulnerabilities not as abstract risks but as
concrete threats, ranked by their actual potential to cause harm in your specific context.

Cyber Defense eMagazine – September 2025 Edition 255
Copyright © 2025, Cyber Defense Magazine. All rights reserved worldwide.