Where to Put Security Gates in Your CI/CD Pipeline
A security gate that blocks every deploy for ten minutes gets disabled the first time it's in the way of a real release. A gate that only reports and never blocks catches nothing that matters. Most teams pick the wrong default for each check, and the fix is to decide gate by gate rather than applying one policy to the whole pipeline.
Here's how to place each kind of check so it actually gets enforced instead of routed around.
Should secrets scanning always block a pull request?
A committed API key or credential is the one class of finding where speed doesn't matter: block the merge, every time, no exceptions for "just this once." Run it on every pull request, not just on merges to your main branch, so a leaked secret never lands in history at all, since removing it from git history after the fact is a much bigger job than catching it before commit.
Keep the false-positive rate near zero by tuning the scanner's patterns to your actual codebase early. A secrets scanner that cries wolf on test fixtures gets muted within a week, and a muted scanner catches nothing.
When should dependency and SAST scans block a merge?
Blocking a merge over a low-severity finding in a dependency you don't even call from production code trains engineers to bypass the gate rather than fix the underlying issue. Set the blocking threshold at high or critical severity with a known exploit path, and route everything else to a dashboard someone actually reviews on a schedule.
This isn't lowering your standard, it's matching the gate's strictness to how confident the finding actually is. A tool that blocks on speculative findings loses credibility fast, and credibility is what makes a blocking gate work at all.
Size your gate's runtime against how often you actually deploy
A team shipping multiple times a day can't tolerate a fifteen-minute security scan on every push, but a team deploying weekly has more slack to run a heavier check. Teams with the strongest deploy frequency ship on demand rather than on a fixed weekly or monthly release train, and that pace only holds up when every gate sitting in the deploy path is fast enough not to become the new bottleneck itself1.
If your current deploy cadence is closer to weekly, that's a reasonable place to run a more thorough scan on every push; if you're aiming for daily or better, move the heavy scanning to a scheduled nightly job against your main branch and keep the per-push gate fast and narrow. Say your full dependency scan takes eight minutes: running it on every push adds real friction to a team shipping ten times a day, but running it once overnight against main catches the same issues within hours instead of within a year at your next scheduled review.
Give every blocked build a specific, actionable message
A build that fails with "security check failed, see logs" sends an engineer hunting through console output for the actual problem. A build that fails with the exact file, line, and finding, plus a one-line explanation of why it matters, gets fixed in minutes instead of escalated to whoever owns the security tooling.
This single change does more to keep a gate enforced than almost any policy decision, because the gate's cost to the team is mostly about how long it takes to resolve a failure, not whether the failure happened.
For example, a scanner fails a build with the message "policy violation" and a link to a long report. The engineer spends twenty minutes finding a single hardcoded test token in one file and then asks the security owner whether it is real. If the message had named the file, the line and the reason a hardcoded token matters, the fix would have taken a minute and the security owner would never have been pulled in. When you review your gates, read the failure message as if you were a new hire seeing it for the first time.
Review your gate list quarterly and remove what nobody acts on
A dashboard of findings nobody triages isn't a control, it's noise that makes real findings harder to spot. If a non-blocking check has generated three quarters of findings with zero remediation, either make it blocking with a tighter scope or retire it. A pipeline with twelve scanning steps that everyone ignores is worse than one with four that people actually respond to.
Place each gate using these rules:
- Run secrets scanning on every pull request and always block, with patterns tuned early so false positives stay near zero.
- Block dependency and SAST findings only at high or critical severity with a known exploit path, and route the rest to a reviewed dashboard.
- Keep the per-push gate fast for teams that deploy often, and move heavy scans to a scheduled job against the main branch.
- Make every blocked build show the exact file, line and finding so engineers can fix it without escalating.
- Retire or tighten any non-blocking check that has produced findings for several quarters with no remediation.
What Good Looks Like
Good practice means every gate's blocking threshold matches its confidence level, every failure gives a specific and actionable message, and the gate list gets reviewed for what's actually acted on rather than growing indefinitely.
Building The Capability (5-Stage Skill Ladder)
How to Get Started
Frequently Asked Questions
Should every security check block the deploy?
No. Reserve blocking for high-confidence, high-severity findings like committed secrets or critical dependency vulnerabilities with a known exploit path. Lower-confidence findings belong on a reviewed dashboard, since blocking on everything trains engineers to route around the gate entirely.
How do we add a new blocking gate without disrupting an active team?
Run it in report-only mode for two to three weeks first, fix the backlog of findings it surfaces, then flip it to blocking once the noise is gone. Turning a new gate on as blocking from day one usually just produces a wave of bypassed or disabled checks.
What's the biggest sign a security gate isn't working?
A rising rate of overrides, exceptions, or disabled checks. That's a signal the gate's threshold doesn't match its confidence level, not a signal that engineers don't care about security.
Sources
Where we quote a benchmark, we show its source. Other figures in this guide are estimates or general guidance, so check them against your own numbers.
- Deployment frequency by DORA performance cluster (max days between deploys). DORA Accelerate State of DevOps 2024 (Google Cloud), cluster table via Octopus Deploy analysis, 2024.
Related Guides
Continuous Device Verification for a Zero-Trust API
How continuous device and identity verification actually works in a zero-trust architecture, and where to draw the line for a small engineering team.
Rolling Out Zero Trust in Production Without a Broad Outage
A checklist for rolling out stricter API authentication and authorization in production, and the pitfalls that turn a rollout into an incident.
Building a CI/CD Pipeline That Actually Catches Bugs
How to build a pipeline that blocks real regressions instead of just style errors, from test selection to what actually belongs as a merge gate.
A Worksheet for Sizing Your CI Pipeline's Real Cost
A step-by-step worksheet for pricing out what your automated test pipeline actually costs in compute and engineering wait time, and where to trim it.
How to Audit Whether Your APIs Actually Enforce Zero Trust
A step-by-step method for testing whether your APIs enforce zero trust in practice, not just on paper, and what to do with what you find.
Pen Testing, Continuous Scanning, or Bug Bounty: Picking Your Mix
Comparing penetration testing, continuous automated scanning, and bug bounty programs for zero trust APIs, and what each one actually catches.