Reference

CI/CD integration

Running ScanSuite scans from a build pipeline.

ScanSuite scans run from a build pipeline through the command-line interface. The pipeline submits a scan to a ScanSuite server; the server does the work on its own workers, so build agents stay free.

What to run, and when

Full analysis on every commit is rarely worth it. A workable split:

Trigger	Suggested scan
Pull request	sast_quick, plus secrets. Fast enough not to be resented, and secrets are the finding you most want caught before merge.
Merge to main	mlsast in incremental mode. Only what changed is re-analysed, so per-commit AI analysis stays affordable.
Nightly or weekly	The full set — mlsast with reachability, dep_checks, iacs_kics.
Release	A dynamic scan against the deployed staging environment.

Incremental mode is the key to pipeline economics. Run one full scan first so a checkpoint exists, then switch the pipeline to --mode incremental — see Scheduling periodic and incremental scans.

A pull-request step

bash

python scansuite-scan-git.py \
  -s "$SCANSUITE_URL" \
  -u "$SCANSUITE_USER" \
  -p "$SCANSUITE_PASSWORD" \
  -l java \
  -g "$CI_REPOSITORY_URL" \
  -b "$CI_COMMIT_BRANCH" \
  --engagement-id "$SCANSUITE_ENGAGEMENT_ID" \
  --scanners sast_quick,secrets \
  --mode once

Supply the password from your CI secret store, never as a literal in the pipeline definition. -p exists for automation; the interactive prompt is the better choice everywhere else.

An incremental step on merge

bash

python scansuite-scan-git.py \
  -s "$SCANSUITE_URL" \
  -u "$SCANSUITE_USER" \
  -p "$SCANSUITE_PASSWORD" \
  -l java \
  -g "$CI_REPOSITORY_URL" \
  -b main \
  --engagement-id "$SCANSUITE_ENGAGEMENT_ID" \
  --scanners mlsast \
  --mode incremental

Reuse the same engagement ID, repository URL, scanner configuration, branch and language across runs. The server matches on those to find the comparison checkpoint; change one and you get a full scan instead.

Alternatives to polling from the pipeline

You do not have to drive scans from CI at all. Two server-side options cover most of what a pipeline trigger achieves, without a build step:

Monitor Changes — the server checks the branch hourly and scans only what moved. Set it up once from the console or with --mode monitor-changes.
Scheduled scans — daily, weekly or monthly runs, for the heavier engines that do not belong in a build.

Getting results back

Findings land in Vulnerability Management and, for the engines that export there, in DefectDojo. Reports are downloadable from Scan History, and vulnerability records export to XLSX.

Setting up API keys and the AI provider used by these scans is covered in Configuring API keys for external systems and AI providers and cost.

Last reviewed 2026-08-16