Reachability
Last updated
Last updated
When a dependency has some 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 will not) 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 works 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 can exploit in the real deployed software.
But most of those findings are NOT actually reachable, because although the dependency with the vulnerability V is “imported” (in the component descriptors of the target software S and transitively on its dependencies), it only uses a small portion of those components, not invoking the vulnerable code for V.
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.
Your app may either be calling the vulnerable function or not. If you are not calling the vulnerable function, your app is not affected (the related issue is not reachable). Instead, if you are calling the vulnerable method, your app is at risk and the issue is reachable.
And this means not only tracing direct calls to the vulnerable function, but also indirect or transitive calls.
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 reachable vulnerability probably needs to be handled with a higher priority than an unreachable critical one, but a critical unreachable vulnerability should not be muted / disregarded as reachability may change in time: the vulnerable code may become reachable after changes in software S (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 S.
Reachability should be considered as a main criteria for vulnerability prioritization (see Prioritization Funnels)
