Install the Safeguard CLI, run a scan on your repository, preview the fixes with a dry run, and then let the CLI update the vulnerable packages and open a pull request. Review that pull request like any other change and let your tests decide whether it merges.
What do you need first?
The CLI installs with one command. On macOS or Linux:
curl -fsSL https://cli.safeguard.sh/install | bash
On Windows, in PowerShell:
irm https://cli.safeguard.sh/install.ps1 | iex
The installer checks the release checksum. The CLI page also suggests downloading install.sh and reading it before you run it, which is a good habit for any piped installer. You can pin a version with the SAFEGUARD_VERSION variable.
Then sign in:
safeguard login
This uses the OAuth 2.0 device flow. The command safeguard whoami shows the current token, and safeguard logout clears it.
How do you scan?
From the repository root:
safeguard scan --dir .
The scan builds the software bill of materials locally. According to the CLI page, your source is never uploaded; only the SBOM and findings leave the machine. You can also scan a repository URL, a container image reference or an existing SPDX or CycloneDX file.
Each run writes result files per component, including one for vulnerabilities, one for licenses, one for secrets and one for scorecard data. Read the vulnerability file first.
How do you preview a fix?
Use the fix command with a severity threshold and the dry run option:
safeguard fix --severity high --dry-run
The dry run previews the changes without applying them. Read the list of packages and versions it proposes. Look for major version jumps, since those are the changes most likely to break your build.
How do you apply it?
Run the command without the dry run flag, and add the pull request option if you want the change opened for review:
safeguard fix --severity high --create-pr
The CLI updates the vulnerable packages, writes a patched SBOM and emits a fix report. With the pull request option, it opens the PR for you.
For container images, the page lists a separate command, safeguard patch-image, which rebuilds an image with patched layers.
What should you check before merging?
An automated update is a proposal. Check four things.
First, does the test suite pass on the branch? If your coverage is thin where the library is used, add a test before you merge.
Second, read the changelog of any package that jumped a major version. Breaking changes hide there.
Third, scan again on the branch and confirm the finding is gone and nothing new appeared. Transitive dependencies can bring their own findings.
Fourth, check the patched SBOM and keep it with the build, so you can prove later what shipped.
What if no fix exists?
Then the CLI cannot update to a safe version. Look for a mitigation in the advisory, such as disabling a feature, and write down an owner and a review date. Rescan when a fixed release appears.
What to do
- Install the CLI and run
safeguard login. - Scan the repository root with the scan command above.
- Preview the fixes with the dry run version of the fix command.
- Apply the fix command with the pull request option.
- Run your tests on the pull request branch.
- Read changelogs for major version jumps.
- Rescan the branch, then merge and keep the patched SBOM.
Quick check
Does the CLI upload my source code?
According to the CLI documentation, the SBOM is built locally and your source is never uploaded. Only the SBOM and findings leave the machine.
Can I use the CLI in CI?
Yes. The CLI page shows a CI example that runs the scan and fails the build when the vulnerability results contain a critical finding. The steps are plain shell, so they work in other CI systems too.
Sources
Last reviewed: 18 October 2026.
