Reachability

Reachability

When a dependency has a vulnerability (i.e. a CVE), is that CVE really affecting my application?

Reachability, in a SCA (or vulnerability analysis) context, is a property of a vulnerability finding that indicates whether it will (or wont) be invoked under the software’s normal operational conditions.

Analyzing the reachability for a large set of vulnerability findings for a software is important.

Most of the SCA scanners work by extracting the dependency graph (direct and transitive/indirect dependencies) from manifest files (pom.xml, package.json etc.), and simply enumerate the known vulnerabilities that are listed in vulnerability databases (NVD and others). This gives many more findings that the real vulnerabilities that a potential adversary could exploit in the deployed software.

Most of those findings are NOT actually reachable, because although the dependency with the vulnerability is “imported” (in the component descriptors of the target software S and transitively on its dependencies), your application only uses a small portion of those components, not invoking the vulnerable code of the dependacny.

By focusing on reachable vulnerabilities only, the ones that exist within the code usage path of S, we focus on the vulnerabilities that can pose an actual risk. By doing so, we disregard the ones that, while present, may never be executed.

If your application invokes the vulnerable function, it is at risk because the issue is accessible. Conversely, if your app does not call this function, it remains unaffected and the issue is not present.

This means not only tracing direct calls to the vulnerable function, but also indirect or transitive calls.

Values for Reachability

• Reachable: An issue is flagged as reachable when the application's call graph can access the vulnerable method in the dependency, either directly or indirectly.

• Always Reachable: If an issue is flagged as always reachable, it is strongly recommended that the vulnerability be fixed regardless of your application code. This often occurs when the vulnerable part is unrelated to a specific dependency method.

• Potentially Reachable: An issue is flagged as potentially reachable when it's impossible to confirm its reachability or unreachability. Common reasons for this include unsupported call graph analysis for certain languages or package managers, insufficient information, and scenarios with dynamic or conditional invocations.

• Not reachable: An issue is flagged as not reachable when the application's call graph analysis determines that no function calls directly or indirectly invoke the vulnerable method in the dependency.

Do not confuse reachability with severity.

A low-severity and reachable vulnerability probably needs to be handled with a higher priority than an unreachable and critical one. But a critical unreachable vulnerability should not be muted/disregarded as reachability may change: the vulnerable code may become reachable after changes in the software (where adding a new call changes the call graph so the vulnerable function becomes reachable). An unreachable vulnerability is a latent one, probably harmless in the current version of the software.

Reachability should be considered as a main criteria for vulnerability prioritization (see Prioritization Funnels)