The promise of security gates in CI/CD pipelines is compelling: automate security checks, fail builds on critical findings, and nothing dangerous ships without being caught. The reality in most organizations is different. Security gates get added, engineers encounter noisy or slow checks, someone adds a bypass flag, and six months later the gate is either disabled or set to warn-only. The team has learned that security gates are an impediment, not a safety net.
This isn't an argument against security gates. Done well, they're one of the highest-leverage investments in an AppSec program. Done poorly, they create adversarial relationships between engineering teams and security. The difference is architecture and configuration, not intent.
The anti-patterns that cause teams to disable security checks
Before describing what works, it's worth being specific about what doesn't. The failure modes are consistent:
Gates that block on too many things. A SAST scanner configured to fail the build on medium-severity findings in a codebase with 500 existing medium findings will block every PR from day one. Engineers will raise tickets to disable it within a week. The correct initial configuration for a legacy codebase is to fail only on new findings above a threshold — not findings that already existed before the gate was added.
Gates that are slow. A security scan that adds 12 minutes to every PR build creates sustained friction. Engineers start looking for ways to skip it. For pre-commit hooks especially, latency above 2-3 seconds causes adoption to drop sharply. The tooling choice matters: a full OWASP ZAP DAST scan is appropriate for nightly builds; it's not appropriate as a PR gate.
Gates without context. A build that fails with "1 critical vulnerability found in dependency X" gives an engineer no useful information. They need: what the vulnerability is, what CVE or CWE it maps to, whether it's reachable in your application, what the fix is, and how urgent it is. Without that context, the engineer either marks it as a false positive (possibly incorrectly) or blocks the delivery conversation while they research it themselves. Tooling that provides actionable context in the build output — Snyk's PR annotations, CodeQL's SARIF output in GitHub Security tab, Semgrep's rule explanations — reduces that friction meaningfully.
Gates that nobody owns. A security gate that fails generates a finding. That finding needs an owner. If it's unclear whether the engineer who triggered the build, the security team, or the tech lead is responsible for triaging and resolving the finding, it won't get resolved. Unresolved findings pile up, the backlog becomes unmanageable, and the gate loses credibility.
Designing a gate architecture that works
Think of your CI/CD pipeline as having three distinct security gate positions, each with different characteristics and appropriate tools:
Pre-commit gates run locally on the developer's machine before code is committed to the repository. They should be fast (under 2 seconds), focused on a narrow finding class, and low false-positive. Good candidates: secret detection (Gitleaks, detect-secrets), basic linting for obvious anti-patterns, license compliance checks. Bad candidates: full SAST scans — too slow, too noisy for pre-commit.
PR gates run in CI when a pull request is opened or updated. They should complete within the overall PR build time budget (typically 5-10 minutes). They can be more comprehensive than pre-commit gates. Good candidates: incremental SAST (Semgrep or CodeQL scoped to changed files), dependency vulnerability checks (Snyk, Dependabot), IaC misconfiguration scanning (Checkov, tfsec) for infrastructure changes. These gates should fail on critical and high-severity new findings. They should warn on medium findings without blocking.
Build/deploy gates run before a release is promoted to production. They can take longer and can be more comprehensive. Good candidates: full SAST on the release branch, container image scanning (Trivy, Grype), DAST scans against a staging environment, software composition analysis. These gates hold the release, not the development flow.
The paved-road model versus the gate model
There are two philosophies for security tooling in the SDLC, and the best programs combine both.
The gate model is reactive: scan what engineers produce and block or flag findings. It's necessary, but it creates friction and doesn't improve the underlying quality of the code being written.
The paved-road model is proactive: provide secure defaults, libraries, and patterns that make the right thing easy. A pre-approved OAuth library that handles token validation correctly. A database access layer that enforces parameterized queries by construction. An internal HTTP client that always adds the right security headers. Engineers who use the paved-road components don't produce the finding in the first place — the gate doesn't need to catch it.
The paved-road model requires more upfront investment but produces better long-term outcomes. For a growing engineering team, start with gates (faster to implement) and invest in paved-road components as you identify the finding categories that keep appearing.
GitHub Actions example: incremental SAST gate
A practical PR gate for a JavaScript/TypeScript project using Semgrep:
name: Security PR Gate
on: [pull_request]
jobs:
semgrep:
runs-on: ubuntu-latest
container:
image: semgrep/semgrep
steps:
- uses: actions/checkout@v4
- run: semgrep ci --config=auto --error
env:
SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}The --error flag causes Semgrep to exit non-zero only on blocking findings (severity configured in your Semgrep policy). The --config=auto selects rules appropriate for the detected language. This adds approximately 30-90 seconds to a PR build on a typical codebase, which is within the acceptable range for a PR gate.
Measuring whether your gates are working
Two metrics that matter for security gate effectiveness: bypass rate (what percentage of failing gates result in someone overriding or disabling the gate rather than fixing the finding), and escape rate (what percentage of vulnerabilities are found in production rather than in CI). If your bypass rate is high, your gate is too noisy. If your escape rate is high, your gate coverage is insufficient.
Neither of these metrics is easy to measure without instrumenting your pipeline specifically for them. But the qualitative version — are engineers fixing findings or bypassing gates? — is visible in your PR history and in how your team talks about security checks in sprint retrospectives.
A security gate that engineers trust is one they use to make better decisions, not one they route around to make their sprint metrics look good. Getting to that state requires starting with configurations that are accurate, fast, and actionable — not comprehensive. You can broaden scope once the trust is established.
