Set the SAFEGUARD_VERSION environment variable on the install command to pin a release, and update it deliberately. For extra control, set the variables that turn off update checks and self updates, so the binary never changes underneath a running build or agent.
Why pin
A build that downloads whatever is newest gets different behaviour on different days. A scanner is not a compiler, but the same logic applies. If the output format or exit code behaviour changes, your gate or parser can break without a commit on your side.
Safeguard's documentation says the same thing in its best practices: pin the CLI version and update it deliberately.
How
The installer is the same one used locally. The CLI site says the SAFEGUARD_VERSION variable pins a release and SAFEGUARD_INSTALL_DIR sets the install location.
export SAFEGUARD_VERSION="<version from the download page>"
export SAFEGUARD_INSTALL_DIR="$HOME/.local/bin"
curl -fsSL https://cli.safeguard.sh/install | bash
export PATH="$SAFEGUARD_INSTALL_DIR:$PATH"
The installer detects the operating system and architecture and verifies the release checksum before installing. Supported builds are macOS and Linux on amd64 and arm64, and Windows on amd64.
Stop silent updates
The system configuration page lists two switches. One skips the background check for a new release. The other turns off binary updates entirely.
export SAFEGUARD_NO_UPDATE_CHECK=1
export SAFEGUARD_DISABLE_SELF_UPDATE=1
On a throwaway CI container these rarely matter, but on long lived self hosted agents they do.
Where to find the version
The download page shows the current CLI version, at the time of writing 1.4.0. Be aware that the page's archive file names showed a different version string when we checked, so read the version label on the CLI card, and confirm the installer accepts it before committing it to a pipeline. The CLI site's own example uses an older value, which tells you versions are expected to move.
A reasonable update routine
Keep the version in one place, such as a shared variable or a template. Update it in a branch, run a scan on a known repository, and compare the output files and exit codes with the previous version. Merge only if they match, or if you understand the difference.
Direct binaries
The download page also offers archives with checksums, and each release publishes a SHA256SUMS file. If your policy forbids piping a script into a shell, download the archive, verify the checksum, and install it yourself.
Rolling back
If an update breaks a pipeline, the pinned variable is also your rollback. Revert the version line, and the pipeline returns to the previous binary. That is only true if you did not also change the scanners or the pipeline logic in the same commit, so update one thing at a time.
Quick check
Does the installer verify what it downloads?
The documentation says it checks the release checksum before putting the binary on your PATH.
Is npm install available?
Not yet. The CLI site lists npm as coming soon.
Sources
- Safeguard CLI site
- Safeguard docs: CLI system configuration
- Safeguard docs: CI/CD Integration
- Safeguard download page
Last reviewed: 19 October 2026.
