Reachability Analysis: Evolving from Package-Level to Function-Level 

by Ali Naqvi

Software development today is significantly different from what it was a few years ago. More open-source packages are being embedded in code today than ever before. In their 2024 Open-Source Security and Risk Analysis Report, Blackduck states, "Seventy-seven percent of all code in the codebases originated from open source. Every industry codebase scanned contained open source—most at percentages from 99% to 100%." Open-source third-party libraries and dependency packages significantly speed up development through contributions from the open-source community. Third-party libraries and dependency packages come with their challenges. A threat actor can create an exploit to compromise a dependency package. This could compromise any software built using these dependency packages. This is where reachability scans by vulnerability scanners started to gain popularity. When reachability scanning first became popular, it was rudimentary. Most scanning tools would investigate your application code and determine whether the vulnerable package was imported anywhere in the application.

This approach is better than not doing a reachability scan, although it yields many false positives. From 2010 to 2020, scanners focused on context-aware scanning at the package level, which helped security analysts better understand the reachability of a vulnerable dependency package. For example, suppose a security analyst conducts a package-level reachability scan for the widespread Log4Shell vulnerability in the Apache Log4j 2 package (CVE-2021-44228). In that case, the scanner will flag the Log4j package as vulnerable, even if it has not been used in the application code. This made the vulnerability seem more significant in many instances than it was. Many applications may include Log4j as a nested dependency without invoking the specific JndiLookup class or configurations required to exploit Log4Shell.

In the last couple of years, function-level reachability has become a critical feature for security analysts in their application scanners. Function-level scanners provide deeper analysis when they scan dependency packages. Rather than scanning for vulnerabilities at a package level and generating numerous alerts for using a vulnerable package, the scanner now identifies vulnerabilities at a function level. This is a shift in scanning from a reactive "scan and detect everything" approach to a more proactive-focused approach. If the scan were a function-level reachability scan for the Log4Shell vulnerability, it would determine how the Log4j library was used within the application code. The scan can analyze and see if the JndiLookup functionality is exploitable and assess whether it is in vulnerable paths. This gives a more accurate analysis of the Log4j package being vulnerable, reducing false positives. This detailed analysis will help security analysts prioritize and allocate resources effectively to remediate the vulnerability. Security analysts can decide whether to update the dependency package to the next non-vulnerable dependency package or accept the risk and continue utilizing the same dependency package.

Although function-level dependency is a big step forward for application security analysis, it is not a silver bullet. It still comes with several challenges. Analyzing function-level reachability for a complex application requires the scanning tool to traverse multiple layers of dependency packages that are deeply nested by calling packages that rely on other dependency packages. This can impact the overall speed at which the security analyst can identify risks in their organizations. Another major challenge is that function-level scanning, although better than package-level scanning, can still have false positives (flagging non-exploitable functions) and false negatives (not detecting exploitable paths). Function-level reachability analysis is also programming language-dependent. Most scanners support a limited number of programming languages. There is usually support for popular languages like Java, JavaScript, and Python. Other languages like Golang, Rust, and Perl are generally unsupported. Finally, the last drawback of function-level analysis is the difficulty of tracing code that has been obfuscated for security purposes. This forces scanners to try and make an educated guess on what functions will be vulnerable or just default back to a package-level analysis.

In conclusion, you must scan your application for security vulnerabilities as a security analyst. If you are budget-conscious and have the resources, you can use open-source scanners to perform package-level scanning, which will get you a step further than not scanning at all. The best option today is to get a function-level scanner for reachability. Function-level reachability provides a more detailed analysis of dependency packages that the security analyst should use. This analysis reduces noise by examining the function to determine if the function is exploitable. It also increases efficiency by reducing the number of alerts generated and false positives, allowing you to spend less time triaging and more on remediation. This is particularly important for mid-to-large organizations, where developers and security teams already face a heavy workload.