A scanner fits your CI system if it can run as a step you control, return a clear exit code, and report results back where developers already work. Ask whether it ships a native integration, a command line tool, or only an API, and test the one you will actually use.
What "supports our CI" can mean
Vendors use one phrase for several different things. Sort the answer into one of these levels before you accept it.
| Level | What it means | What to verify |
|---|---|---|
| Native app or plugin | Installed from your CI's marketplace | Version it works with, permissions it asks for |
| Command line tool | You call it from any pipeline step | Runs headless, exit codes, no interactive prompts |
| API only | You write the glue yourself | Auth model, rate limits, who maintains your script |
| Template or example | A sample pipeline file | Whether it is kept current or abandoned |
A command line tool is usually the most portable, because every CI system can run a shell command. A native plugin is more convenient but ties you to one platform.
Questions that matter in a trial
- Can the scan run on a clean runner with no human login? Ask how credentials are supplied and rotated.
- What does the step return when it finds something? You want a documented exit code and a machine readable report, not only a web link.
- Can results appear on the pull request itself, as a status check or comment?
- How does it behave when the scanner service is unreachable? See what to do when the scanner is down.
- How long does a typical scan take on a repository your size, and can it cache between runs?
- Does it work on self-hosted runners and ephemeral containers, or only on hosted ones?
Test it on your slowest pipeline
Pick the repository that already complains about build time. A scanner that adds forty seconds to a small service may add ten minutes to your largest monorepo. Run it on a branch, record the added time, and ask the vendor what tuning options exist: incremental scans, path filters, or scanning only changed files.
Also check the failure path. Introduce a known vulnerable dependency on a test branch and confirm the pipeline blocks as your policy says it should. A gate that never fails is not a gate.
Permissions and secrets
Ask what access the CI integration needs. Read access to source is common. Write access to branches is needed for fix pull requests but should be optional. Anything that requests organisation wide admin rights deserves a written explanation.
Where a token lives matters too. Prefer short lived credentials from your CI's own identity mechanism over a long lived secret pasted into settings.
Try it yourself
Click through it at your own pace, or open it full screen.
Click the pull request gate and watch what a blocked merge looks like, then ask whether any tool you evaluate shows the same clarity to a developer.
Quick check
Is an API enough for CI integration?
It can be, but you own the glue code and its upkeep. Prefer a command line tool or native step unless you have a reason to script it yourself.
Should a CI scan block every build?
Not at first. Start in report mode, review the noise, then block on a narrow set such as known exploited or reachable critical findings.
Safeguard offers policies, gates and guardrails for pull requests and SBOM and dependency scanning, and you can try a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
