Advanced DevSecOps

Secure pipeline — SAST, DAST, SCA in CI/CD and quality gates

A secure pipeline is not a pipeline with more steps — it is a pipeline where each step has clear pass/fail criteria. SAST, DAST, and SCA are the three core tools that turn a standard CI/CD into an automated security barrier.

SAST — Static Application Security Testing

Analyzes source code without executing it. Detects insecure patterns such as SQL injection, XSS, and use of dangerous functions.

# GitHub Actions — Semgrep SAST
jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Semgrep
        uses: returntocorp/semgrep-action@v1
        with:
          config: "p/owasp-top-ten"
        env:
          SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_TOKEN }}

Popular tools: Semgrep, SonarQube, Checkmarx, CodeQL (native to GitHub).

SCA — Software Composition Analysis

Scans third-party dependencies for known CVEs.

  sca:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Trivy SCA
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: "fs"
          scan-ref: "."
          severity: "HIGH,CRITICAL"
          exit-code: "1"   # fails the pipeline on HIGH/CRITICAL
Example SCA output:
  lodash@4.17.15  CVE-2021-23337  CRITICAL  Prototype Pollution
  log4j@2.14.0    CVE-2021-44228  CRITICAL  RCE (Log4Shell)
  → pipeline blocked until dependencies are updated

DAST — Dynamic Application Security Testing

Tests the running application by simulating real attacks. Runs against a staging environment, never production.

  dast:
    runs-on: ubuntu-latest
    needs: [deploy-staging]
    steps:
      - name: OWASP ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.10.0
        with:
          target: "https://staging.example.com"
          rules_file_name: ".zap/rules.tsv"
          fail_action: true
What DAST finds that SAST misses:
  - Server misconfiguration (missing security headers)
  - Authentication logic bypassable at runtime
  - Exposure of undocumented endpoints
  - CORS and CSP misconfigurations

Quality gates

Gates are automatic criteria that block pipeline progression:

Example gate policy:
  SAST    → no CRITICAL or HIGH vulnerabilities
  SCA     → no CRITICAL CVEs; HIGH accepted with documented exception
  DAST    → no HIGH-risk alerts in baseline scan
  Secrets → zero secrets detected in the diff
  Coverage → test coverage >= 80%

If any gate fails → merge blocked, PR annotated with findings.
push → pre-commit hooks (local)
     → secrets scan (fast, < 30s)
     → SAST (parallel with unit tests)
     → SCA (parallel with build)
     → container image build
     → image scan (Trivy)
     → deploy to staging
     → DAST
     → manual approval (optional, for prod)
     → deploy to production

Exceptions and false positives

Analysis tools produce false positives. The exception process must be traceable:

1. Developer opens an issue documenting the false positive
2. Security team reviews and approves
3. Rule added to the suppression file (versioned in the repo)
4. Exception reviewed every 90 days

# .semgrepignore or equivalent — never suppress without justification

Summary

SAST finds problems in code. SCA exposes vulnerable dependencies. DAST validates actual application behavior. All three together, with clear gates, form an automated security mesh that does not rely on manual review to operate.