The Safeguard local runner executes scans and assistant turns on your own machine and uploads only SBOM and findings files. Its documentation does not describe "why is this reachable" questions as a runner feature. Ask that in the platform's vulnerability views or with Griffin, and use the runner to keep source code local.
What is the local runner?
Per Safeguard's runner documentation, the runner is built into the Safeguard CLI, not a separate product. It is meant for cases such as a private repository you will not give a cloud service access to, a network that allows only outbound HTTPS, or an assistant that should fix vulnerabilities in code you have not pushed yet.
How it works, as documented: the runner sends heartbeats and polls the platform for jobs assigned to that machine, using only outbound HTTPS. It executes a job with its own local scan server, then uploads result files (SBOM and findings) and reports status. Source stays on the machine.
Install with curl -fsSL https://cli.safeguard.sh/install | bash on macOS or Linux, or irm https://cli.safeguard.sh/install.ps1 | iex on Windows. Run safeguard, type /login, approve in the browser, and the runner starts. The first run downloads scanner tools and the vulnerability database.
Where does reachability come from?
Safeguard's reachability documentation describes three kinds of evidence. Static analysis builds a call graph from source, lockfiles and bytecode. Dynamic analysis uses a runtime collector that records which functions production workloads load and invoke. Configuration analysis parses framework config such as Spring beans or Next.js routes to see whether code is wired in.
Each finding lands in one of four classes: reachable, conditionally reachable (a path exists but needs a flag, route or configuration that is off), unreachable, or unknown. Unknown, caused by things like reflection or native code, is treated conservatively as potentially reachable.
So where do you ask "why"?
The reachability docs say the ESSCM Vulnerabilities tab has Priority and Reachability columns, with filters such as reachable:true and combinations like env:production reachable:true kev:true. They also say Griffin accepts natural-language questions about priorities. Those are the places to look for the verdict and its classification.
One limit to know: the docs state there is no CLI command yet for querying findings by priority, and the example REST endpoints on that page return 404, so the example shows only the intended shape. Do not script against it.
The runner docs list no reachability commands. What the runner does offer are safeguard agent for an interactive session in the current workspace, and safeguard exec for a single turn with no prompts, defaulting to strict permissions where anything a policy file has not approved is denied. Whether an assistant turn can explain a reachability verdict is not stated, so try it on a test repository and judge the answer against the call path yourself.
How should you use the two together?
- Run the scan through the runner so source stays local.
- Open the finding in the platform and read the Reachability value and class.
- For any finding marked reachable or conditionally reachable, ask Griffin to explain, then verify by reading the call path in your code.
- For unknown, assume risk until a human reads the code.
What are the limits?
The reachability page says the analysis is weakest with reflection, eval or unsafe dispatch, data-driven vulnerabilities, and paths that exist only under configurations the analyzer cannot enumerate. In those cases it recommends relying on Known Exploited Vulnerabilities data, EPSS, runtime observation and conservative defaults. The runner also uses permission modes from supervised to autonomous, and the docs do not detail what each allows, so start supervised.
What to do
- Install the CLI and run the runner on one private repository.
- Open its findings in the platform and filter on reachable results.
- Pick five reachable and five unreachable findings, and verify them by hand.
- Keep unknown results in your queue.
- Stay in supervised permission mode until you trust it.
Quick check
Does the runner upload my source code?
Per the docs, no. It uploads only SBOM and findings files, and source code stays on the machine.
What does "unknown" mean for reachability?
The analyzer could not decide, for example because of reflection or native code. Safeguard treats it as potentially reachable.
Sources
Last reviewed: 18 October 2026.
