Free reachability analysis usually comes in three forms: a limited tier of a commercial product, an open source call-graph tool for one language, or manual review by your own engineers. All three can work for a small codebase. Check language coverage, how the tool handles uncertain cases, and whether it scales past a few repositories.
We did not survey the market of free tools for this post and name none. It is a guide to categories and the questions that sort them.
What does reachability analysis do?
It asks whether your code actually calls the vulnerable function in a dependency. Safeguard's documentation describes three kinds of evidence: static analysis of a call graph built from source, lockfiles and bytecode; dynamic analysis from a runtime collector; and configuration analysis of framework settings. Results fall into reachable, conditionally reachable, unreachable and unknown. This helps you put real risk first. It does not remove the need to patch, and CISA says exploited vulnerabilities from its Known Exploited Vulnerabilities catalog should feed your prioritization regardless.
Category 1: Free tiers of commercial products
What you get: the full workflow for a limited scope, often a small number of repositories, users or scans per period.
Where it stops: the cap, and sometimes the feature set. Reachability may be reserved for paid plans. Check the plan page for the exact wording on reachability, not the marketing page. Also check data handling: some free tiers upload source to the vendor's cloud.
Good fit: a small team that wants to see what reachability does on a real repository before paying.
Category 2: Open source call-graph tools
What you get: analysis you can run anywhere, inspect, and script, usually for one language or ecosystem.
Where it stops: language coverage, maintenance and integration. A tool built for one language will not help your polyglot repository. You also own the glue: mapping advisories to function names is hard work, and it is often the missing piece. If no one maintains the project, it ages out as frameworks change.
Good fit: teams with strong engineering depth in one language and time to maintain tooling.
Category 3: Manual review
What you get: the most accurate answer for a single finding, from a person who knows the code.
Where it stops: time. Reading call paths for every finding does not scale. Use it to verify the cases that matter, such as the five highest severity findings, and to check any tool you adopt.
Good fit: the top of the queue, and the validation set for tool trials.
What should you check in any free option?
- Languages. Does it cover the ones you run? Safeguard's reachability page, for example, lists some languages as GA for static and dynamic analysis, and Ruby, PHP, Swift and Objective-C as Preview in some modes. Ask every vendor for that level of detail.
- Unknown handling. What does it do with reflection or dynamic dispatch? Safeguard treats unknown as potentially reachable. A tool that marks those unreachable can hide real risk.
- Explanation. Can it show the call path, so a developer can verify it?
- Scale. Does it handle your largest repository in a reasonable time?
- Where the code goes. Is source uploaded, or does analysis run locally?
- Exit path. Can you export results if you leave?
Does Safeguard have a free route?
We can speak to one verified item: the Gold registry offers a free in-browser scan at gold.safeguard.sh/scan for up to 100 dependencies. We do not describe it as a reachability tool, and we make no claim about what it reports on reachability. For plan details of any kind, check the pricing page directly.
What are the limits of all reachability analysis?
Safeguard's own page says the analysis is weakest with reflection, eval or unsafe dispatch, data-driven vulnerabilities, and paths that exist only under configurations the analyzer cannot enumerate. In those cases rely on exploitation data, runtime observation and conservative defaults. Its documentation also states that its reported filtering figures are aggregates across customer tenants and not guarantees. Hold any free tool to the same standard.
What to do
- Pick one repository and label ten findings by hand as called or not called.
- Run each free option on it and compare with your labels.
- Reject any option that marks a called function unreachable.
- Check the data handling terms before uploading private source.
- Revisit when your repository count or language mix changes.
Quick check
Is a free reachability tool enough for a small team?
It can be, if it covers your languages, handles uncertain cases cautiously and you verify its answers on a sample.
Does reachability replace patching?
No. It helps you order the work. Exploited vulnerabilities still deserve fast attention.
Sources
Last reviewed: 18 October 2026.
