Auditors do not reject reachability analysis as a category. They reject undocumented decisions. A reachability result with a build, date, method, owner and review date is ordinary evidence of a risk based decision. The same result with no record is just a claim. Here are five myths worth retiring.
Myth 1: Auditors require every critical to be patched
Fact: It depends on your own policy and your contracts. Auditors test whether you follow the rules you wrote. NIST's Secure Software Development Framework describes making a risk based decision on whether a vulnerability is remediated or addressed by other means, with approved exceptions recorded. If your policy allows a documented alternative, using it is not a violation. If your contract says patch everything, that is a separate matter. See the contract question.
Myth 2: A tool label is enough evidence
Fact: A label without context draws questions. Evidence needs scope, method, date and owner. The CISA minimum elements for VEX include timestamps and a clear statement of product status, which shows how much structure is expected even in a short statement.
Myth 3: Not reachable means safe forever
Fact: It means no call path was found in a particular build. The OpenVEX specification warns that some justifications can be difficult to prove conclusively. Code changes, new dependencies and new advisories can alter the answer, so the decision needs a review trigger. See why a verdict needs a commit and a date.
Myth 4: Reachability replaces scanning
Fact: It sits on top of scanning. You still need an inventory and a list of known issues to analyze. Reachability helps order and explain the list. It does not remove the need for the list.
Myth 5: Customers will only accept zero findings
Fact: Many reviewers know a clean report is unusual. What they want is a believable account of the open items: what they are, what you decided and when you will look again. Reporting only the findings you closed looks selective. Report every bucket.
A summary table
| Claim | Reality |
|---|---|
| Auditors forbid deprioritizing | They test your documented rule |
| A label is evidence | Context makes it evidence |
| Not reachable is permanent | It is dated and reviewable |
| It replaces scanning | It builds on scanning |
| Zero findings is the goal | An honest account is the goal |
What persuades
- A short written policy that names reachability as an input.
- A consistent record on every deferred item.
- A visible review cycle.
- A frank statement of the method's limits.
- Willingness to patch when the fix is cheap.
What does not
Marketing language, confident absolutes and hiding unknowns. If an unknown result appears, say so and treat it conservatively.
Quick check
Will a SOC 2 or ISO auditor accept reachability evidence?
Whether any evidence is sufficient is the auditor's judgment about your controls. Bring a documented process and records, and ask them early what they expect.
Is it risky to tell a customer about unknown results?
Less risky than hiding them. State how unknowns are treated.
Safeguard offers reachability analysis with policies and evidence automation so decisions arrive with their records. You can try the free scan.
Sources
- NIST SP 800-218, Secure Software Development Framework 1.1
- Minimum Requirements for VEX, CISA
- OpenVEX specification
Last reviewed: 19 October 2026.
