TL;DR: Due to complex dependency layers and static analysis limitations, transitive reachability analysis struggles to deliver actionable insights.
Introduction
How do you manage vulnerabilities in transitive dependencies, e.g., fourth, fifth, sixth, or deeper-level packages? Vendors who offer transitive reachability will tell you this is a much-needed feature, especially given >90% of your dependency vulnerabilities are likely introduced via transitive dependencies.
This blog discusses why reachability analysis, which examines your codebase to assess where and how you use vulnerable open-source dependencies, is highly effective for direct dependencies but is lackluster when applied to transitive dependencies.
If you haven’t already, check out Should security engineers care about transitive supply chain vulnerabilities?
In this blog post, we’ll explore why Semgrep Supply Chain continues to be the favorable solution despite not offering transitive reachability.
Reachability analysis
Software composition analysis (SCA) tools have historically had a bad reputation. Fortunately, we now understand that simply identifying and correlating the project's dependencies with a vulnerability database does not work. This creates too much noise, leading to analysis paralysis, only to discover that >90% of vulnerabilities are false positives.
This isn’t surprising, given that we live in a world with over 250,000 CVEs and projects often using thousands of open-source packages.
That’s where reachability comes into play. By determining if there are any call paths from your codebase to a known vulnerable function, you can significantly reduce the number of false positives outputted by an SCA tool. With the help of the Semgrep engine, our supply chain security product is one of the few solutions on the market offering this prioritization feature.
How effective can it be? Well, a Semgrep study from 2022 assessed 1,100 open-source projects. Of 1,614 Dependabot alerts, Semgrep’s reachability analysis determined that only 31 were reachable in the project’s code - making only ~2% of findings reachable!
Reachability analysis has different meanings depending on the vendor. For example, some vendors use call graphs, whereas Semgrep uses its static analysis engine. Therefore, Semgrep can tell you not just when you use a vulnerable function but when you use it in a vulnerable way. Additionally, Semgrep can provide direct references to the lines of code affected, simplifying triage efforts.
The harsh reality of transitive reachability
Despite its theoretical advantages, the implementation and outcomes of transitive reachability analysis have highlighted significant issues, primarily concerning the actionability of its findings and the prevalence of false positives.
Low actionability of findings
The main challenge with the findings from transitive reachability analysis is their limited actionability:
Complex dependency layers: Many applications use dozens of libraries, each with its own dependencies, creating deeply nested dependency trees. Vulnerabilities identified in these distant layers often do not pose a direct threat because they are not accessible or exploitable via the primary application paths despite being “reachable” via static analysis.
Remediation challenges: Even when a transitive vulnerability is identified, you are at the mercy of the parent dependency’s maintainers. Leaving you with limited options:
Create a pull request for the parent package to update the vulnerable dependency, hope it gets merged, and then update the parent package in your project.
Pin a patched version in your project’s lockfile, which can introduce unknown business logic flaws, often resulting in more risk than the original vulnerability.
Replace the parent package with an alternative package that is not reliant on the known vulnerable package, often requiring significant code refactoring.
High rate of false positives
The methodology typically employed in transitive reachability analysis, static analysis, exacerbates the problem by contributing to a high rate of false positives:
Limitations of static analysis: Static analysis assumes every conditional branch and loop might run, despite some paths potentially never being executed due to runtime conditions, causing inaccuracies in the analysis. These limitations are manageable when dealing with a single project but inevitably cause too many false positives in the context of transitive vulnerabilities.
Limitations of Call Graph Analysis: Current vendors utilize call graph analysis for transitive reachability, often mislabeling vulnerabilities as "reachable" when specific real-world conditions, like certain parameter configurations, are unmet. Tools like Semgrep improve accuracy by using abstract syntax trees (ASTs) to assess parameter usage, better reflect execution context, and reduce false positives by differentiating between theoretical and actionable vulnerabilities.
Making an actual impact with SCA
Semgrep has chosen to focus on enhancing direct dependency analysis and other more impactful areas, e.g.,
License Compliance - Enables you to explicitly allow or disallow (block) a package's use in your repository based on its license
Dependency Search - Accelerate incident response by searching if and where you use a vulnerable dependency across all your repositories, all in one place
SBOM Generation - Generate a software bill of materials (SBOM) to assess your third-party dependencies and comply with auditing procedures
This strategic focus ensures that our efforts align with providing tangible improvements in application security. With that in mind, we are actively working on features to make transitive vulnerabilities more actionable. Some areas of exploration include Path-to-Transitivity, which can provide insight into a project’s dependency tree, allowing you to understand the root cause of transitive findings.
User feedback consistently shows a preference for tools that deliver direct and immediate benefits rather than those offering broad but less actionable data. This preference aligns closely with Semgrep's philosophy of empowering developers to fix issues, not just find them. Our users prioritize accuracy and actionability, areas where transitive reachability currently underperforms.
Conclusion
Transitive Reachability’s challenges of low actionability, high false positives, and significant resource demands make it less attractive. Semgrep’s commitment to delivering high-quality, impactful security tools means focusing on areas that directly enhance the user's ability to detect and remediate vulnerabilities. Therefore, at least for now, transitive reachability falls short on our list of must-have features.
In line with our strategic focus on impactful security tools, we are continuously monitoring the evolving landscape of dependency management. We remain hopeful about delivering meaningful solutions for reducing noise and remediating transitive vulnerabilities in the near future.
