DevSecOps: Sicherheit in CI/CD-Pipelines integrieren

DevSecOps ist keine Technologie - es ist eine Kulturveränderung. Sicherheit gehört nicht ans Ende des Release-Prozesses (“Security Gate”), sondern in jeden einzelnen Schritt der Entwicklung. Jeder Entwickler ist verantwortlich für Security; das Security-Team befähigt statt zu blockieren.

Das DevSecOps-Prinzip: Shift Left

Traditionell (DevOps ohne Security):
  Code → Build → Test → Staging → Security-Review → Release
                                        ↑
                                  Security findet Probleme hier
                                  → teuer, spät, blockierend

DevSecOps (Shift Left):
  Commit → [SAST + Secret-Scan + SCA] → Build → [Container-Scan]
        → Test → [DAST] → Staging → [IAST + Pentest] → Release
  ↑                                                         ↑
  Security hier                                       auch hier!
  → günstig, früh, automatisiert

Kosten-Faktor für Bug-Behebung (IBM NIST-Studie):
  Gefunden im Code:          1x
  Gefunden im Test:          6x
  Gefunden in Produktion:    30x
  Gefunden durch Kundenmeldung: 100x

→ Jeder Security-Bug der in CI/CD gefunden wird ist 30x billiger!

Die DevSecOps-Pipeline - Übersicht

Stufen einer vollständigen DevSecOps-Pipeline:

┌────────────────────────────────────────────────────────────────┐
│ PRE-COMMIT (Lokal auf Entwickler-Rechner)                      │
│ • Secret Detection (gitleaks, git-secrets)                     │
│ • Linting (eslint security rules)                              │
│ • Dependency Check (npm audit, safety)                         │
└────────────────────────────────────────────────────────────────┘
          ↓
┌────────────────────────────────────────────────────────────────┐
│ CI: SOURCE CODE ANALYSE                                        │
│ • SAST (Semgrep, CodeQL, Bandit, SonarQube)                   │
│ • SCA - Software Composition Analysis (Snyk, OWASP Dependency-Check) │
│ • Secret Scanning (TruffleHog, GitLab Secret Detection)       │
│ • License Compliance (FOSSA, ClearlyDefined)                  │
└────────────────────────────────────────────────────────────────┘
          ↓
┌────────────────────────────────────────────────────────────────┐
│ CI: BUILD & CONTAINER                                          │
│ • Container Image Scanning (Trivy, Grype, Snyk)               │
│ • SBOM Generation (Syft) - Stückliste aller Dependencies       │
│ • Image Signing (Cosign, Notary) - Supply Chain Security      │
│ • Infrastructure as Code Scanning (Checkov, tfsec, Terrascan) │
└────────────────────────────────────────────────────────────────┘
          ↓
┌────────────────────────────────────────────────────────────────┐
│ CI/CD: DYNAMISCHE TESTS                                        │
│ • DAST (OWASP ZAP, Nuclei)                                    │
│ • API Security Testing (Postman/Newman Security, ZAP API)     │
│ • IAST - Laufzeit-Instrumentation (Contrast Security)         │
└────────────────────────────────────────────────────────────────┘
          ↓
┌────────────────────────────────────────────────────────────────┐
│ PRODUKTION: LAUFZEIT-SICHERHEIT                                │
│ • WAF (ModSecurity, AWS WAF, Cloudflare)                      │
│ • RASP - Runtime Application Self-Protection                  │
│ • Container Runtime Security (Falco, Aqua Security)           │
│ • Vulnerability Management (kontinuierliches CVE-Monitoring)  │
└────────────────────────────────────────────────────────────────┘

SAST - Statische Code-Analyse in CI/CD

SAST-Tools und ihre Stärken:

Semgrep (Open Source, empfohlen):
  → Regelbasiert, sehr schnell, false-positive-arm
  → Community-Regeln für 20+ Sprachen
  → Custom Rules möglich (spezifische Business-Logik)

  GitLab CI:
  sast:
    stage: security
    image: returntocorp/semgrep:latest
    script:
      - semgrep --config=auto
                --config=p/owasp-top-ten
                --config=p/javascript
                --json
                --output=semgrep-findings.json
                ./src
    artifacts:
      reports:
        sast: semgrep-findings.json  # GitLab SAST-Report-Integration!

---

Semgrep Custom Rule Beispiel (SQL-Injection):
  rules:
  - id: sql-injection-risk
    patterns:
    - pattern: |
        $DB.query("..." + $USER_INPUT + "...")
    - pattern-not: |
        $DB.query($QUERY, [$PARAMS])   # Prepared Statements OK
    message: |
      Mögliche SQL-Injection: User-Input wird direkt in Query eingebaut.
      Verwende Prepared Statements!
    severity: ERROR
    languages: [javascript, typescript]
    metadata:
      cwe: "CWE-89"
      owasp: "A03:2021"

---

SonarQube (mit Security-Plugin):
  # sonar-scanner in CI/CD:
  sonar:
    stage: security
    image: sonarsource/sonar-scanner-cli:latest
    variables:
      SONAR_HOST_URL: "https://sonar.intern.firma.de"
      SONAR_TOKEN: "$SONAR_TOKEN"    # Als CI/CD Secret!
    script:
      - sonar-scanner
        -Dsonar.projectKey=myapp
        -Dsonar.sources=./src
        -Dsonar.security.sources=src
    only:
      - main
      - merge_requests

---

GitHub Actions mit CodeQL:
  name: CodeQL Security Analysis
  on: [push, pull_request]

  jobs:
    analyze:
      runs-on: ubuntu-latest
      permissions:
        security-events: write
      steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: javascript, python
          queries: security-and-quality
      - uses: github/codeql-action/autobuild@v3
      - uses: github/codeql-action/analyze@v3

SCA - Abhängigkeiten auf Schwachstellen prüfen

Software Composition Analysis (SCA) prüft Third-Party-Dependencies:

Snyk (kommerziell, sehr leistungsfähig):
  snyk test                         # Node.js Dependencies
  snyk test --file=requirements.txt # Python
  snyk test --docker myapp:latest   # Container-Image
  snyk monitor                      # Kontinuierliches Monitoring

  # GitLab CI:
  dependency_scanning:
    stage: security
    image: snyk/snyk:node
    script:
      - snyk test --severity-threshold=high
    allow_failure: false

---

OWASP Dependency-Check (Open Source):
  # Docker:
  docker run --rm \
    -v $(pwd):/src \
    owasp/dependency-check:latest \
    --project "MyApp" \
    --scan /src \
    --format HTML \
    --out /src/dependency-check-report

---

npm audit (built-in):
  npm audit --audit-level=high
  npm audit fix                # Automatische Fixes
  npm audit fix --force        # Breaking Changes akzeptieren

  # In package.json scripts:
  "scripts": {
    "audit": "npm audit --audit-level=moderate"
  }

---

pip-audit (Python):
  pip-audit -r requirements.txt
  pip-audit --fix               # Sichere Versionen installieren

---

Supply Chain Security mit SBOM:
  # Syft - SBOM (Software Bill of Materials) generieren:
  syft myapp:latest -o spdx-json=sbom.spdx.json

  # Grype - SBOM auf CVEs prüfen:
  grype sbom:sbom.spdx.json

  # Cosign - Container-Image signieren:
  cosign sign --key cosign.key myregistry.io/myapp:v1.2.3
  cosign verify --key cosign.pub myregistry.io/myapp:v1.2.3

DAST - Dynamische Tests in Staging

OWASP ZAP in CI/CD (empfohlen für DAST):

  Baseline Scan (passiv, schnell, < 2 Minuten):
  dast_baseline:
    stage: dast
    image: owasp/zap2docker-stable:latest
    script:
      - mkdir -p /zap/wrk/
      - zap-baseline.py
          -t https://staging.myapp.de
          -g gen.conf
          -r zap-baseline-report.html
          -J zap-baseline-report.json
          -x zap-baseline-report.xml
          -I                              # Fail on alerts
    artifacts:
      paths:
        - zap-baseline-report.html

  Full Scan (aktiv, langsamer, findet mehr):
  dast_full:
    stage: dast
    script:
      - zap-full-scan.py
          -t https://staging.myapp.de
          -r zap-full-report.html
          -I
    only:
      - main

---

Authentifizierter ZAP-Scan:
  dast_authenticated:
    stage: dast
    image: owasp/zap2docker-stable:latest
    variables:
      TARGET_URL: "https://staging.myapp.de"
      LOGIN_URL: "https://staging.myapp.de/login"
      USERNAME: "${TEST_USERNAME}"    # CI/CD Secret
      PASSWORD: "${TEST_PASSWORD}"    # CI/CD Secret
    script:
      - zap.sh -daemon -host 0.0.0.0 -port 8080
          -config api.disablekey=true &
      - sleep 5  # ZAP starten lassen
      # Formular-Auth konfigurieren via ZAP-API
      - python3 scripts/configure_zap_auth.py
      - zap-cli active-scan --scanners sqli,xss $TARGET_URL
      - zap-cli report -o zap-report.html -f html

---

Nuclei (schnelles Template-basiertes Scanning):
  nuclei_scan:
    stage: dast
    image: projectdiscovery/nuclei:latest
    script:
      - nuclei -u https://staging.myapp.de
               -t cves/
               -t exposures/
               -t vulnerabilities/
               -severity critical,high
               -json-export nuclei-findings.json
               -exit-code 1     # Fail bei Findings

Infrastructure as Code (IaC) Security

IaC-Dateien einmal falsch konfiguriert → hunderte Deployments unsicher!

Checkov (umfassendstes IaC-Scanner):
  # Terraform:
  checkov -d ./terraform --framework terraform

  # Kubernetes YAML:
  checkov -d ./kubernetes --framework kubernetes

  # Docker:
  checkov -f Dockerfile --framework dockerfile

  # In CI/CD:
  iac_security:
    stage: security
    image: bridgecrew/checkov:latest
    script:
      - checkov -d . --soft-fail-on MEDIUM
                     --hard-fail-on HIGH,CRITICAL
    artifacts:
      reports:
        junit: checkov-results.xml

---

tfsec (Terraform-fokussiert):
  tfsec ./terraform --format checkstyle > tfsec-report.xml

Bekannte IaC-Findings:
  □ S3-Bucket: Public Access nicht blockiert (MEDIUM-CRITICAL)
  □ Security Group: 0.0.0.0/0 auf Port 22 (SSH) erlaubt (HIGH)
  □ RDS: Multi-AZ nicht aktiviert (MEDIUM)
  □ CloudTrail: nicht aktiviert (HIGH)
  □ KMS-Key: Rotation nicht aktiviert (MEDIUM)
  □ IAM-Policy: Wildcard (*) Actions (HIGH)

Security Gates - Wann Pipeline stoppen?

Severity-Matrix für CI/CD-Entscheidungen:

                  SAST   SCA    Container  DAST   IaC
  Critical:       STOP   STOP   STOP       STOP   STOP
  High:           STOP   STOP   STOP       STOP   STOP
  Medium:         WARN   WARN   WARN       WARN   WARN
  Low:            INFO   INFO   INFO       INFO   INFO

STOP = Pipeline schlägt fehl, kein Deploy
WARN = Finding wird geloggt, Deploy weiter möglich
INFO = Nur Berichterstattung

Ausnahmen-Management:
  → False Positives müssen dokumentiert werden
  → .semgrepignore / .trivyignore für bewusste Ausnahmen
  → Audit-Trail: wer hat Ausnahme genehmigt, warum, Ablaufdatum?
  → Review aller Ausnahmen quartalsweise

Beispiel: .trivyignore:
  # CVE-2023-XXXXX ist in unserem Deployment nicht exploitierbar
  # weil: [Begründung]
  # Ausnahme genehmigt von: Max Muster, 2026-01-15
  # Ablauf: 2026-04-15 (dann neu evaluieren!)
  CVE-2023-XXXXX

---

Security Dashboard für Teams:
  → SAST-Findings: Trend über Zeit (nimmt zu oder ab?)
  → Mean Time to Remediate (MTTR): wie schnell werden Bugs gefixt?
  → Security Debt: Summe offener Findings (Risk Backlog)
  → Security Test Coverage: wie viel Code ist durch Security-Tests gedeckt?
  → Compliance: OWASP-Kategorien die abgedeckt sind

DevSecOps-Reifegrad und Einführungsstrategie

Phasen der DevSecOps-Einführung:

Phase 1 (Monat 1-2): Sichtbarkeit schaffen
  □ SAST im nicht-blockierenden Modus (nur Reports)
  □ Secret Scanning aktivieren (alle Repos!)
  □ npm audit / pip-audit als Report
  → Ziel: Baseline-Risiko kennenlernen, Entwickler informieren

Phase 2 (Monat 3-4): Kritisches blockieren
  □ Critical + High SAST-Findings blockieren Pipeline
  □ Known-Malware in Dependencies → STOP
  □ Secrets detected → STOP (immer!)
  □ Container: Critical CVEs → STOP
  → Ziel: Schlimmste Findings verhindern

Phase 3 (Monat 5-6): DAST und IaC
  □ ZAP Baseline in Staging-Pipeline
  □ IaC-Scanning für Terraform/CloudFormation
  □ SBOM-Generierung für alle Images
  → Ziel: Laufzeit-Schwachstellen und Infra-Misconfigurationen

Phase 4 (Monat 7-12): Optimierung und Kultur
  □ Custom Security-Regeln (Firmen-spezifische Patterns)
  □ Security Champions in jedem Team
  □ Security-KPIs im Team-Dashboard
  □ Developer Security Training
  → Ziel: Security als Selbstverständlichkeit

Security Champions Programm:
  → Ein freiwilliger Entwickler pro Team = Security Champion
  → Monatliche Security-Champion-Meetings
  → Direkter Kanal zum Security-Team
  → Security Reviews von MRs durchführen
  → Security-Awareness im Team erhöhen