Ask a vendor which languages the analysis really covers, what the tool says when it cannot decide, whether the verdict comes with evidence you can read, and whether the result can be exported in a standard format. A reachability claim without those answers is a marketing line, not a control.
Reachability analysis asks one question about each known vulnerability: does your code actually get to the vulnerable function? Done well, it shrinks a backlog to the findings worth a developer's afternoon. Done badly, it hides real risk behind a confident label.
1. Which languages, and at what depth?
Support varies a lot by ecosystem. Static call graphs are easier for some languages than for others, and reflection, dynamic dispatch and native code can break them. Ask for a table of languages with what is supported for each, and whether a feature is generally available or in preview. A vendor who answers "all of them" has not looked closely.
2. What happens when the tool cannot decide?
This is the most important question. A safe design treats an undecidable case as potentially reachable and says so. An unsafe one quietly marks it unreachable and removes it from view. In Safeguard's docs, a finding is classed as reachable, conditionally reachable, unreachable or unknown, and unknown is treated conservatively as potentially reachable. Whatever the vendor's labels are, ask what the fourth bucket is called and where it goes.
3. Can I see the path?
A verdict you cannot inspect is hard to defend to an auditor or a skeptical engineer. Ask to see the call path from your code to the vulnerable function for one real finding. If the only output is a label, you cannot challenge it.
4. Is it static, dynamic, or both?
Static analysis reads code and configuration. Dynamic analysis observes what runs in a real environment. Each has blind spots. Static can overestimate, because a path may exist but never run. Dynamic can underestimate, because code that did not run during the observation window may still run next week. Ask how the two are combined, and how long the dynamic observation window is.
5. How is exploit information used?
Reachability tells you whether your code can get there. It does not tell you whether anyone is attacking the issue. Two public sources help with that.
- CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities observed being exploited in the wild, and CISA says organizations should use it as an input to their prioritization framework.
- EPSS, maintained by FIRST, estimates the probability that a published CVE will be exploited in the next 30 days, published as a daily score between 0 and 1.
Ask how the tool combines reachability with these signals, and whether you can see each input separately. A single opaque score makes it hard to explain a ranking.
6. Can I export the result in a standard format?
CISA publishes minimum requirements for a Vulnerability Exploitability eXchange document, known as VEX. A VEX statement lets a supplier say that a product is not affected by a given vulnerability, with a reason. If a tool decides a finding is unreachable, ask whether it can express that as VEX, so your customers and auditors see the same reasoning you do.
7. Where does my code go?
Some analysis needs source. Ask whether it runs on your infrastructure or the vendor's, what leaves your network, and whether there is a mode where only results leave. This matters for regulated teams and for anyone with private repositories.
8. How do you measure accuracy?
Ask for false negative handling, not only noise reduction. Any vendor can show how many findings were removed. Fewer can show how they check that nothing real was removed. A good answer includes a test set, a review process for disputed verdicts, and a way for you to override a verdict with a recorded reason.
What to do
- Pick five findings from your own backlog, including one you know is real and one you know is noise.
- Send those to each vendor and ask for the verdict and the path.
- Score the answers on the eight questions above, with a column for evidence shown versus claimed.
- Pilot on one service for a full release cycle and track findings that changed class after a code change.
- Keep a manual override with a written reason, and review overrides monthly.
Open the full walkthrough at /demos/exploitability-check.
Quick check
Is an unreachable finding safe to ignore forever?
No. Reachability depends on the code and configuration at the time of analysis. A refactor or a new feature flag can create a path, so re-run the analysis on change and keep the finding on record.
Does a high EPSS score mean the vulnerability is reachable in my code?
No. EPSS estimates the chance of exploitation in general. Reachability is about your own code. You need both signals.
Sources
- CISA, Known Exploited Vulnerabilities Catalog
- FIRST, Exploit Prediction Scoring System (EPSS)
- CISA, Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
- Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
Last reviewed: 18 October 2026.
