How do you triage a critical vulnerability with the local runner?

Install the Safeguard CLI, run it, type /login, then scan the repository from the interactive terminal. The scan, dependency graph and fixes all run on your machine, and only the SBOM and findings go to the platform. Then work the critical findings one at a time: confirm, check the fix, preview it, apply it.

This is useful when the repository is private, the network is restricted, or you want to fix code you have not pushed yet. The Safeguard docs describe the runner as part of the CLI, not a separate product.

How do you set it up?

1. Install. On macOS or Linux, use the installer at cli.safeguard.sh with curl -fsSL https://cli.safeguard.sh/install | bash. On Windows, use the PowerShell installer from the same site. The docs say the installer verifies the release checksum. They also say there is no Homebrew formula, winget package or container image for the runner.
2. Start the terminal by running safeguard with no arguments.
3. Type /login. Your browser opens, you approve the session, and the runner starts polling the platform for jobs assigned to this machine. The first run also downloads scanner tools and the vulnerability database.
4. Check your setup with safeguard doctor. It reports what is wrong in the order that matters and changes nothing.

All traffic is outbound HTTPS opened by the runner. Nothing connects in to it.

How do you scan?

From the interactive terminal, type /scan . while signed in. The docs say the runner uploads the SBOM and findings, never your source code, so the results show up in the platform next to your other projects. Results also land as JSON files in a local output folder, including a vulnerability file and a license file.

Two details from the docs matter for scripts. The scan command exits 0 whenever the scan ran, whatever it found, and there is no severity threshold flag. Gating on findings is done by policy gates in the platform, not by the exit code. The scan uses two open source tools that the interactive terminal downloads the first time, so a fresh CI container needs them on its path.

How do you triage a critical finding?

Work one finding at a time.

1. List the criticals. Ask in the terminal, or read the vulnerability file. For each, note the package, installed version, advisory ID and the version that fixes it.
2. Confirm you ship it. Is the package in what you deploy, or only a dev tool? Check the lockfile and the build.
3. Check exposure. Does your code call the vulnerable function? Safeguard documents reachability analysis for this question. Where the analysis is not available to you, read the advisory and search your code for the affected function.
4. Check exploitation. Look the advisory ID up in CISA's Known Exploited Vulnerabilities catalog. A listing means exploitation has been observed in the wild.
5. Ask the assistant. The terminal has an assistant. The docs give the example prompt "why is this CVE critical?" and describe asking what a version bump breaks. Treat answers as a starting point and check them against the advisory.
6. Preview the fix. The safeguard fix command updates vulnerable packages, writes a patched SBOM and emits a fix report. The docs describe a dry run mode that shows the diff before anything changes, and a mode that opens a pull request. Use the dry run first.
7. Run your tests, then merge through your normal review.

Can the assistant fix things for you?

Yes, with limits you control. The docs show safeguard agent with a plain-language request such as fixing the critical CVEs in the repository. For scripts and CI, safeguard exec runs one turn and exits, with strict permissions by default: nothing is asked, and anything the policy file has not pre-approved is denied. You can set how much the assistant may do without asking, from supervised to autonomous. Start supervised.

Open the full walkthrough at /demos/local-runner-cli.

What should you watch out for?

• Stale data. Run safeguard update to refresh the vulnerability databases. It is different from safeguard self-update, which updates the binary.
• Zero findings on a repo you know has issues. Check that the scan target is right, that the tools are installed and that the exit code was not 2, which the docs say means results were written but the vulnerability scan did not run.
• A fix that bumps a major version. Read the changelog, and run integration tests.
• Headless runners. In a restricted network, the docs note a polling option for networks that forbid held connections.

What to do

1. Install the CLI, sign in and run safeguard doctor.
2. Scan your most important repository from the terminal.
3. For each critical finding, confirm presence, exposure, exploitation and fix.
4. Preview fixes with the dry run before you change anything.
5. Merge through review, and rescan to confirm the finding is closed.
6. Record accepted risks with a reason and a review date.

Quick check

Sources

• Safeguard docs: Local Runner
• Safeguard docs: CLI usage
• Safeguard CLI site
• CISA, Known Exploited Vulnerabilities Catalog

Last reviewed: 18 October 2026.