Explain reachability in four beats: what the scan found, what you checked, what you concluded and how you will keep checking. Use one concrete example, say what the method cannot see, and offer the evidence in writing. Five minutes is enough if you skip the theory and stay on their product.
Beat one: the finding, in their words
Start from what they already have. "Your scan lists a high severity issue in a logging library. We looked at it for this release."
Do not open with the definition. People listen better when the first sentence is about their concern.
Beat two: what reachability means
Say it once, plainly. "A library can sit in the product without the risky function ever running. Reachability analysis checks whether any path from our code reaches that function."
If they ask for an analogy: a locked room in the building that no corridor leads to. It is still part of the building, and you still note it.
Beat three: what you found
Give the concrete result and the scope. "For version 4.2, on the analysis date, no call path reaches the affected function. Here is how we know."
Then say the limit. "This is a statement about this build. Dynamic loading or reflection can hide paths from static analysis, so we also keep the finding on a review list."
That sentence is what makes the rest credible. Reviewers trust a vendor who names the blind spot.
Beat four: how you keep checking
"We rerun the analysis on each release and when the advisory changes. If a path appears, the finding is reopened and you hear from us."
Offer the artifact. "We can send a short statement with the finding, the version, the date and the reason, in a standard VEX format if your tooling reads it."
Questions to expect
| Question | Honest answer |
|---|---|
| Why not just upgrade? | We do when it is low risk. Where it is not, we schedule it and explain the interim position. |
| Can you prove it cannot be exploited? | We can show no call path was found in this build. We do not claim more than that. |
| Does your tool ever get this wrong? | Yes, in both directions. That is why we review decisions and rerun them. |
| What if the library is used by a plugin? | Then it is in scope for the analysis and we say how plugins were handled. |
| Who signed this off? | Name the owner and the date. |
Habits that keep the call short
- Bring the finding ID, version and date on one page.
- Avoid the words "safe" and "not exploitable".
- Say "no call path found" instead.
- Do not read the tool vendor's marketing aloud.
- Follow up in writing the same day.
CISA's minimum elements for VEX describe a statement of a product's status against a vulnerability, and the OpenVEX specification asks a not affected claim to carry a justification or an impact statement. Mentioning that you can issue such a statement tells the reviewer you work in a recognized format.
After the call
Send the one page. Log the call in the finding record. If the customer asked a new question, add it to your FAQ so the next call is shorter. For more on the written side, see explaining reachability to a customer security reviewer.
Quick check
Should I show the call graph on screen?
Only if they ask, and only the relevant path. A full graph invites questions about unrelated code.
Is it fine to say the vulnerability does not affect us?
Prefer a scoped sentence: no call path found in this version on this date.
Safeguard's reachability analysis and policies give you the result and the record to bring to a call like this. You can try the free scan.
Sources
Last reviewed: 19 October 2026.
