Triage a critical vulnerability with the Safeguard CLI, step by step

To triage a critical vulnerability with the Safeguard CLI, install the binary, run a local scan of the directory, filter the results for critical severity, preview the fix with a dry run, and then open a pull request. The scan runs on your machine and only results leave it.

What do you need first?

The CLI is a single binary. The installer detects your operating system and architecture, verifies the release checksum, and puts one safeguard binary on your path. On macOS or Linux:

curl -fsSL https://cli.safeguard.sh/install | bash

On Windows PowerShell:

irm https://cli.safeguard.sh/install.ps1 | iex

The CLI page suggests reading the script first if you prefer, which is a good habit: download it to a file and open it before you run it. You can pin a release with the SAFEGUARD_VERSION environment variable.

Step 1: sign in and scan

Authenticate the machine with the device flow, then scan the directory you care about.

safeguard login
safeguard scan --dir .

safeguard scan builds the software bill of materials from source and matches it against the advisory database. It also accepts a Git repository, a container image or an existing SPDX or CycloneDX file in place of a directory. The CLI page describes the run as local: the dependency graph, vulnerabilities, secrets and licence risks are computed on your machine, and the SBOM and findings are the payload the platform receives when you choose to send them.

If your advisory data is stale, safeguard update refreshes the local vulnerability databases.

Step 2: read the findings

A scan writes its artifacts to an output folder. The CLI page says each run produces the SBOM plus vuln.json, license.json, secret.json and scorecard.json per component, and that vuln.json is grype compatible under .data.matches. That makes it simple to filter with a standard JSON tool. This example, taken from the CLI page's pipeline gate, checks that no critical finding is present:

jq -e '[.data.matches[].vulnerability.severity | ascii_downcase] | index("critical") | not' out/*/vuln.json

Run your scan with an output directory so the files land where you expect, as the page's example does with --output out/.

Step 3: decide what to do about each critical

For every critical finding, ask three questions.

1. Is the package really in the build, or only in a test or dev tool?
2. Is the vulnerable code path reachable from your application?
3. Is a fixed version available, and what does the bump change?

The interactive mode of the CLI helps here. Running safeguard with no arguments opens a runner session with an assistant, where you can ask why a finding matters or what a version bump breaks. Use the answer as a lead, then confirm it in your code.

Step 4: preview, then fix

Update vulnerable packages with:

safeguard fix --severity critical --dry-run

The --dry-run flag previews the change so you can read the diff before anything moves. When you are satisfied:

safeguard fix --severity critical --create-pr

The CLI page says safeguard fix updates vulnerable packages to safe versions, writes a patched SBOM and emits a fix report, and that --create-pr opens the pull request. Review it like any other change and let your own tests run.

Step 5: keep the record

safeguard report generates a report from an existing scan result, which is the artifact you can hand an auditor. Attach it to the ticket along with the pull request link.

Try it

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

What to do

1. Install the CLI and read the install script before running it.
2. Run a local scan with an output directory.
3. Filter vuln.json for critical findings and list the packages.
4. Check presence, reachability and fix availability for each.
5. Run the fix with a dry run and read the diff.
6. Open the pull request, let tests run, and merge when green.
7. Generate the report and attach it to your ticket.

Quick check

Sources

• Safeguard CLI documentation and command reference

Last reviewed: 18 October 2026.