TracksSpecializations and Deep DivesCybersecurity Deep DiveSecurity in CI/CD Pipelines(5 of 8)

Security in CI/CD Pipelines

Manual security reviews don't scale. When you're deploying multiple times per day, you need automated security checks integrated into your CI/CD pipeline. This "shift left" approach catches issues early when they're cheapest to fix.

Building a Security Pipeline

A comprehensive security pipeline includes multiple scanning stages:

name: Security Checks

on: [push, pull_request]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: SAST Scan
        run: |
          pip install bandit
          bandit -r src/ -f json -o bandit-report.json
      
      - name: Dependency Audit
        run: |
          pip install pip-audit
          pip-audit
      
      - name: Secret Scanning
        uses: trufflesecurity/trufflehog@main
        with:
          path: ./
      
      - name: Container Scan
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker scan myapp:${{ github.sha }}

What to Scan

Static analysis (SAST) examines your source code for security anti-patterns. Tools like Bandit for Python or ESLint security plugins for JavaScript catch common mistakes automatically.

Software composition analysis (SCA) checks your dependencies against vulnerability databases. This catches known issues in third-party packages.

Secret scanning detects accidentally committed credentials, API keys, and tokens. Tools like TruffleHog scan your entire git history, not just current files.

Container scanning analyzes your container images for vulnerable packages and misconfigurations.

Infrastructure as Code scanning checks Terraform, CloudFormation, or Kubernetes manifests for security misconfigurations before deployment.

Handling Findings

Not every finding should block deployment. Configure thresholds based on severity:

Critical vulnerabilities should always block. These are actively exploited issues that put users at immediate risk.

High severity findings typically block, but allow exceptions with explicit approval. Document why you're accepting the risk.

Medium and low severity issues get tracked in your backlog. Fix them, but don't halt deployments.

- name: Check SAST Results
  run: |
    HIGH_COUNT=$(jq '[.results[] | select(.issue_severity=="HIGH")] | length' bandit-report.json)
    if [ "$HIGH_COUNT" -gt 0 ]; then
      echo "Found $HIGH_COUNT high severity issues"
      exit 1
    fi

Balancing Security and Velocity

Security gates shouldn't become bottlenecks. Keep scans fast by running them in parallel. Cache dependencies to avoid re-downloading. Use incremental scanning when possible — only analyze changed files.

When scans do block deployments, provide clear remediation guidance. Developers shouldn't have to guess how to fix issues.

See More

Further Reading

Last updated December 26, 2025

You need to be signed in to leave a comment and join the discussion