CI/CD gating is the use of checks that must pass before code moves through a continuous integration or continuous delivery pipeline. It can include automated tests, security scans, policy checks, manual approvals, and deployment rules that block promotion until conditions are met.
What CI/CD gating means in practice
CI/CD gating turns the pipeline into a controlled promotion path rather than a simple handoff. Each gate is a decision point that stops unverified code, artifacts, or configuration from advancing until required checks are satisfied.
That makes the concept less about a single tool and more about trust boundaries. A gate can be automated, manual, policy-driven, or risk-based, but its job is the same: prevent unintended changes from reaching production or other sensitive environments.
What CI/CD gating is designed to control
The main function of gating is to reduce the chance that unsafe code, compromised dependencies, or misconfigured build outputs move forward unnoticed. It is especially important where one pipeline step can influence later steps, because the further a bad change travels, the harder it is to unwind.
Gating also helps separate routine development activity from higher-risk release activity. For example, a merge gate may be appropriate for code quality and test coverage, while a deployment gate may also require security review, artifact attestation, or approval from an owner with release authority.
What usually sits behind a gate
Common gate checks include automated tests, static and dynamic security scanning, dependency checks, artifact integrity validation, branch protection rules, policy-as-code decisions, and environment-specific approvals. Some organisations also gate on provenance, signed commits, or signed build outputs when release integrity matters.
The exact mix depends on what the pipeline is protecting. A fast-moving internal service may rely mostly on automated checks, while a regulated or externally exposed system usually needs stronger controls over who can approve, what evidence must exist, and which artifacts are allowed to deploy.
Why gating matters for release integrity
CI/CD gating is most valuable when the pipeline itself is part of the attack surface. If an attacker can alter source, workflow logic, runner behaviour, or artifact content, the pipeline can become a delivery channel for malicious changes rather than a control point.
That is why gating is often paired with artifact provenance and supply-chain controls. SLSA is useful here because it frames build provenance and integrity verification as a trust problem, not just a build problem.
Risk and Threat Considerations
CI/CD gating reduces exposure, but only if the gate is meaningful and actually enforced. Weak approval logic, overbroad permissions, skipped checks, or compromised pipeline identities can let malicious code pass as if it were trusted.
Failure mechanism: Attackers target the pipeline’s trusted paths, such as stolen tokens, poisoned workflows, compromised dependencies, or weakened approval rules, then use the pipeline to promote malicious changes or exfiltrate secrets.
Impact: A bypassed or misconfigured gate can lead to unauthorized code release, secret exposure, artifact tampering, or downstream compromise of production systems and customer environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | CI/CD gating often enforces build provenance and artifact integrity before release. |
| Recommendation — Use SLSA to require trustworthy provenance before promoting build artifacts. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Gates control when code and configuration changes are allowed to progress. |
| IA-5 — Authenticator Management | Pipeline gates often depend on token, key, and credential handling for promotion control. | |
| Recommendation — Apply CM-3 to approve and document changes before they move through the pipeline. Apply IA-5 to manage pipeline credentials and rotate any secrets used in gated releases. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Gating commonly includes secure design and architecture checks before deployment. |
| V16 — Security Logging and Error Handling | Gated pipelines need logs that prove which checks ran and why promotion was blocked. | |
| Recommendation — Use V15 to require security review and architectural checks before release. Use V16 to log gate outcomes and preserve evidence for release decisions. | ||
Practitioner Guidance
Why practitioners should care: Gating only works when the check actually blocks promotion and the evidence behind it is trustworthy. Treat the gate as a release control, not as a dashboard signal that people can ignore.
Common misunderstanding: Adding more checks does not automatically create stronger security. Poorly scoped gates can slow delivery without reducing risk, while a small number of well-chosen gates can give better protection if they are tied to the real release decision.
Practitioner takeaway: Design gates around the highest-risk transition in the pipeline, then make sure the approval, scan, and provenance signals are resistant to tampering.