Your SCA Scanner Found a Critical CVE. Is the Vulnerable Code Actually Reachable?

Your SCA scanner just flagged a critical vulnerability in one of your dependencies.

Before that finding goes anywhere near your escalation process, it's worth answering one question first: does your application actually reach the vulnerable code, or does it just happen to depend on a package that contains it somewhere?

Presence tells you the vulnerable component exists. Reachability asks whether your application can actually get to the vulnerable code. Those are two different questions, and conflating them is one of the most common reasons SCA backlogs fill up with findings that look urgent but aren't.

This distinction matters more as dependency trees get deeper. Modern applications routinely pull in hundreds of packages, many of them transitive dependencies nobody on the team explicitly chose or reviewed. A CVE in any one of them shows up on the same dashboard, with the same severity label, regardless of whether it's sitting in code your application runs constantly or code that's simply along for the ride.

What an SCA Finding Actually Tells You

Software Composition Analysis tools are good at what they're built to do: identify which packages, at which versions, are present in your dependency tree, including both the ones you installed directly and the transitive dependencies pulled in underneath them. When a CVE is published against one of those packages, the scanner correctly flags it.

What that finding does not necessarily answer is whether your application's execution actually reaches the affected code. A package can sit in your dependency tree for reasons that have nothing to do with the vulnerable function inside it (such as being pulled in for one utility method, one configuration helper, or one small piece of functionality that never touches the vulnerable code path at all). The scanner sees the package, but it doesn't automatically know what your application actually does with it.

None of this is a shortcoming in the scanner itself. Package-level detection and function-level reachability are genuinely different analyses, requiring different information. A scanner comparing your manifest against a vulnerability database doesn't need to understand your application's call graph to do its job well. Reachability analysis is a separate, additional step layered on top of that detection, not a correction to it.

The Real Question: Is the Vulnerable Function on an Application Call Path?

Presence is a package-level signal. Reachability is a function-level question, and that shift matters.

A CVE is rarely a statement about an entire package; it's usually tied to a specific function, method, or code element where the vulnerable behavior actually lives. The real question isn't "do we depend on this package," it's "does any path through our application code, directly or through other dependencies, actually call that specific vulnerable function." A package can be entirely present and entirely unused in the one place that matters.

How SCA Reachability Analysis Works

The general workflow moves from a raw finding down to a function-level answer: the SCA finding identifies the vulnerable package and version, the vulnerable code location narrows that down to a specific function or method, the application's dependency and call graph gets mapped, and the analysis traces whether a valid path connects application execution to that specific function.

The result isn't always a clean yes or no. Reachability analysis on real codebases tends to produce three outcomes, not two: reachable, where a confirmed execution path connects the application to the vulnerable function; unreachable, where analysis can confirm no such path exists given the application's known code; and unknown, where dynamic behavior, reflection, runtime configuration, or other factors make a confident static determination genuinely difficult. Treating "unknown" as equivalent to "unreachable" is a quiet way of underestimating risk, and treating it as equivalent to "reachable" is a quiet way of wasting investigation time on findings that may not deserve it. It deserves its own bucket and its own follow-up.

Direct vs. Transitive Dependencies: Which Ones Can Be Reachable?

This is where SCA reachability gets genuinely specific to dependency management, rather than being a restatement of general reachability concepts.

A direct dependency, which is one your team explicitly installed, is not automatically reachable just because it's a first-party choice. Plenty of direct dependencies get pulled in for one narrow purpose and never touch the vulnerable portion of their own codebase. Being a deliberate, direct choice doesn't mean every function inside it gets exercised.

The reverse is just as important: a transitive dependency, sitting several layers below anything your team explicitly chose, is not automatically irrelevant just because nobody on your team knows it's there. If application code calls into a direct dependency, which calls into a second-level dependency, which calls into a third-level package containing the vulnerable function, that chain is still a real execution path. It's just harder to see without actually mapping it. Depth in the dependency tree affects how hard reachability is to determine; it doesn't affect whether the vulnerability matters if the path genuinely exists.

This is also why manual reachability review tends to break down as dependency trees get deeper. Tracing a call path through two or three levels of dependencies by hand is tedious but doable. Tracing it through six or seven, across a codebase with hundreds of packages, stops being a reasonable use of a security engineer's time, even though the risk calculus hasn't changed at all.

Reachable Does Not Mean Exploitable

A confirmed reachable path is a meaningful signal, not a final verdict. Whether that reachable code can actually be abused still depends on factors like attacker-controlled input reaching the vulnerable function, the application's exposure, runtime configuration, and whatever permissions or controls sit around that code path.

Reachability is evidence of relevance, not proof of exploitability. It tells you a finding deserves real attention instead of being buried under a thousand others. It doesn't, by itself, tell you how urgently to act. That's a separate analysis, and one worth keeping separate rather than trying to answer here.

How Reachability Changes the Way AppSec Teams Handle SCA Findings

The practical benefit of reachability analysis isn't that it makes findings disappear. It's that it stops every dependency CVE from being treated with identical urgency by default.

Without reachability context, a security team investigating a large SCA backlog has to treat "critical CVE in package X" the same whether that package is central to the application or barely touched. With reachability context, findings split into ones that deserve real investigation time and ones that can be reasonably deprioritized with documented justification. That split also improves how findings get handed to developers: a reachable finding with a shown execution path is a far more credible ask than a bare CVE number, and developers are more likely to trust and act on findings that come with that context attached. Tracking this shift also connects directly to signal quality as a measurable application security metric, since reachability is one of the clearest ways to separate findings that deserve engineering time from ones that don't.

What Should You Do With an Unreachable Dependency Vulnerability?

Unreachable does not mean delete or ignore forever. It means the finding gets a different disposition than an urgent one, with the reasoning behind that disposition actually documented, detailing which function was checked, what call graph analysis was run, and what conclusion it reached.

That documentation matters because reachability isn't a permanent property of a finding. Code changes, dependency versions get upgraded, and configuration shifts, any of which can turn an unreachable finding into a reachable one. An unreachable dependency vulnerability should be monitored and revisited when any of those conditions change, not closed out and forgotten. Treating "unreachable today" as "irrelevant forever" is how a legitimately deprioritized finding quietly turns into a real gap six months later.

A reasonable review trigger is any dependency version bump that touches the flagged package, any refactor of the code that previously sat between application logic and the vulnerable function, or any configuration change that alters how a feature is exposed. None of these require re-running a full reachability sweep across the entire codebase; you just need to re-check the specific findings whose surrounding conditions actually changed.

A Practical SCA Finding-to-Decision Workflow

Put together, the full sequence looks like this: an SCA finding arrives, the vulnerable package and version get identified, the affected function or code gets located, the application's call path to that function gets mapped, and the finding gets classified as reachable, unreachable, or unknown.

From there, the path diverges. If the finding is unreachable, document the supporting evidence and move it into disposition or ongoing monitoring rather than active remediation. If it's reachable, the next step is exploitability analysis, followed by prioritization and remediation (the same vulnerability triage sequence that applies to any validated finding once reachability has established that it's actually relevant). If the result is unknown, that's a signal to investigate further rather than defaulting to either extreme. From there, the question of how urgently a reachable finding should be worked is really a question of how to prioritize vulnerabilities more broadly, using reachability as one input alongside exploitability, exposure, and business context.

Where Amplify Fits

Once reachability has narrowed an SCA backlog down to the findings that actually matter, the next problem is doing this consistently at volume; most teams can't manually trace call graphs for every dependency CVE that shows up in a given month.

This is the specific gap Amplify is built to close. Amplify Console applies reachability analysis to SCA findings automatically, mapping application call paths to determine whether a flagged dependency is actually reachable before a security engineer spends time investigating it manually. The goal isn't finding more dependency vulnerabilities, as SCA scanners already do that well. It's reducing the manual work that currently sits between a raw scanner finding and an actionable security decision, so the findings that reach a developer already come with the context needed to trust and act on them.

Frequently Asked Questions

What is SCA reachability analysis?

SCA reachability analysis determines whether an application's code actually reaches the vulnerable function inside a flagged dependency, rather than stopping at confirming the vulnerable package or version is merely present.

Can a critical CVE be unreachable?

Yes. A dependency can carry a critical CVE even when the application never calls the specific vulnerable function inside it, which means the severity rating and the actual risk to that application can differ significantly.

Can a transitive dependency vulnerability still be reachable?

Yes. A transitive dependency several layers below what was directly installed can still be reachable if application code, through the chain of intermediate dependencies, eventually invokes the vulnerable function.

Does reachability mean exploitable?

No. Reachability confirms the vulnerable code can be executed, but exploitability also depends on attacker-controlled input, exposure, configuration, and existing controls. Reachability is evidence of relevance, not proof of exploitability.

What should teams do with unreachable dependency vulnerabilities?

Document the evidence supporting the unreachable classification, handle the finding according to organizational policy, and reassess if the code paths, configuration, or dependency version later change rather than dismissing it permanently.

How does reachability analysis help with SCA findings?

It gives AppSec teams a way to distinguish SCA findings that deserve real urgency from ones that don't, avoiding the default of treating every dependency CVE as equally critical regardless of whether the application actually executes the vulnerable code.

Turn Dependency Findings Into Actionable Security Context

Amplify helps security teams investigate findings with application context and move credible vulnerabilities toward prioritized, developer-reviewable remediation.

See How Amplify Works