How to test an SCA vendor's reachability claims

Seed a test project with two cases: a vulnerable function you do call and one you do not. A trustworthy reachability tool flags the first as reachable and the second as not, and shows its evidence for both. If it cannot explain either answer, treat the claim as marketing.

What reachability means

Software composition analysis lists vulnerable packages. Reachability analysis asks a narrower question: does your code, directly or through other libraries, call the vulnerable code? If not, the finding is real but unlikely to be exploitable through your application.

That distinction can shrink a long list. It can also hide real risk if the analysis is wrong, so it deserves a test.

Build the seeded project

Create a small repository with a dependency that has a published advisory tied to one specific function. Then:

1. In file A, call the vulnerable function.
2. In file B, import the same package but call only a safe function.
3. Make a third case where the call is indirect, through a wrapper in your own code.
4. Make a fourth where the call happens through reflection or dynamic dispatch, if your language allows.

Write down the expected result for each before you scan.

Read the results

For each case ask:

• Did the tool label it reachable, unreachable, or unknown?
• Does it show the call path?
• Is "unknown" an option? Honest tools admit when analysis cannot decide.

The dynamic case is the revealing one. A tool that labels it unreachable with confidence is guessing. A tool that says unknown or reachable is being careful.

Check the failure direction

There are two ways to be wrong. Calling a reachable flaw unreachable hides risk. Calling an unreachable flaw reachable only costs time. Ask the vendor which way the tool errs when unsure. You want it to err toward showing the finding.

Check that suppressed findings stay visible

A good tool does not delete unreachable findings. It lets you filter them out, and it reopens them if your code changes. Ask whether a later commit that adds a call changes the status.

Check language coverage honestly

Reachability support is often deeper for some languages than others. Ask for the list, and confirm it covers the ones you run. Ask what happens for languages not on it.

Combine with exploit signals

Reachability and exploit data answer different questions. See EPSS, KEV, and CVSS in SCA triage for the other half.

Click through it at your own pace, or open it full screen.

Safeguard includes reachability analysis in its dependency scanning. You can run a seeded project through the free scan at https://gold.safeguard.sh/scan.

Ask for the evidence format

A call path you can read is the best proof. Ask whether the tool shows each hop from your code to the vulnerable function, and whether you can export it. If the vendor only returns a yes or no label, you cannot audit it, and you cannot explain a suppressed finding to a customer or an auditor later. Keep the seeded project in version control and rerun it after every major tool update.

Quick check

Last reviewed: 19 October 2026.