Run scans from the command line when you want a fast local check, are investigating something, or work in a pipeline your CI service does not cover. Use CI for anything that must apply to every change. The CLI is a tool, and CI is a control point.
What each is for
A command line scanner runs wherever you run it: your laptop, a build agent, a jump host. It is flexible and scriptable. CI is a place where your team agreed to run checks automatically on each change.
The same command can often do both jobs. The difference is who triggers it and whether anyone can skip it.
When the CLI is the better choice
- Before pushing. A developer wants to check a branch without waiting for a pipeline.
- Investigations. Someone wants to scan a specific directory, an old release, or a downloaded artifact.
- Unusual build systems. Your CI platform has no native integration, so a command in a script is the integration.
- Restricted networks. Builds on isolated infrastructure still need a scan step you can call directly.
- Triage. Reproducing a finding locally to understand it before opening a ticket.
When CI is the better choice
- You need the result to block a merge.
- You need the same settings on every change.
- You need a record that the scan ran, with the version of tool and data.
- You are collecting evidence for an audit or a customer.
Comparison
| Need | CLI by hand | CI job |
|---|---|---|
| Speed of feedback | Fast | Depends on queue |
| Enforced for everyone | No | Yes, if required |
| Reproducible settings | Only if scripted | Yes |
| Good for one-off analysis | Yes | Awkward |
| Audit evidence | Weak | Strong |
A common failure
A developer runs the scanner once, sees a clean result, and assumes the pipeline will agree. Then CI fails on a different dependency resolution or a newer advisory, and trust in the tool drops. Naming the cause early (version, data timing, settings) saves a long thread.
Make the two agree
The worst outcome is a CLI scan that passes locally and a CI scan that fails with different settings. Avoid it by keeping the config in the repository and calling the same command in both places. Pin the scanner version in CI and tell developers which one to install locally.
A small checklist
- Store scanner settings in the repository, not in personal dotfiles.
- Use the same command locally and in CI.
- Pin versions in CI and update them on a schedule.
- Make CI the only source of pass or fail for merging.
- Treat local results as advice.
Where Safeguard fits
The Safeguard CLI is at version 1.4.0 on the download page, with curl and PowerShell installers (npm is listed as coming soon). The same policies can apply on pull requests as gates. Try a scan first at https://gold.safeguard.sh/scan.
Quick check
Can a CLI scan count as audit evidence?
It can, but a CI run is easier to defend because it is recorded, repeatable, and independent of one person's machine.
Why do local and CI results differ?
Usually different tool versions, different advisory data timing, or different settings. Keep config in the repository and pin versions.
Last reviewed: 19 October 2026.
