Reachability Analysis in SCA

What Is Reachability Analysis in SCA?

Reachability analysis is a technique used in software composition analysis (SCA) to determine whether a known vulnerability in an open source dependency can actually be triggered by your application's code paths. Rather than simply flagging every CVE associated with a library, it traces whether the specific vulnerable function or method is ever called at runtime.

This distinction matters enormously for security teams. A library may contain dozens of known vulnerabilities, but if your application never invokes the affected functions, those vulnerabilities carry no practical exploitability risk.

Reachability analysis answers a more precise question than traditional SCA: not just "does this vulnerable component exist in our dependency tree?" but "can this vulnerability actually be reached and exploited in our application?"

How Reachability Analysis Differs From Standard Dependency Scanning

Standard dependency scanning works by comparing your project's dependency manifest against a database of known vulnerabilities, such as the NVD or OSV. It produces a list of every CVE associated with every component you use, direct or transitive.

This approach is fast and broad, but it comes with a major drawback. It treats all vulnerabilities equally, regardless of whether your code ever touches the vulnerable logic.

Reachability analysis goes further by performing call graph analysis. It maps how your application's code interacts with third-party libraries and traces execution paths to determine which vulnerable functions are genuinely reachable.

Key differences include:

Dependency scanning flags vulnerabilities by presence; reachability analysis flags them by exposure.
Dependency scanning is faster but generates significantly more noise.
Reachability analysis requires deeper code analysis and more compute resources.
Reachability results are more actionable for developers prioritizing fixes.

Why False Positives in SCA Make Reachability Analysis Essential

The false positive vulnerability problem in SCA is well documented. Studies consistently show that a substantial portion of flagged CVEs in any given codebase are unreachable in production. Some estimates suggest this figure can exceed 70% or even 80% in mature applications with complex dependency trees.

When every scan returns hundreds of critical alerts, security teams experience alert fatigue. Developers begin to deprioritize vulnerability remediation because the signal-to-noise ratio becomes unworkable.

Reachability analysis directly addresses this problem. By filtering out vulnerabilities tied to code paths your application never executes, it produces a smaller, higher-confidence set of findings that genuinely require attention.

The business impact is real:

Fewer wasted engineering hours on non-exploitable vulnerabilities.
Faster remediation cycles for vulnerabilities that actually matter.
Improved trust between security teams and development teams.
Stronger compliance posture when reporting on exploitable risk.

Integrating Reachability Analysis Into CI/CD Pipelines

Embedding reachability analysis into CI/CD pipelines allows teams to assess exploitable risk at every stage of the software development lifecycle. Rather than running periodic audits, teams receive continuous, contextual feedback tied directly to code changes.

Effective integration typically involves:

Running reachability-enabled SCA scans during pull request checks.
Configuring pipeline gates that block merges only for reachable, high-severity vulnerabilities.
Sending reachability-filtered alerts to developer-facing dashboards rather than overwhelming ticketing systems.
Pairing results with OSS vulnerability scanning practices to maintain full visibility.

When combined with container scanning best practices, reachability analysis provides a layered view of risk from source code through deployment. Teams can confidently distinguish between theoretical risk and genuine threat.

FAQ

What percentage of CVEs are typically unreachable in production code?

Research and industry reports suggest that between 70% and 85% of CVEs flagged by standard dependency scanning tools are unreachable in production applications. This figure varies by codebase size, language, and dependency complexity. Reachability analysis helps teams focus remediation efforts on the minority of vulnerabilities that carry genuine exploitability risk.

Can reachability analysis work across all programming languages?

Not equally. Reachability analysis performs best with statically typed languages like Java and Go, where call graphs are easier to construct accurately. Dynamic languages such as Python, JavaScript, and Ruby present challenges due to features like reflection and dynamic dispatch, which can cause tools to miss legitimate execution paths or produce inaccurate results.

How does reachability analysis handle transitive dependencies?

Reachability analysis traces call chains through transitive dependencies by building multi-layer call graphs. If your code calls Library A, which calls a vulnerable function in Library B, the analysis should surface that path. However, accuracy depends on tool capability, and deep transitive chains in dynamic languages remain a common source of incomplete or imprecise results.

Does reachability analysis eliminate the need for manual code review?

No. Reachability analysis reduces noise and helps prioritize findings, but it does not replace human judgment. Manual code review remains essential for understanding business logic, contextual risk, and vulnerabilities that automated analysis may miss. Treat reachability analysis as a filtering and prioritization layer within a broader security review process, not a complete substitute.

How does reachability analysis differ from static application security testing?

Static application security testing (SAST) analyzes first-party code for security flaws like injection vulnerabilities or insecure logic. Reachability analysis, used within software composition analysis, focuses on third-party open source dependencies and whether known CVEs in those libraries are actually invoked by your application. Both techniques are complementary and address different categories of security risk.