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

Im traditionellen Modell findet ein Security-Review erst nach dem Staging-Schritt statt - spät, teuer und blockierend. DevSecOps verlagert Security-Tests an den Anfang der Pipeline: SAST, Secret-Scan und SCA bereits beim Commit, Container-Scanning beim Build, DAST in der Testphase, IAST und Pentest im Staging.

Der wirtschaftliche Grund ist eindeutig: Laut IBM/NIST-Studie kostet ein Bug, der im Code gefunden wird, den Faktor 1. Derselbe Bug im Test kostet 6x, in Produktion 30x und nach einer Kundenmeldung 100x. Jeder Security-Bug der in CI/CD gefunden wird ist damit 30x billiger zu beheben als einer der in Produktion landet.

Die DevSecOps-Pipeline

Eine vollständige DevSecOps-Pipeline umfasst vier Stufen:

Pre-Commit (lokal auf dem Entwickler-Rechner): Secret Detection (gitleaks, git-secrets), Linting mit Security-Regeln (eslint security rules) und 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) und License Compliance (FOSSA, ClearlyDefined).

CI: Build und Container: Container Image Scanning (Trivy, Grype, Snyk), SBOM-Generierung (Syft) als Stückliste aller Dependencies, Image Signing (Cosign, Notary) für Supply Chain Security und Infrastructure as Code Scanning (Checkov, tfsec, Terrascan).

CI/CD: Dynamische Tests: DAST (OWASP ZAP, Nuclei), API Security Testing (Postman/Newman Security, ZAP API) und IAST - Laufzeit-Instrumentation (Contrast Security).

Ergänzend in Produktion: WAF (ModSecurity, AWS WAF, Cloudflare), RASP, Container Runtime Security (Falco, Aqua Security) und kontinuierliches Vulnerability Management.

SAST - Statische Code-Analyse in CI/CD

Semgrep ist das empfohlene Open-Source-SAST-Tool: regelbasiert, sehr schnell und false-positive-arm. Die GitLab-CI-Integration:

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

Eigene Semgrep-Regeln lassen sich für firmenspezifische Muster schreiben, zum Beispiel zur SQL-Injection-Erkennung:

rules:
- id: sql-injection-risk
  patterns:
  - pattern: |
      $DB.query("..." + $USER_INPUT + "...")
  - pattern-not: |
      $DB.query($QUERY, [$PARAMS])
  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"

GitHub Actions mit CodeQL bietet tiefe semantische Analyse mit Datenfluss-Verständnis:

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 prüft Third-Party-Dependencies auf bekannte CVEs. Die wichtigsten Tools:

Snyk bietet tiefe Dependency-Baum-Analyse, automatische Fix-PRs, Lizenz-Scanning und Container-Scanning. OWASP Dependency-Check ist Open Source und unterstützt viele Sprachen und Ökosysteme. npm audit und pip-audit sind in den jeweiligen Package-Managern integriert.

Für Supply Chain Security generiert Syft ein SBOM (Software Bill of Materials), das Grype auf CVEs prüft:

syft myapp:latest -o spdx-json=sbom.spdx.json
grype sbom:sbom.spdx.json

# 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 ist das empfohlene DAST-Tool für CI/CD. Der Baseline Scan ist passiv und läuft in unter zwei 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
        -I
  artifacts:
    paths:
      - zap-baseline-report.html

Nuclei ermöglicht schnelles Template-basiertes Scanning gegen bekannte CVEs und Konfigurationsfehler:

nuclei -u https://staging.myapp.de \
       -t cves/ -t exposures/ -t vulnerabilities/ \
       -severity critical,high \
       -json-export nuclei-findings.json \
       -exit-code 1

Infrastructure as Code (IaC) Security

IaC-Dateien einmal falsch konfiguriert bedeutet hunderte unsichere Deployments. Checkov ist der umfassendste IaC-Scanner:

checkov -d ./terraform --framework terraform
checkov -d ./kubernetes --framework kubernetes
checkov -f Dockerfile --framework dockerfile

In CI/CD mit differenzierten Fehlergrenzen:

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

Typische IaC-Findings: S3-Bucket ohne blockierten Public Access, Security Group mit SSH-Zugang aus 0.0.0.0/0, fehlende CloudTrail-Aktivierung und IAM-Policies mit Wildcard-Actions.

Security Gates - Wann Pipeline stoppen?

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

Severity	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 bedeutet: Pipeline schlägt fehl, kein Deploy. WARN bedeutet: Finding wird geloggt, Deploy weiter möglich. INFO bedeutet: nur Berichterstattung.

False Positives und bewusste Ausnahmen müssen dokumentiert werden. Trivy-Ausnahmen werden in .trivyignore mit Begründung, Genehmigung und Ablaufdatum erfasst. Alle Ausnahmen sollten quartalsweise überprüft werden.

DevSecOps-Reifegrad und Einführungsstrategie

Phase 1 (Monat 1-2) - Sichtbarkeit schaffen: SAST im nicht-blockierenden Modus, Secret Scanning für alle Repos aktivieren, npm audit/pip-audit als Report. Ziel: Baseline-Risiko kennenlernen.

Phase 2 (Monat 3-4) - Kritisches blockieren: Critical und High SAST-Findings blockieren die Pipeline, bekannte Malware in Dependencies und gefundene Secrets stoppen die Pipeline sofort. 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 Infrastruktur-Fehlkonfigurationen erkennen.

Phase 4 (Monat 7-12) - Optimierung und Kultur: Custom Security-Regeln für firmenspezifische Patterns, Security Champions in jedem Team, Security-KPIs im Team-Dashboard, Developer Security Training. Ziel: Security als Selbstverständlichkeit.

Das Security Champions Programm sieht einen freiwilligen Entwickler pro Team vor, der an monatlichen Meetings teilnimmt, einen direkten Kanal zum Security-Team hat und Security Reviews von Merge Requests durchführt.