The application owner should sign off a not reachable decision, with security reviewing the evidence for anything high severity. The record needs the call path result, the build configuration, the date, and a trigger for rechecking. Without those four, "not reachable" is an opinion, not a decision.
Why an owner matters
Reachability depends on how the application is built and used, which the team that owns it knows best. Security brings the method and the second pair of eyes. If only security decides, the context is missing. If only the developer decides, the incentive to close the ticket is strong.
A simple split of roles
| Role | Responsibility |
|---|---|
| Application owner | Confirms entry points and configuration are correctly described |
| Security reviewer | Checks the evidence and the severity, challenges thin reasoning |
| Approver for exceptions | Signs when severity is high or the finding is on an exposed service |
For low severity findings, an owner alone is often enough. For high severity or internet-facing services, require the second review.
What the record should hold
- The finding: package, version, advisory identifier, affected function if known.
- The result: not reachable, with the tool output or call graph excerpt.
- The scope: which entry points and which build configuration were analysed.
- The reasoning in a sentence or two, in plain words.
- The date, the name of the owner and the reviewer.
- The recheck trigger: dependency update, new entry point, or a time limit.
Matching the VEX vocabulary
If you publish status to customers, the OpenVEX specification includes standard justifications for a not affected status. Two relevant ones are that the vulnerable code is not present, and that the vulnerable code is not in the execute path. Choose the one that matches what you really verified. They are different claims, and mixing them up can mislead a reader.
Recheck triggers that work
- The dependency version changes.
- A new route, job or integration is added that can feed data to the package.
- The build configuration changes.
- A set review date passes, such as 90 days for medium severity.
Signs of a weak sign off
- The reason says only "not used".
- No tool output or path is attached.
- The reviewer is the same person who wrote the code and the ticket.
- No trigger to recheck.
Fixing these costs minutes per finding and prevents most embarrassing questions later.
Safeguard includes reachability analysis alongside SBOM and dependency scanning, and you can run a free scan at gold.safeguard.sh/scan to see the output on your own repository.
Quick check
Can a tool auto-close not reachable findings?
It can label them, but a person should own the decision for anything beyond low severity, with evidence attached.
How long should a sign off last?
Until a recheck trigger fires. A time limit is a good backstop.
Sources
Last reviewed: 19 October 2026.
