Pin the Safeguard CLI in CI by setting the version variable on the install line, so every run installs the same release. Without it, the installer fetches the latest version, and a pipeline that passed yesterday can behave differently today. Upgrade on purpose, in a separate change, with a test run.
Why drift hurts
A scanner changes in three ways between releases: its commands and flags, its output format, and what it detects. Any of these can turn a green pipeline red, or worse, turn a red one green without anyone noticing.
If you gate builds on the output file, a format change can break your jq filter silently. Pinning gives you a stable base and lets you choose when to absorb the change.
The pin itself
On macOS and Linux:
curl -fsSL https://cli.safeguard.sh/install | SAFEGUARD_VERSION=VERSION_HERE bash
On Windows, set the variable first:
$env:SAFEGUARD_VERSION = "VERSION_HERE"
irm https://cli.safeguard.sh/install.ps1 | iex
Replace the placeholder with a release you have tested. The docs say pinning is commonly used in CI.
Find out what is current
The installation docs point to a latest version file on the CLI site. Fetching it tells you what an unpinned install would get today. Note that the version numbers shown on the public pages we looked at were not fully consistent with each other when we checked, so trust the version command on a machine you installed on, not a number from a marketing page.
safeguard --version
Print it at the top of every pipeline run. When a result looks odd, the first question is always which version produced it.
Turn off surprise updates
The CLI can check for new releases in the background and update itself. Two variables control that: one skips the release check, and one disables binary updates entirely. In CI, set both so a runner never changes the tool mid-job.
export SAFEGUARD_NO_UPDATE_CHECK=1
export SAFEGUARD_DISABLE_SELF_UPDATE=1
An upgrade routine that works
- Read the release notes if the release has any.
- Bump the pinned version in one branch.
- Run the pipeline against a repository whose results you know.
- Diff the output files against the previous run: counts, file names, severity fields.
- Merge, and note the version in your change log.
Do the same for the scanner tools the scan command depends on, since a change in them can also move results.
Keep checksum verification on
Pinning and checksums work together. The installer compares the archive with the release's checksum file, and the shell installer aborts if that file is missing. Only skip verification for an internal mirror, and verify by other means.
Quick check
What happens if I do not pin the version?
The installer fetches the latest release each run. Results and flags can change between runs without any change in your code.
How do I stop the CLI updating itself on a build agent?
Set the variable that disables self update, and the one that skips the release check, in the job environment.
Safeguard also offers a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
