Reachability analysis for a startup with no security team

Reachability analysis checks whether your application can actually reach the vulnerable code in a dependency, so you fix what matters first. For a startup with no security team, it turns a long list of alerts into a short one. Use it with two public signals: known exploitation and exploit probability.

What is reachability, in one example?

Your app depends on a library with a published vulnerability in one function. If your code never calls that function, directly or through other libraries, the flaw is present but not reachable. If it does, an attacker may be able to trigger it through your inputs.

Safeguard's vulnerability documentation lists reachability as a prioritization signal built from three things: call path analysis, which asks whether the vulnerable code is actually called; runtime context, which separates production from development use; and configuration impact, such as feature flags and settings. The docs define the reachability field as whether the code path is reachable.

Reachability is evidence for ordering work, not a permission to ignore anything. Static analysis of call paths can miss dynamic calls. Treat "not reachable" as "lower priority and re-check on change."

Which public signals pair well with it?

CISA's Known Exploited Vulnerabilities Catalog. The catalog lists vulnerabilities known to be exploited. If a vulnerability in your dependency is on it, move it to the front of the queue regardless of other scores.

EPSS. FIRST describes the Exploit Prediction Scoring System as a model estimating the probability, from 0 to 1, that a published CVE will be exploited in the wild in the next 30 days, with scores published daily. It is a probability, not a verdict, and FIRST points readers to its pages on known limitations and common misuses.

Together the three give you a simple order: known exploited and reachable first, high probability and reachable next, everything else on a schedule.

How should a tiny team work with it?

You have no spare hours. Aim for a weekly 30 minute routine, not a program.

1. Scan on every pull request so new issues appear while the change is fresh.
2. Sort by exploited, then reachable, then probability.
3. Fix or upgrade the top few, and note why you deferred the rest.
4. Re-run weekly, because new advisories arrive for old code.

Buyer criteria for a tool follow from this. Look for call path evidence you can read, not just a label. Ask which languages the analysis covers. Ask how it handles frameworks that call code indirectly. Check that it runs in your pull requests and gives you the fix version. And check what it says when it cannot tell.

What to do

1. Generate an inventory of your dependencies, including transitive ones.
2. Turn on reachability in your scanner and read the call path for the first few results.
3. Flag anything in the CISA catalog as urgent.
4. Use EPSS to rank the rest, and remember it is a probability.
5. Upgrade the reachable items first, and test.
6. Record every deferral with a reason and a date to revisit.
7. Add a pull request check so new reachable high issues block a merge.
8. Review monthly: what was deferred, what changed.

Try it

Our exploitability check demo shows how reachability and exploit signals combine.

Open the full demo at /demos/exploitability-check.

Quick check

Sources

• Safeguard docs: Vulnerabilities, fetched 18 October 2026.
• FIRST: Exploit Prediction Scoring System, fetched 18 October 2026.
• CISA: Known Exploited Vulnerabilities Catalog, fetched 18 October 2026.

Last reviewed: 18 October 2026.