The Safeguard local runner is documented as running scan jobs against code on your own machine and uploading only the resulting SBOM and findings. The docs do not describe feeding it a vendor's existing SBOM file. For that task, use the CLI's scan with an SBOM target. Use the runner when you can check out the source.
What does the runner actually do?
The runner is built into the safeguard CLI. It is not a separate product. According to the Safeguard docs, it executes the platform's scan jobs and assistant turns on your own machine. Source code stays local. What leaves is the SBOM and the findings.
It works by outbound HTTPS only. The runner sends heartbeats, polls for jobs assigned to that machine, runs each claimed job with its own local scan server, then uploads results and job status. Nothing connects inward.
That design suits one case well: a repository you are allowed to read but not allowed to send anywhere.
Where does a vendor SBOM fit?
A vendor SBOM is a file, not a repository. The CLI overview says safeguard scan can scan an existing SBOM, and safeguard validate checks CycloneDX, SPDX and VEX documents. The step by step for that is in our post on reviewing a vendor SBOM with the Safeguard CLI.
The runner docs say nothing about accepting a pre-existing SBOM as input, so we will not claim it does. If you need that, check with Safeguard directly.
When is the runner the right tool for vendor work?
Two situations come up.
The vendor shares source or a build with you. A contract may let you review code on a controlled machine. Run the runner there, and the code never has to be uploaded to prove what the scan found. You can then compare the SBOM it produces with the one the vendor gave you. Differences are your questions.
You want to check the SBOM against reality. An SBOM is a claim. Scanning the thing it describes tests the claim. The runner gives you a local way to do that when you have the code.
How do you start it?
Install the CLI with the one line installer from cli.safeguard.sh (macOS and Linux use curl -fsSL https://cli.safeguard.sh/install | bash, Windows uses irm https://cli.safeguard.sh/install.ps1 | iex). The docs say there is no Homebrew formula, winget package or container image for the runner.
Then run safeguard and type /login, approve the session in your browser, and the runner starts. The first run downloads scanner tools and the vulnerability database.
For headless use on a workspace:
safeguard runner start --workspace ./path/to/repo
safeguard runner status
safeguard runner stop
stop drains in flight work before it exits. If your network forbids held connections, pass --poll-wait 0 to poll at a fixed interval, set with SAFEGUARD_POLL_INTERVAL (default 10 seconds).
What are the limits?
The runner needs outbound HTTPS. The docs do not state supported languages or repository size limits for it. Policies and gates are evaluated in the platform, not by the CLI. And as with any scan, a clean result tells you nothing about components that are missing from the input.
Open the local runner demo on its own page.
What to do
- Decide which you hold: an SBOM file only, or code you may inspect.
- For a file, validate it and scan it with the CLI as described in the linked post.
- For code, install the CLI, log in, and start the runner on that workspace.
- Compare the SBOM the runner produces with the vendor's and list differences.
- Send the differences to the vendor as questions, and keep their answers with the evidence.
Quick check
Does source code leave my machine when I use the runner?
According to the docs, no. Only the resulting SBOM and findings are uploaded.
Can I point the runner at a vendor SBOM file?
The runner docs do not say so. The CLI docs describe scanning an existing SBOM with safeguard scan.
Sources
- Safeguard Local Runner docs, fetched 18 October 2026
- Safeguard CLI overview, fetched 18 October 2026
Last reviewed: 18 October 2026.
