Connect the repository when you want policies and gates evaluated with nothing to maintain in the pipeline. Run the CLI in the job when you need results inside the build, on a runner you control, or on code the platform cannot reach. Many teams do both.
Route 1: connect the repository
Safeguard's CI/CD documentation lists this first. Once the repository is connected as an integration, the platform scans it and evaluates your policies and gates. The documentation says nothing needs to run in your pipeline.
It suits teams that want one place for rules and results, who would rather not maintain install steps across dozens of repositories, and who are fine with the platform reading the repository through the host integration. The documented host families include GitHub, GitLab, Bitbucket and generic Git, public and private.
Route 2: run the CLI in the job
The CLI runs scan and detect on the build machine and produces files you can keep as artifacts, or upload to a code scanning tab. You choose when it runs and what it sees, including build outputs that never reach a repository.
It suits teams that want results as part of the build record, that scan container images or SBOMs produced by the build, or that cannot let a hosted service clone the code. The CLI documentation notes that the runner executes platform jobs locally and uploads SBOMs and findings, never source.
Side by side
On setup effort, connecting is a one time integration while the CLI is a few lines per pipeline. On gating, connecting gives you policy gates directly, while the CLI needs a platform gate or your own check. On control, the CLI wins, because it runs where you say. On coverage of unusual build outputs, the CLI wins again.
Why not both
Both routes feed the same engine. A common setup is to connect repositories for continuous scanning and gate evaluation, and to run the CLI in only the pipelines that build images or produce release SBOMs. If you do this, keep the rules in the platform so the two routes cannot disagree.
A short decision list
Choose connect first if you have many repositories, few platform engineers, or a policy first mindset. Choose the CLI first if you have a regulated build environment, air gapped runners, or a need to archive scan output with each build. Revisit the choice when the dependency gate in the documentation is published, since it targets pipelines.
Changing your mind later
The choice is not permanent. You can start with a connected repository, see results quickly, and add pipeline steps later for the builds that need them. Going the other way is also fine. What you should avoid is two sets of rules, one in a platform and one in YAML flags, because they drift apart and nobody remembers which is authoritative.
Quick check
Do I have to pick one?
No. They are not exclusive. Pick per repository based on where the decision should be made.
Which one blocks a merge?
Policy gates in the platform do. See how to gate a build.
Sources
Last reviewed: 19 October 2026.
