To fix a vulnerable dependency with the Safeguard CLI, install it, log in, scan the repo, preview the upgrade with a dry run, then run the fix command with the pull request option. Everything runs on your machine. The runner uploads only the SBOM and findings, never your source code.
This is a walkthrough of that path, using the commands in the CLI docs. It also covers the assistant mode for cases where a plain version bump is not enough.
What do you need first?
The CLI installer is a one line script. On macOS or Linux:
curl -fsSL https://cli.safeguard.sh/install | bash
On Windows PowerShell:
irm https://cli.safeguard.sh/install.ps1 | iex
If you would rather read the script first, download it to a file and open it. The installer checks the archive against published checksums and stops on a mismatch. The docs list macOS and Linux on both amd64 and arm64, and Windows on amd64.
Then run safeguard with no arguments to open the interactive session and type /login. You approve the session in your browser using the device flow. The first run also downloads the scanner tools and the vulnerability database.
How do you find what needs fixing?
From the repo root:
safeguard scan --dir .
The scan builds an SBOM and matches it against the advisory database. It writes results per component, including vuln.json and license.json. If you already have an SBOM, you can point the scan at it instead, in SPDX or CycloneDX form.
Read the findings before you fix anything. The question to ask is whether the vulnerable package is a direct dependency you can bump, or a transitive one that a parent package pins.
How do you preview the fix?
Start with the dry run so nothing in your working tree changes:
safeguard fix --severity high --dry-run
The fix command updates vulnerable packages to safe versions, writes a patched SBOM and emits a fix report. The dry run shows you the planned changes. Look for major version jumps in the preview, because those are where a build is most likely to break.
How do you open the pull request?
When the preview looks sane:
safeguard fix --severity high --create-pr
This applies the upgrades and opens a pull request. The docs demo shows a lodash upgrade from 4.17.11 to 4.17.21 in package.json, which is the typical shape of a good fix: a small diff you can review in a minute. Let your normal CI run on that pull request. A scanner can tell you a version is safe from a known advisory. Only your tests can tell you the upgrade did not break your code.
When is the assistant mode better?
Some fixes need judgment: a breaking API change, a package with no patched release, or several findings that touch one another. For those, the runner includes an assistant:
safeguard agent "fix the critical CVEs in this repository"
A permission mode controls how much it may do without asking, from supervised to autonomous. Start supervised. For scripts and CI there is a one turn command, safeguard exec, which defaults to strict permissions and denies anything your policy file has not approved.
Try the local runner demo to see the commands in action.
What stays on your machine?
The runner docs say scans run locally and the runner "uploads only the resulting SBOM and findings, never your source code." Traffic is outbound HTTPS opened by the runner, and nothing connects inbound to it. That matters if your security team will not grant a vendor read access to repositories.
What are the limits?
The docs do not describe every flag, and the fix workflow for unpushed code is only briefly described, so run the help command for your installed version. A fix command cannot help when no patched version exists. In that case you are choosing between pinning, replacing the package or accepting the risk with a recorded reason.
What to do
- Install the CLI and log in with the device flow.
- Scan the repo and read the findings, noting direct versus transitive.
- Run the fix command with the dry run option and review the planned version changes.
- Run it again with the pull request option and let CI test the branch.
- For anything the fix command cannot resolve, use the assistant in supervised mode.
- Re-scan after merge to confirm the finding is gone.
Quick check
Does the local runner upload my code?
No. Per the runner docs it uploads the SBOM and findings only, and source stays on the machine.
Can I try the fix without changing files?
Yes. The dry run option previews the changes before anything is modified.
Sources
Last reviewed: 18 October 2026.
