Skip to Content

DevSecOps on Autopilot

Building a good Security Gate in CI/CD
May 9, 2025 by
DevSecOps on Autopilot
Cloudnovi, Ajdin Lokvancic

How to Add a Security Gate to Your CI/CD


Why You Need a Gate

Bugs cost less to fix before code goes live. A gate stops code that breaks basic security rules. The team sees the error right away and fixes it while the change is fresh in their minds.


What a “Security Gate” Means

A security gate is an automatic check in the pipeline. If the check finds a high-risk issue, the pipeline fails. No manual step, no long meeting—just a clear red light.


Plan the Spot for the Gate

Put the gate after unit tests pass but before the deploy step. That way you catch issues early but avoid noise from code that is still broken for other reasons.

stages:
  - test
  - security
  - deploy

Pick the Checks

Check Type

Tool Examples

What It Finds

Static code scan

Semgrep, Bandit

SQL injection, bad crypto

Dependency scan

OSV-Scanner, Snyk CLI

Known CVE issues

Secrets scan

TruffleHog, GitLeaks

Hard-coded keys

Container image scan

Grype, Trivy

Vulnerable packages in images

Infra-as-Code scan

Checkov, tfsec

Open S3 buckets, weak IAM

Start with two or three tools. Add more only when the team can handle the extra output.


Wire It Into the Pipeline

Example with GitHub Actions:

jobs:
  security_gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Scan code
        run: semgrep ci --fail-on=error

      - name: Scan deps
        run: osv-scanner --recursive .

      - name: Scan secrets
        run: gitleaks detect --exit-code 1

The build stops if any step exits with code 1.


Set Clear Pass/Fail Rules

  • High severity → fail.
  • Medium → warn, let it pass (at first).
  • Low → ignore until the team is ready.

Put those thresholds in a config file that lives with the repo, so changes need a pull request.


Handle the Results

  • Post a short comment on the pull request.
  • Link to full logs for anyone who wants details.
  • Tag the file owner so it lands with the right person.


Keep the Gate Healthy

  • Auto-update scan rules weekly.
  • Track numbers: how many scans run, how many fails, how long to fix.
  • Cut false positives fast; trust in the gate drops if noise stays high.


Grow Carefully

Once the team trusts the gate, raise the bar:

  • Turn medium issues into fails.
  • Add container or IaC scans.
  • Require a passing gate on every branch, not just main.


When a Team Yells “It Blocks Us”

  • Check severity: is it truly high?
  • Allow a short-term override with a signed commit tag like SEC-IGNORE-123 that expires in 30 days.
  • Log each override so you can audit later.


Key Takeaways

  • A security gate is just another test.
  • Fail fast, give clear feedback, measure impact.
  • Start small, earn trust, then tighten the rules.


Done right, the gate fades into the background. Code that passes is safer by default, and nobody has to remember to run one-off tools.