Reachability Analysis Pares Down Static Security-Testing Overload

Source: Photon Photo via Shutterstock

AI assistants are a double-edged sword for developers. On one hand, code-generation assistants have made creating barebones applications easier and led to a surge in code pushed to GitHub. Yet just as easy? Generating code with defects and vulnerabilities.

As a result, application security teams serving large development groups are seeing growing application vulnerability reports — a large portion of which are false positives. In fact, nearly a third of teams (31%) find the majority of reported vulnerabilities are false positives, according to software security firm Snyk’s “2023 State of Open Source Security” report.

In the face of growing volumes of code submissions and continuing problems with false positives, application security teams are relying on reachability analysis as an important way to prioritize their remediation requests. Because only 10% to 20% of imported code is typically used by a specific application, determining whether the code is reachable by an attacker — and thus likely exploitable — can dramatically reduce the number of vulnerabilities that need to be patched, says Joseph Hejderup, technical staff member at Endor Labs, who presented on the topic at SOSS Community Day Europe 2024 in September. This makes it possible to prioritize vulnerability reports, he says.

“With software composition analysis — without looking into the code — we are essentially assuming that if you use this library, you’re using all this functionality, where in reality we know that you’re only using part of the library,” Hejderup says. “By going down to the source code, you can see whether this particular vulnerable part of the code is used or not used.”

Static application security testing (SAST) tools continue to evolve and have a proven return on investment (ROI), especially if they are used to catch software defects during development time, when the cost of fixing a bug is lower. However, false positives reduce the benefits of SAST tools and undermine developer trust in the tools.

False Positives, Lack of Context Remain Problems

Overall, 61% of developers believe the faster cadence of development with automation has increased the number of false positives, according to Snyk’s report. For application security teams, finding ways to reduce the volume of vulnerabilities discovered in dozens or hundreds of projects into a more manageable burden is critical, says Randall Degges, head of developer relations at Snyk.

“Each of those projects has hundreds — maybe thousands of vulnerabilities — and a lot of them look scary, like these critical RCE vulnerabilities,” he says. “Reachability is really a nice way to kind of calm yourself down as a security team and not stress your teams out because, if you’re able to successfully filter the vulnerabilities that you see based on, ‘Are they even being executed, like in our code base or not,’ that’s a really big benefit to security teams.”

Overall, companies can reduce their remediation work by 60%, just by excluding unreachable code. One study found that, while 71% of Java applications consist of open source code, applications used only about 12% of that code.

Combining reachability with other contextual information — such as exploitability and business impact — reduces the workload even further. In an analysis of 106 million alerts from 900 organizations, or an average of about 118,000 alerts per organization, reachability analysis reduced the workload by 99.5% — or down to about 660 alerts per organization, according to application security firm OX Security.

Reporting fewer vulnerabilities back to developers can help reduce friction between the two groups, says Katie Teitler-Santullo, cybersecurity strategist with OX Security.

“A lot of the frustration happens because tools aren’t able to reduce the noise and focus on the prioritization that developers need [in order] to move at the speed of development versus the speed of security,” she says.

Source Code Analysis or Instrumentation

Typically, there are two approaches to reachability analysis. One is static code analysis focused on building graphs of the function calls in the applications and determining whether specific code can be executed. The determination is not always simple: A conditional statement may be executed only once in hundred or thousands calls — or never — and so application security tools have to determine whether that constitutes a threat.

Snyk, for example, errs on the side of work reduction. If there is a conditional statement, the company’s tools will ignore the minor branches and just focus on the likely outcome, says Snyk’s Degges.

“We look for things where we can 100% definitively trace it down there, and say that, 'Yes, this is reachable,’” he says. “The trade-off for that is that some things may be marked as not reachable, even though they are. But the benefit is that people aren’t getting a bunch of false alerts.”

Another approach is to instrument the application and the code, determining at runtime what functions are being executed and label that code as reachable.

Whether a vulnerability in the code can be exploited is another level of investigation. Endor Lab’s Hejderup expects companies to be able to filter down to code that is reachable and provably exploitable as the next step.

“This type of more advanced, sophisticated analysis would likely be the next level within reachability analysis,” he says.

About the Author

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT’s Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline Journalism (Online) in 2003 for coverage of the Blaster worm. Crunches numbers on various trends using Python and R. Recent reports include analyses of the shortage in cybersecurity workers and annual vulnerability trends.