Open the chat in the Safeguard web app, name the CVE and the project, and ask why it is reachable. Treat the reply as a lead, then confirm it against the finding's reachability class and its call path. A good question names the package, the project and the thing you doubt.
What does "reachable" mean here?
The Safeguard docs say a CVE is reachable when your code actually calls the vulnerable function or triggers the vulnerable code path. That differs from "the package is in your tree," which is all a plain dependency scan can say.
The docs describe three kinds of analysis. Static analysis builds a call graph from source, lockfile and bytecode and checks whether any path leads to the vulnerable code. Runtime analysis records which modules and functions load in production and flags never-executed paths as cold. Configuration analysis reads framework configuration, such as route files, to see whether the code is wired in at all.
Findings then land in one of four classes: reachable, conditional, unreachable or unknown. Conditional means a path exists but needs a flag, route or setting that is currently off. Unknown means the analyzer could not decide, for instance because of reflection or native code, and the docs say it is treated conservatively as potentially reachable.
How should you phrase the question?
The chat is the front of the web app, and the docs say the whole platform can be driven from it. Vague questions get vague answers. Compare:
- Weak: "Is this bad?"
- Better: "Why is CVE-2021-44228 marked reachable in the payments-service project?"
- Best: "Which call path reaches the vulnerable method in payments-service, and is that path enabled in production?"
The third version asks for the evidence, not a verdict. It also separates "a path exists" from "the path is live," which maps straight to the conditional class.
How do you check the answer?
Do not stop at the chat reply. The web app's search bar accepts filter syntax, and the docs show a query of the form severity:critical AND reachable:true AND project:payments-service. Run the filter and confirm the finding appears in that set. If the chat says reachable and the filter disagrees, trust the filter and ask the chat to explain the gap.
Then open the finding and read the path. A developer who owns that code can usually tell in a minute whether the call is real. If the path runs through a test fixture or a disabled feature, record that.
When should you not rely on it?
Dynamic dispatch, reflection and native code are the places static analysis struggles, and the docs mark those as unknown. Do not read unknown as safe. Do not read reachable as exploited either. Reachability says your code can get there, not that an attacker can send the input that triggers it.
For that second question, pair it with exploit signals. The docs say the platform also uses EPSS, which estimates the chance of exploitation in the next 30 days, and CISA's list of known exploited vulnerabilities.
What to do
- Open app.safeguard.sh and start a chat in the project that holds the finding.
- Ask for the call path, not a yes or no.
- Ask whether the path is enabled in production, and where that setting lives.
- Re-run the same filter in search to confirm the finding sits in the reachable set.
- Have the code owner read the path and sign off.
- Write the decision and the class into the ticket so the next reader sees why.
Quick check
What does the conditional class mean?
A call path exists but depends on a feature flag, route or configuration that is not currently enabled. Fix it on your normal schedule, and re-check if the setting changes.
Is an unknown result safe to ignore?
No. The docs say the analyzer marks cases it cannot decide, such as reflection or native code, conservatively as potentially reachable.
Sources
- Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
- Safeguard docs: Web app
- FIRST: Exploit Prediction Scoring System
- CISA: Known Exploited Vulnerabilities Catalog
Last reviewed: 18 October 2026.
