The Safeguard CLI reports findings but does not fail a build on them, and it has no severity threshold flag. To gate a pull request, run the CLI in CI to produce results, then add your own pass or fail check, or let the platform's policy gates decide on a connected repository.
What does the CLI give you in CI?
The CI/CD Integration docs describe two paths. You can connect the repository so the platform scans it and evaluates your policies and gates, with nothing running in your pipeline. Or you can run the CLI in the job and keep its output. The docs say the CLI reports findings and does not fail a build on them, and that enforcement belongs to the platform.
Two commands cover most pipelines. safeguard scan builds an SBOM and matches it against vulnerability databases. safeguard detect finds secrets and misconfigurations, with table, JSON or SARIF output.
What do the exit codes mean?
| Command | Exit code | Meaning |
|---|---|---|
| scan | 0 | The scan ran, whatever it found |
| scan | 2 | Results were written but the vulnerability scan did not run |
| scan | 1 | The command failed |
| detect | 0 | The scan ran, whatever it found |
An exit of 0 therefore says nothing about risk. Most CI systems fail a step on any non zero exit, so a 2 would likely fail the job even though findings do not gate it. That is an inference from how CI runners behave, so check your own.
How do you write your own gate?
Run the scan and write results to a folder:
safeguard scan --dir . --output out/
The CLI site shows a check you can run afterwards with jq against the vulnerability file:
jq -e '[.data.matches[].vulnerability.severity | ascii_downcase] | index("critical") | not' out/*/vuln.json
That command exits non zero when a critical match exists, so the CI step fails. Treat it as a starting point, not a policy. Confirm the file layout on a real run before you trust it, and decide in writing what severity blocks a merge and who can override.
For secrets and misconfiguration, upload SARIF to your code scanning view. The GitHub Actions example in the docs is:
safeguard detect --format sarif --output safeguard.sarif
The job needs the security-events: write permission, and the docs use the CodeQL upload SARIF action for the next step. GitLab, Jenkins and Azure DevOps variants are in the same page.
Why would you use a platform gate instead?
Your own jq check is simple and visible, but it stops at one rule. Platform gates are policies written in YAML with a target, rules and an effect of BLOCK, WARN or AUTO_FIX, and they apply across repositories with an exception process. The docs note the CLI has no gate command, so gates run on the platform's scans of connected repositories.
A common split is to let the platform gate decide, and keep the CLI step for artifacts and local checks.
Walk through the flow at /demos/gate-pull-request.
What are the limits?
The docs state there is no published GitHub Action, container image or pipeline plugin for the CLI yet. A dependency gate that checks manifests against the free Gold database and can fail on actively exploited (CISA KEV) dependencies is described as built but not yet published, so do not plan around it. Scan also runs syft and grype, which must be on the path or in a directory named by TOOLS_DIR.
What to do
- Pin the CLI version in CI with
SAFEGUARD_VERSIONon the installer, so a release cannot change your builds. - Put syft and grype on the path, or set
TOOLS_DIR. - Run
safeguard scan --dir .with an output folder, and keep it as a build artifact. - Decide your blocking rule in writing, for example critical and exploited findings, and encode it in a check.
- Upload
safeguard detectSARIF so findings show on the pull request. - Try the pipeline on a branch with a known vulnerable dependency and confirm it fails.
- Connect the repository so platform gates can apply the same rule consistently.
Quick check
Does a clean exit code mean the pull request is safe?
No. Exit 0 means the scan ran, whatever it found. You need a separate check on the results.
Should I rely on the CLI or the platform for gating?
The docs put enforcement in the platform. Use your own CLI check as a simple stopgap, then move the rule into a policy gate.
Sources
- Safeguard docs: CI/CD Integration, fetched 18 October 2026
- Safeguard docs: CLI, fetched 18 October 2026
- Safeguard CLI site, fetched 18 October 2026
- Safeguard docs: Guardrails and Enforcement, fetched 18 October 2026
Last reviewed: 18 October 2026.
