How do you integrate security testing into a CI/CD pipeline?

The goal is to catch the cheap, common security problems automatically, as close to the change as possible, without turning the pipeline into a wall of noise that teams learn to ignore. I think of it as layers, each placed where it is fast enough to run.

The layers

Check	What it finds	Where it runs
Secrets scanning	Committed keys, tokens, passwords	Pre-commit hook and every PR
SAST (static analysis)	Injection patterns, unsafe APIs, weak crypto in source	Every PR
SCA (dependency scanning)	Libraries with known CVEs, licence issues	Every build, plus scheduled scans
Container and IaC scanning	Vulnerable base image packages, misconfigured Terraform or Kubernetes manifests	On image build and infra PRs
DAST	Runtime issues: missing headers, reflected XSS, misconfigurations	Against a deployed test environment, often nightly
Authorization tests	IDOR, privilege escalation, tenant isolation	With the API regression suite

Typical tools include Gitleaks for secrets, Semgrep or CodeQL for SAST, Dependabot, Renovate or OWASP Dependency-Check for SCA, Trivy for images and IaC, and OWASP ZAP for DAST. The specific tools matter less than the placement.

Example: GitHub Actions jobs

name: security
on:
  pull_request:
  schedule:
    - cron: "0 2 * * *"

jobs:
  secrets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  image-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t app:${{ github.sha }} .
      - name: Scan image, fail on high and critical
        run: |
          docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
            aquasec/trivy:latest image --severity HIGH,CRITICAL --exit-code 1 \
            app:${{ github.sha }}

In practice I pin tool image versions rather than using latest, so a scanner upgrade does not change results without anyone noticing.

Gating policy is the hard part

Turning every tool on with “fail on any finding” fails within a week. What works:

• Gate on new, high-severity findings only. Establish a baseline of existing issues, track them as backlog, and block the PR only when it introduces something new and serious.
• Fast triage path. A documented way to mark false positives or accepted risks, with an owner and expiry date, reviewed by security.
• SLAs by severity for fixing existing findings, reported on a dashboard rather than enforced by breaking every build.
• Keep PR checks fast. Full DAST scans and deep SAST rules run nightly or on the release candidate; PRs get the quick subset.

What tools will not find

Scanners do not understand your business rules. They will not notice that a customer can read another tenant’s invoices, or that a coupon can be applied twice. That is why I keep automated authorization matrices in the API suite, include abuse cases in test design, and still rely on periodic penetration tests and threat modelling for new features.

What interviewers look for

• Correct definitions of SAST, DAST and SCA, and why each runs where it does.
• A realistic gating strategy that keeps signal high and the pipeline trusted.
• Awareness that business-logic and access-control flaws need targeted tests and humans.
• Ownership: who triages findings and how false positives are handled.

Common mistakes

• Running DAST against production without agreement.
• Blocking every build on hundreds of legacy findings, so teams disable the job.
• Treating a clean scan as proof of security.