Continuous security in CI / CD

Continuous security in a pipeline is a deceptively simple idea: every commit gets tested; failing tests block merge; security becomes another quality gate. In practice, teams hit four predictable failure modes — and the gap between a pipeline that helps and a pipeline that gets bypassed is mostly about avoiding those.

#The minimum viable shape

Before optimizing, you need the skeleton. Three jobs, three triggers, two gates. Anything less leaves an obvious bypass; anything more, before you have measured what works, tends to overfit your stack.

name: security

on:
  pull_request:
  push:
    branches: [main]

jobs:
  fast-scan:
    timeout-minutes: 5
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: bugthrive/scan@v1
        with:
          mode: pr
          fail-on: high

  deep-scan:
    if: github.ref == 'refs/heads/main'
    timeout-minutes: 30
    steps:
      - uses: actions/checkout@v4
      - uses: bugthrive/scan@v1
        with:
          mode: deep
          fail-on: critical

#Failure mode 1: the slow PR scan

If the security step adds more than 5 minutes to PR feedback, engineers route around it — they ship hotfixes through emergency paths, they batch security work into 'security PRs' that hide context, they stop reading the report. The bar to enforce: PR-scan completes in under 4 minutes for the median PR.

Getting under 4 minutes is a matter of scope, not horsepower. Run SAST only against the diff. Run DAST only against routes that changed. Run dependency checks only when the manifest changed. Saving 90% of scan time costs almost no coverage when paired with a deeper nightly run.

#Failure mode 2: the noisy gate

A gate that fires false positives even 5% of the time will be force-merged within the quarter. Engineers learn to treat the security check the way they treat a flaky e2e test — they retry, and if it stays red, they merge anyway and 'fix it on main.' From that point, the gate exists in name only.

Two structural defenses. First, never block on a finding without an attached PoC and a clear remediation. Second, calibrate severity quarterly: if a 'High' rarely turns out to actually be high, the threshold is broken.

#Failure mode 3: the unknown owner

A blocked PR with no clear owner becomes a security-team problem within an hour and a dropped problem within a day. Owner mapping is the single highest-leverage piece of pipeline infrastructure — and the one teams under-invest in.

• ▸Map every directory in the repo to a CODEOWNERS-style team.
• ▸Resolve the team to an on-call rotation, not a Slack channel.
• ▸Post the finding to the on-call's private DM with full context, not just a link.

#Failure mode 4: missing retest workflow

Fixes that never get verified accumulate as silent rot. The fix landed; the original finding is closed; nobody confirmed the underlying issue is gone. Six months later, the same class of bug ships again in a new feature.

Solution: every finding closes through a verification step that re-runs the original PoC. The fix branch's PR should run a targeted re-exploit attempt and surface the result inline. If the PoC still works, the close is rejected automatically.

# Verification step on fix branches
on:
  pull_request:
    types: [labeled]

jobs:
  retest:
    if: contains(github.event.label.name, 'security-fix:')
    steps:
      - uses: bugthrive/retest@v1
        with:
          finding-id: ${{ github.event.label.name | split:':' | last }}
          fail-on: still-exploitable

#What success looks like

Hit those four numbers and the rest takes care of itself. The pipeline stays trusted, engineers stay velocity-positive, security stays out of the room when it does not need to be there. Continuous security stops being a roadmap goal and becomes a property of the build system.

“We stopped having a 'security review' meeting six months after the gate went in. The pipeline does the review, the owner gets the context, the fix ships in the same PR.”

— Director of Engineering, developer infra