Over the past few years, AI assistants have made coding easier for developers in that one is able to quickly develop and push code over to GitHub, among others. But with so much automation going on, the risk of coding vulnerabilities has also increased. The vast majority of those generated codes have security flaws. What has befallen the application security teams is a lot of vulnerability reports pouring in. But lately, Snyk has found that 31% of these vulnerability reports are completely false positives added to the burden of security teams.

In such cases, many teams tend to use a method called reachability analysis, which usually helps the security expert screen out noise and work only with the vulnerabilities that might be exploited during an attack-upon only accessible code during said attack. Since only 10% to 20% of the imported code is even used by any application on average, this approach cuts the number of reported vulnerabilities that developers have to fix in half. Joseph Hejderup, technical staff member at Endor Labs, demonstrated this approach during the SOSS Community Day Europe 2024 and talked about how it makes vulnerability reports more actionable.

False Positive Overload

The biggest problem of application security is false positives. The sooner security teams can ship out more code, the larger their impact will be as your security tool begins to flag issues that are not actually a risk. According to Snyk, 61% of the developers believe that the enhancement of false positives is due to automation. To the eyes of the security teams, sorting hundreds or thousands reported vulnerabilities in numerous projects becomes a daunting task.

According to Randall Degges, head of developer relations at Snyk, reachability analysis helps by narrowing down exactly which vulnerabilities are really dangerous. This calms the security teams, since they can now focus on issues being actively executed in the code. Filtering out the kind of vulnerabilities that attackers cannot reach makes companies remediate by as much as 60%. And as OX Security research put it, in some cases, teams even reduced the workload by nearly 99.5%, making improvements to the developers.

Reducing developer friction

It's not just about workload reduction, but rather reporting fewer, more accurate vulnerabilities back to developers, says Katie Teitler-Santullo, a cybersecurity strategist at OX Security. "Tools that focus on real risks over bombarding developers with false alerts improve collaboration and efficiency," she says.

The hardest part is to eliminate the noise that security tools produce, keeping the developers in the same pace with the growth of development while still having a secure solution. Focusing on reachability ensures that the reported vulnerabilities are really relevant to the code being worked on, allowing developers to tackle key issues without fear of information paralysis.

Two Approaches to Reachability Analysis

There are two primary ways of reachability analysis. The first of these is static code analysis-in the process, the code itself is analysed and a graph of function calls is constructed to determine whether vulnerable code can be executed. This method works but is not failsafe as some of the functions may only be called under specific conditions.

The second approach involves instrumenting the application to track code execution during runtime. This really gives a live snapshot of which parts are really being used, so you will be able to immediately know if the identified vulnerability is something that poses an actual threat.

While the current reachability analysis tools mainly focus on whether code is being executed, the future of this technology involves determining if vulnerable code is indeed exploitable. According to Hejderup, the next step in reaching that milestone of making security testing even more effective would be the combination of reachability with exploitability analysis.

Finally, reachability analysis offers an effective solution to the problem of vulnerability overload. This is because it allows security teams to remove extraneous reports and focus only on reachable, exploitable code. This approach reduces workloads and generates better collaboration between security teams and development teams. As companies adopt this way of doing things, the future of application security testing will be more complex, such that only the most crucial vulnerabilities are flagged and then fixed.

Reachability analysis isn't going to be a silver bullet, perhaps, but it is going to be a pretty useful tool in an era where code is being developed and deployed faster than ever-and the risks of ignorance on security have never been higher.