DevSecOps Security Gates: SAST, DAST und SCA in CI/CD-Pipelines

"Shift Left Security" bedeutet: Sicherheitsprüfungen so früh wie möglich in den Entwicklungsprozess integrieren. CI/CD-Security-Gates sind der Mechanismus dafür - automatisierte Prüfungen die bei kritischen Befunden den Build stoppen. Dieser Guide zeigt die praktische Umsetzung mit konkreten Pipeline-Konfigurationen.

Security Gate Konzept

Ohne Security Gates landet eine Schwachstelle im Code erst Wochen später beim Pentest - wenn sie dann noch gefunden wird. Der Fix in Produktion kostet 10- bis 100-mal mehr als eine Korrektur im Pull-Request. Mit Security Gates wird die Schwachstelle direkt beim Commit abgefangen.

Das Pipeline-Modell unterscheidet zwei Gate-Typen:

Hard Gates (Blocker) stoppen den Build sofort. Sie greifen bei kritischen Schwachstellen (CVSS ≥ 9,0), bei Secrets im Code und bei Lizenz-Violations (z. B. GPL-Bibliotheken in proprietärem Code).

Soft Gates (Warnings) blockieren nicht, aber informieren. Hohe Schwachstellen (CVSS 7,0-8,9) erzeugen eine Team-Notification, mittlere Befunde einen PR-Kommentar, informational findings landen nur im Report.

Threshold-Management variiert je nach Repo-Alter: Neue Repositories erhalten von Anfang an strenge Schwellenwerte. Bei Legacy-Repos empfiehlt sich Baselining - der aktuelle Zustand wird als Baseline gesetzt, keine neuen Schwachstellen werden toleriert. Mit Ratcheting werden die Schwellenwerte dann schrittweise verschärft.

SAST - Statische Code-Analyse

SAST-Tools analysieren den Quellcode ohne Ausführung und finden Probleme wie SQL-Injection, unsichere Deserialisierung und OWASP-Top-10-Schwachstellen direkt im PR.

Semgrep ist die erste Wahl für schnelle, konfigurierbare SAST-Scans. Die GitHub-Actions-Integration funktioniert out-of-the-box mit vorgefertigten Rule-Sets:

# .github/workflows/sast.yml
name: SAST with Semgrep
on: [push, pull_request]
jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: semgrep/semgrep-action@v1
        with:
          config: >
            p/security-audit
            p/owasp-top-ten
            p/nodejs
            p/java
          auditOn: push

Eigene Regeln ergänzen die Rule-Sets für projektspezifische Muster. Eine Regel für SQL-Injection via String-Concatenation in JavaScript:

# rules/sql-injection.yaml
rules:
  - id: raw-sql-concatenation
    languages: [javascript]
    message: "Possible SQL injection via string concatenation"
    severity: ERROR
    pattern: |
      const query = "SELECT * FROM " + $USER_INPUT
    fix: "Use parameterized queries: db.query('SELECT * FROM ?', [input])"

SonarQube eignet sich für umfassendes Enterprise-SAST inklusive Code-Coverage-Tracking. Das Quality Gate blockiert den Build, wenn neue kritische Issues oder Blocker gefunden werden. Die Konfiguration erfolgt über sonar-project.properties mit sonar.qualitygate.wait=true - die Pipeline wartet auf das Gate-Ergebnis, bevor sie weiterläuft.

Bandit ist das Standard-Tool für Python-Projekte. Mit -ll werden nur Medium- und High-Findings ausgegeben. Der Exit-Code ungleich 0 bei Findings blockiert die Pipeline direkt.

SCA - Software Composition Analysis

SCA-Tools prüfen Drittbibliotheken auf bekannte CVEs. Die Dependency-Supply-Chain ist heute einer der häufigsten Angriffsvektoren.

OWASP Dependency-Check ist die kostenlose Referenzlösung. Der harte Gate-Schwellenwert für failBuildOnCVSS: 9 stoppt den Build bei kritischen CVEs:

# .github/workflows/sca.yml
- name: OWASP Dependency Check
  uses: dependency-check/Dependency-Check_Action@main
  with:
    project: 'myapp'
    path: '.'
    format: 'HTML,JSON,SARIF'
    failBuildOnCVSS: 9
    additionalArguments: >
      --enableRetired
      --enableExperimental
      --nodeAuditSkipDevDependencies

Snyk liefert präzisere Ergebnisse mit niedrigerer False-Positive-Rate, ist aber kommerziell. Neben dem einmaligen Scan in der Pipeline (snyk test) bietet snyk monitor kontinuierliches Monitoring im Snyk-Dashboard - neue CVEs für bereits eingecheckte Dependencies werden automatisch gemeldet.

npm audit ist für Node.js-Projekte der einfachste Einstieg und sollte in jedem Build laufen: npm audit --audit-level=high --production. Mit --production werden devDependencies ignoriert, Exit-Code 1 bei High/Critical blockiert die Pipeline.

Renovate und Dependabot automatisieren Dependency-Updates und erstellen PRs mit neuen Versionen. In Kombination mit SCA/SAST wird jeder Update-PR automatisch geprüft, bevor er gemergt werden kann.

Secret Detection

Versehentlich eingecheckte API-Keys, Passwörter und Zertifikate sind eine der häufigsten Ursachen für Cloud-Breaches. Secret-Detection muss als Hard Gate laufen - kein Commit mit verifiziertem Secret darf durchkommen.

detect-secrets (Yelp) eignet sich als Pre-Commit-Hook. Eine Baseline mit bekannten, akzeptierten Pseudo-Secrets verhindert false positives bei Test-Fixtures:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.4.0
    hooks:
      - id: detect-secrets
        args: ['--baseline', '.secrets.baseline']
        exclude: .secrets.baseline

TruffleHog v3 analysiert nur Änderungen seit dem Basis-Branch und prüft gefundene Credentials aktiv auf Gültigkeit (--only-verified). Das reduziert den Noise erheblich.

gitleaks lässt sich mit eigenen Regex-Regeln für projektspezifische Secret-Formate erweitern und ist besonders gut in GitLab-CI-Pipelines integrierbar. Als Hard Gate (allow_failure: false) blockiert es den Build bei jedem Fund:

# .gitlab-ci.yml
gitleaks:
  image: zricethezav/gitleaks:latest
  script:
    - gitleaks detect --source . --config .gitleaks.toml
  allow_failure: false

Für alle Entwickler lokal: pip install pre-commit && pre-commit install im Repo-Root aktiviert den Hook für jeden Commit.

Container-Security-Scanning

Ein sauberes Image-Scan-Ergebnis im CI/CD-Prozess ist keine Garantie für einen sicheren Container im Betrieb. Aber es verhindert, dass bekannte CVEs in Produktion landen.

Trivy ist das vielseitigste kostenlose Scanner-Tool: Es prüft OS-Pakete (Alpine, Debian, Ubuntu), Anwendungsabhängigkeiten (pip, npm, go.sum), Dockerfile-Misconfigurations und Kubernetes-YAML auf fehlende Security Contexts:

# .github/workflows/container-scan.yml
- name: Build Docker Image
  run: docker build -t myapp:${{ github.sha }} .

- name: Trivy Container Scan
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: myapp:${{ github.sha }}
    format: 'sarif'
    output: 'trivy-results.sarif'
    severity: 'CRITICAL,HIGH'
    exit-code: '1'
    ignore-unfixed: true

Dockerfile-Härtung - die häufigsten von Trivy erkannten Misconfigurations:

# Schlecht:
FROM ubuntu:latest        # Mutable Tag, kein Hash
USER root                 # Läuft als root
COPY . /app               # Kein --chown

# Gut:
FROM ubuntu:22.04@sha256:abc123
RUN groupadd -g 1001 appuser && useradd -u 1001 -g appuser appuser
COPY --chown=appuser:appuser . /app
USER appuser
HEALTHCHECK --interval=30s CMD curl -f http://localhost/health || exit 1

Grype (Anchore) ist eine Alternative zu Trivy mit ähnlichem Funktionsumfang und nativer GitLab-Container-Scanning-Integration via artifacts.reports.container_scanning.

DAST - Dynamische Anwendungsanalyse

DAST testet die laufende Anwendung auf Schwachstellen - als schwarzer Kasten, so wie es ein Angreifer tun würde. In der Pipeline läuft DAST gegen das Staging-System, nachdem der Deploy erfolgreich war.

OWASP ZAP ist die Standardlösung für Pipeline-DAST. Der Baseline Scan eignet sich für schnelle Pipelines, der Full Scan für umfassendere Prüfungen. Ein .zap/rules.tsv steuert False-Positive-Management für bekannte Findings:

# .github/workflows/dast.yml
dast:
  name: DAST with OWASP ZAP
  runs-on: ubuntu-latest
  needs: deploy-staging

  steps:
    - name: Start Application
      run: |
        docker run -d -p 8080:8080 myapp:staging
        sleep 10

    - name: OWASP ZAP Baseline Scan
      uses: zaproxy/action-baseline@v0.10.0
      with:
        target: 'http://localhost:8080'
        rules_file_name: '.zap/rules.tsv'
        cmd_options: '-a'  # Ajax Spider für SPAs

Nuclei eignet sich ergänzend für template-basierte Scans auf spezifische CVEs und Exposure-Patterns. Die Templates werden aktiv gepflegt und decken neue Schwachstellen schnell ab.

GitLab DAST (Enterprise) integriert sich direkt in den GitLab-CI-Workflow via include: template: DAST.gitlab-ci.yml und bietet ein natives Dashboard für DAST-Findings.

Vollständige Pipeline (GitHub Actions)

Die folgende Pipeline kombiniert alle Stufen in einer einzigen GitHub-Actions-Workflow-Datei. Die Stages laufen teilweise parallel, um die Gesamtlaufzeit zu minimieren:

# .github/workflows/devsecops.yml
name: DevSecOps Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  # Stage 1: Sofort-Checks (< 2 Min)
  secret-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: trufflesecurity/trufflehog@main
        with:
          path: ./
          base: ${{ github.event.repository.default_branch }}

  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: semgrep/semgrep-action@v1
        with:
          config: p/security-audit p/owasp-top-ten

  # Stage 2: Dependency-Checks (2-5 Min)
  sca:
    runs-on: ubuntu-latest
    needs: [secret-scan]
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm audit --audit-level=high --production

  # Stage 3: Build + Container-Scan (5-10 Min)
  container-scan:
    runs-on: ubuntu-latest
    needs: [sast, sca]
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t myapp:${{ github.sha }} .
      - uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:${{ github.sha }}
          severity: CRITICAL,HIGH
          exit-code: 1

  # Stage 4: Deploy Staging + DAST (15-30 Min, nur main)
  deploy-staging:
    if: github.ref == 'refs/heads/main'
    needs: [container-scan]
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploy to staging..."

  dast:
    if: github.ref == 'refs/heads/main'
    needs: [deploy-staging]
    runs-on: ubuntu-latest
    steps:
      - uses: zaproxy/action-baseline@v0.10.0
        with:
          target: 'https://staging.example.com'

Metriken und Reporting

Die entscheidenden KPIs für Security Gates:

Metrik	Bedeutung	Richtwert
Mean Time to Remediate (MTTR)	Wie schnell werden Schwachstellen gefixt?	< 7 Tage für Critical
Vulnerability Debt	Offene Findings, gewichtet nach Alter	Trend sinkend
Pipeline-Failure-Rate	Wie oft stoppt ein Gate den Build?	5-15 % ist normal
False Positive Rate	Wie viele Findings sind falsch?	> 30 % → Tool-Konfiguration prüfen

Alle Tools die SARIF-Output unterstützen (Semgrep, Trivy, SonarQube) können Findings direkt in den GitHub Security Tab hochladen:

- uses: github/codeql-action/upload-sarif@v2
  if: always()  # Auch bei Pipeline-Fail hochladen!
  with:
    sarif_file: trivy-results.sarif
    category: container-scan

Das if: always() ist wichtig: Nur wenn SARIF-Uploads auch bei fehlgeschlagener Pipeline ausgeführt werden, sind die Findings im Security Tab sichtbar - auch dann, wenn der Build durch das Hard Gate gestoppt wurde.