Yes. A model handed only a list of CVEs has to guess which ones matter, and it will guess confidently. If you supply evidence on whether the vulnerable function is called, it can explain priority in plain words that a reviewer can check against the facts you supplied.
What the model lacks by default
From a CVE list alone, a model knows the descriptions it has seen. It does not know whether your code imports the affected module, calls the vulnerable function, or passes untrusted input to it. Without that, "likely relevant" is a pattern match on severity words.
Reachability analysis is the step that answers the code question: does a path from your code reach the vulnerable function? That is computed from your code, not recalled from training data.
Facts worth supplying
| Fact | Where it comes from |
|---|---|
| Component and version in use | Lockfile or SBOM |
| Direct or transitive dependency | Dependency graph |
| Vulnerable function named in advisory | Advisory record |
| Whether that function is reachable | Reachability analysis |
| Whether input to it is attacker influenced | Code review |
| Exploitation status, dated | Authoritative exploited list |
A prompt shape that works
- Role: you are helping an engineer understand one finding.
- Facts: paste the table rows above for this finding only.
- Rules: use only these facts, say "unknown" when a fact is missing.
- Task: write a three sentence note for the owning team and one suggested next step.
- Format: fixed fields, so notes are comparable.
Check afterwards that each claim in the note maps to a supplied fact. If the note mentions something you did not supply, it was invented.
What reachability does not settle
Reachable does not mean exploitable, and unreachable does not mean forever safe. Code changes, and a new call path can appear next release. Treat "not reachable" as a lower urgency with a re-check, not as a permanent dismissal. Record the date of the analysis.
Why this reduces noise
When teams sort findings by reachability, they spend time first on flaws in code that actually runs. The model then spends its effort writing about the findings that matter, rather than summarizing hundreds that do not.
For adjacent reading: how a model should be asked to triage.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and watch how the finding list changes once call path evidence is applied.
Where Safeguard fits
Safeguard's reachability analysis works on your code and dependencies, and you can pair its output with a model for explanation while keeping the evidence attached. Try a free scan at https://gold.safeguard.sh/scan.
Quick check
Can the model work out reachability itself from pasted code?
For a small snippet it may be right, but it can miss indirect calls and generated code. Use analysis tooling for the facts.
Should unreachable findings be closed?
Lower their priority and set a re-check date. Do not treat them as permanently resolved.
Last reviewed: 19 October 2026.
