The Safeguard CLI has a fix command that updates vulnerable packages, writes a patched SBOM and a fix report. It supports a dry run to preview changes and an option to open a pull request. In a pipeline, run the dry run first and always keep human review before merge.
What the command does
The CLI site describes fix as updating vulnerable packages, writing a patched SBOM and emitting a fix report. A severity option limits it, with high as the example. A dry run option previews the changes, and a create PR option opens a pull request. The usage page only points to the help output for fix flags, so check that for your version.
# preview only
safeguard fix --severity high --dry-run
# open a pull request
safeguard fix --severity high --create-pr
Dry run in CI
A scheduled job that runs the dry run and archives the fix report gives you a picture of what would change, with no repository writes. It is a good first step because it needs no write permission and produces something a person can read.
Only after a few runs where the report looks sensible should you let a job create pull requests. At that point the job needs permission to push a branch and open a PR, so scope the token to that repository and nothing else.
Keep the review
A fix PR is a proposal. It should go through the same checks as a human change: build, tests, and review. A dependency update can change behaviour with no compile error. Make sure branch protection requires the same checks on bot authored PRs, and that the job cannot merge its own work.
Rolling back
Because the fix is a pull request, rollback is a revert. Keep PRs small, one logical update each, so a revert is clean. If one PR bundles many updates, a single bad one forces you to revert all.
Platform remediation
Separately, Safeguard's platform has autonomous remediation with fix pull requests. It is off by default, with every category set to manual. The CLI command above is a user run tool, which is a different path from that platform setting.
What to measure
Count how many fix PRs merge unchanged, how many need edits, and how many are closed. If most are closed, the severity filter is too loose or the tests are too thin to trust.
Start narrow
Begin with one low risk repository and one severity level. Watch the first ten fix pull requests by hand. Widen scope only when the team is comfortable with what the tool proposes. Fix automation that surprises people gets switched off, and then the benefit is lost.
Quick check
Can the pipeline merge the fix on its own?
It should not. Require review and passing checks on every fix pull request.
Does dry run change files?
It is documented as a preview of changes. Confirm on a scratch branch for your version.
Sources
Last reviewed: 19 October 2026.
