Part V · Adoption · CI/CD · p. 58–59

Gates people do not disable

CI is where security tooling goes to be turned off. The difference is entirely in how you introduce it.

A pull request is not a scan report. It is a social object with a merge button. The CI scene: report lands where dashboards already live, gate fails at high on new findings, and the install step is pinned like any other supply-chain dependency.

GitHub Actions — in production, do not curl-pipe-shell in CI. Pin a version.

securegit scan . \
  --format sarif --report-output securegit.sarif \
  --baseline .securegit/baseline.json \
  --fail-on high

GitLab — the sast artifact lights up the security dashboard and MR widget.

securegit scan . --format gitlab --report-output gl-sast-report.json \
  --baseline .securegit/baseline.json --fail-on high

The four-stage introduction

Advisory, informational. Scan runs, prints findings, always exits zero. One week minimum.
Advisory, annotated. Findings appear as PR annotations. Still non-blocking.
Blocking on new findings only. Scan the diff, not the tree. This is the sustainable steady state for most teams.
Blocking on total. Only after the backlog is burned down. Many teams never reach this and should not feel bad about it.

Gate	Scope	Threshold	Speed
Pre-commit	staged only	high	under a second
Pre-push	push range	critical	seconds
PR / CI	diff vs. main	high	seconds
Nightly	full tree, all plugins	report only	minutes
Release	full tree + SBOM + CVE	critical	minutes

Findings count measures your codebase. Disable rate measures your adoption. Only one of them tells you whether the tool will still be here next quarter.