Reachability Analysis: How to Eliminate False Positive SCA Alerts
Reachability analysis determines whether vulnerable code in a dependency is actually called by your application. By tracing call graphs and data flows from your code into third-party libraries, reachability analysis eliminates 60-95% of false positive SCA alerts — only flagging vulnerabilities your application can actually trigger.
Why Reachability Analysis Matters for Application Security
The average enterprise application pulls in hundreds of open-source dependencies, each bringing its own transitive dependency tree. When a CVE is published against any component in that tree, traditional SCA tools flag it regardless of whether the vulnerable function is ever executed.
The result is staggering noise. Research consistently shows that 60-80% of flagged dependency vulnerabilities exist in code paths no application ever calls (Endor Labs, “State of Dependency Management,” 2024). Organizations running multiple scanners — 5.3 tools on average per team — compound the problem, with the same unreachable CVE appearing across every dashboard.
Teams with 100,000+ vulnerability backlogs (66% of organizations, per industry surveys) spend 50-80% of AppSec capacity on manual triage. Mean time to remediation stretches to 252 days. False positive rates from traditional SCA scanners run between 71% and 88%.
Reachability analysis directly attacks this problem. Instead of treating every CVE as equally urgent, it asks a precise technical question: Does my application actually call the vulnerable function? When the answer is no, the alert can be safely deprioritized — or eliminated entirely.
For teams evaluating SCA solutions, Forrester now treats reachability as a baseline expectation. The 2024 Forrester Wave for SCA explicitly evaluates whether tools prioritize “vulnerabilities by using criteria such as exploitability, maturity, effort to fix, [and] reachability (whether the vulnerable method is called)” (Forrester, “The Forrester Wave: Software Composition Analysis, Q4 2024”). GitLab’s lack of reachability analysis was specifically cited as preventing it from achieving an on-par developer experience score.
Reachability is no longer a differentiator. It is table stakes.
How Reachability Analysis Works
Reachability analysis maps the execution paths between your application code and the functions exposed by its dependencies. The core mechanism is call graph construction — building a directed graph of which functions call which other functions, from your entry points down through every layer of the dependency tree.
Dependency resolution
The tool parses your manifest file (package.json, pom.xml, requirements.txt, go.mod) and resolves the full dependency tree, including transitive dependencies.
Call graph construction
Static analysis traces function calls from your application code into dependency code. This produces a graph showing which dependency methods are actually invoked.
CVE-to-function mapping
When a CVE is published, the analysis maps the vulnerability to the specific function or code path it affects — not just the package version.
Reachability verdict
If no execution path connects your application code to the vulnerable function, the vulnerability is marked unreachable. If a path exists, it is marked reachable and prioritized for remediation.
Your application depends on lodash@4.17.20, which has a known prototype pollution vulnerability in lodash.merge(). Reachability analysis traces your code’s call graph and finds that your application imports lodash.get() and lodash.debounce() but never calls lodash.merge(). The vulnerable function is unreachable — the CVE is real, but it cannot be triggered in your application. Deprioritize.
Your Application ├── imports lodash.get() ← Used (no CVE) ├── imports lodash.debounce() ← Used (no CVE) └── lodash.merge() ← NEVER CALLED (CVE-2020-28500) Verdict: UNREACHABLE → Deprioritize
Static vs. Runtime Reachability
Two approaches exist, and the distinction matters:
Static reachability
Static reachability analyzes source code without executing it. It builds call graphs from code structure alone. This is the most common approach — it works in CI/CD pipelines, requires no production instrumentation, and catches issues before deployment. The tradeoff is potential over-approximation: static analysis may flag paths that are theoretically reachable but practically never executed (e.g., dead code behind feature flags).
Runtime reachability
Runtime reachability instruments production applications to observe which dependency functions are actually loaded into memory and executed. Mend.io pioneered this approach through its Sysdig partnership, providing both static and runtime signals (Forrester Wave SCA, Q4 2024). Runtime reachability is more precise but requires production access and only reflects currently observed behavior — it can miss code paths triggered by rare events.
Most mature SCA programs use static reachability as the default triage layer, with runtime data as supplementary evidence for high-stakes decisions.
How Pixee Uses Reachability Analysis
Pixee’s approach to reachability is fundamentally different from detection-only tools. Where most SCA vendors use reachability to generate smarter alerts, Pixee uses it to generate smarter fixes.
False positive reduction
Pixee’s triage automation combines reachability analysis with broader exploitability context — EPSS scoring, deployment configuration, internet-facing exposure, and data sensitivity. Reachability is one input into a multi-dimensional assessment that reduces false positives by 95% across 10+ scanner tools. This is not call-graph-only filtering. It is evidence-based exploitability validation that proves whether an attacker can actually reach the vulnerable code in your specific environment.
Merge rate
When reachability confirms a vulnerability is exploitable, Pixee does not stop at an alert. It generates a context-aware pull request that fixes the vulnerability — updating the root dependency in the manifest file, predicting breaking changes with 80-90% confidence, and matching your codebase’s coding conventions. Across 100,000+ PRs, 76% are merged by developers without modification.
This is the critical difference. Endor Labs provides function-level reachability and claims 92% noise reduction — but it is detection-only. Developers still have to manually fix every confirmed vulnerability. Pixee closes the loop: reachability-informed triage feeds directly into automated remediation.
Pixee is also scanner-agnostic. Whether your SCA findings come from Snyk, Checkmarx, Black Duck, or any combination of tools, Pixee ingests the alerts, applies reachability-informed triage, and produces merge-ready fixes. You do not need to replace your scanner. You need to resolve what it finds.
Industry Context
Reachability analysis has moved from emerging capability to evaluation criterion in under two years.
- Forrester (2024): The Forrester Wave for SCA evaluates reachability as a core prioritization criterion alongside exploitability, effort to fix, and production context. GitLab was specifically penalized for lacking it (Forrester Wave SCA, Q4 2024).
- Gartner (2025): Mend.io’s acquisition of Atom Security to extend reachability from code to runtime containers was noted as a strategic move (Gartner MQ Application Security, Q4 2025).
- Endor Labs (2024): Claims function-level reachability with 92% noise reduction, positioning it as their primary SCA differentiator.
- VEX integration: Reachability results feed directly into VEX (Vulnerability Exploitability eXchange) documents. When a CVE is proven unreachable, it can be tagged with a VEX status of “Not Affected” — providing auditable evidence for compliance teams.
Frequently Asked Questions
Reachability analysis determines whether vulnerable code in a third-party dependency is actually called by your application. By constructing call graphs that trace execution paths from your code into dependency libraries, reachability analysis identifies which CVEs can actually be triggered in your environment. Vulnerabilities in functions your application never calls are unreachable and can be safely deprioritized, eliminating 60-95% of false positive SCA alerts.
Traditional SCA tools flag every known vulnerability in your dependency tree, regardless of whether the vulnerable function is used. Reachability analysis filters this list by tracing which dependency functions your application actually calls. Since 60-80% of dependency CVEs exist in unreachable code paths, reachability eliminates the majority of false positives. This lets security teams focus remediation effort on the vulnerabilities attackers can actually exploit.
Static reachability analyzes source code structure to build call graphs without executing the application. It works in CI/CD pipelines and catches issues pre-deployment, but may over-approximate by flagging theoretically possible paths. Runtime reachability instruments production applications to observe which dependency functions are actually executed, providing higher precision but requiring production access and only reflecting currently observed behavior. Most mature programs use static reachability as the primary triage layer.
Related Topics
Software Supply Chain Security: The Complete Guide
The pillar page covering the full landscape of dependency security, from SBOM to automated remediation.
Exploitability Context
Reachability is one dimension of exploitability. Learn how EPSS scoring, deployment context, and data sensitivity combine with reachability for full prioritization.
VEX Explained
How reachability results translate into VEX status codes for compliance reporting and audit evidence.
The SCA Problem, Framed
Why traditional SCA creates more noise than signal, and what a resolution-first approach looks like.
Introducing Pixee SCA
How Pixee brings triage automation and dependency remediation to the software supply chain.
See Reachability Analysis in Action
If your team is spending more time triaging SCA alerts than fixing real vulnerabilities, reachability-informed triage and automated remediation can change that equation. See how Pixee applies reachability analysis across your existing scanner stack — reducing false positives by 95% and producing merge-ready fixes at a 76% merge rate.