You can scan on every change two ways: run the Safeguard CLI inside your CI job, or connect the repository so the platform scans it and evaluates policies and gates. Connecting gives you gates with nothing in the pipeline. The CLI keeps code on your runner and gives you local control. Many teams use both.
The two models
The CI/CD documentation describes them side by side:
- Connect the repository. The platform scans it and evaluates policies and gates. Nothing runs in your pipeline.
- Run the CLI in the job. The scan and detect commands run on the build machine and write results you can keep as artifacts or send to a code scanning view.
The documentation says to connect the repository so gates evaluate every result, and it lists no pipeline plugin yet.
Where each one wins
Connected repository
- Policies and gates are evaluated in the platform, so enforcement does not depend on every pipeline author remembering a step.
- Nothing to install or pin in CI.
- One place to see results across repositories.
CLI in the job
- The code is scanned on your own runner, and per the docs only SBOMs and findings are uploaded.
- Works for repositories you cannot, or will not, connect.
- Gives you files to feed other tools, such as SARIF for a code scanning view or JSON for a dashboard.
- You choose the exact moment and inputs, such as the built image.
Where each one costs you
Connected repository. It requires granting the platform access, which is a security decision for your team. Results arrive from the platform side rather than inside the job, so a job cannot easily branch on them.
CLI in the job. You own the plumbing: install, pin, scanner tools, artifacts and failure rules. The CLI reports but does not fail on findings, so a local gate means extra shell, such as a jq check.
A quick decision guide
- Code cannot leave your network and you cannot connect it: CLI.
- You want consistent gates on every repository with the least effort: connect.
- You need SARIF in your code host's security view: CLI with detect.
- You need to scan the built container image: CLI, since the image exists only in the pipeline.
- Auditors want evidence that a gate ran on every change: connect, and keep the pipeline artifacts too.
Combining them
A common setup connects the repository for gates and history, and runs the CLI in the job for artifacts and image scans. Keep the two honest with each other: if the numbers differ, check the CLI version, the database freshness and whether both scanned the same commit.
Plan for failure
Decide what happens when the scan step cannot run. A failed install, an expired sign-in or an exit code of 2 should block the release or alert someone, not pass silently. Write that rule down for whichever model you choose.
Quick check
Do I have to pick only one?
No. The documentation describes both models, and they can run together. Connect for gates and run the CLI for artifacts and image scans.
Which one stops a build on a critical finding?
The platform gates do, in the connected model. The CLI reports findings, so a local stop needs an extra check on its output.
You can see gates in action in the interactive demo.
Click through it at your own pace, or open it full screen.
Safeguard also offers a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
