Security gates in the pipeline

A security gate is an automated checkpoint that decides whether the pipeline may continue; set clear thresholds based on severity and fixability, separate blocking from warning, and provide a controlled emergency exit.

What a gate is

A security gate is a pipeline step that evaluates security tool results and returns pass or fail. Without gates, tools only produce reports nobody reads; with gates that are too strict, teams work around them. The goal is to block what matters.

A sample pipeline

flowchart TB
  subgraph R1["Before merge"]
    direction LR
    PR["Pull request"] --> G1{{"PR gate<br/>secrets, new SAST, IaC High"}}
    G1 -- "pass" --> M["Merge"]
  end
  subgraph R2["Build"]
    direction LR
    B["Build image"] --> G2{{"Build gate<br/>fixable Critical CVEs"}}
    G2 -- "pass" --> S["Sign + push + SBOM"]
  end
  subgraph R3["Release"]
    direction LR
    T["Deploy to staging"] --> G3{{"DAST gate<br/>no FAIL"}}
    G3 -- "pass" --> P["Prod (approval)"]
    P --> G4{{"Admission<br/>signature + policy"}}
  end
  R1 --> R2 --> R3

Gate	Blocks when	Only warns when
Secrets	Any secret at all	(never; always block)
SAST	New vulnerabilities of High or above	Code smells, old issues
SCA / image	Critical or High with a fix	Medium, Low, unfixed
IaC	High, Critical (public bucket, open SG)	Best practices not met
DAST	Rules configured as FAIL	WARNs such as missing headers (moved to FAIL over time)

Threshold principles

Block the new, track the old: like a Quality Gate on new code, so old debt does not fail forever.
Block when a fix exists: developers can act right away; unfixed issues are recorded with an SLA.
Thresholds are code: gate settings (.trivyignore, .checkov.yaml, Quality Gates) live in the repo or centrally and change through review.
The same for everyone: no "special" repo silently skipping gates.

The emergency exit

A production incident needs a hotfix now, and a gate blocks it over an unrelated CVE. You need a controlled break-glass: a label or an approval by someone authorised, logged, automatically opening a tracking ticket, and expiring. That is far better than everyone knowing how to switch the gate off.

Measuring

Track: the share of pipelines blocked by gates, mean time to fix, open exceptions, and break-glass uses. Gates blocking too much or too little are both signals to tune.

Traps: "report only" gates that never fail; each tool with an ad-hoc threshold nobody remembers; disabling a gate in a rush and forgetting to re-enable it; blocking every Medium so the pipeline is permanently red.