DevOps-Pipeline-Sicherheit 2026: SAST, DAST, Supply Chain und Interview-Fragen

Die Sicherheit von DevOps-Pipelines erfordert die Integration von Sicherheitsprüfungen in jeder Phase des CI/CD-Workflows, von Pre-Commit-Hooks bis zum Produktions-Monitoring. Der Datadog State of DevSecOps Report 2026 zeigt, dass 87% der Organisationen Dienste mit mindestens einer bekannten ausnutzbaren Schwachstelle betreiben, während Supply-Chain-Angriffe die Weltwirtschaft inzwischen jährlich über 80 Milliarden Dollar kosten.

SAST: Statische Analyse zur Erkennung von Schwachstellen vor dem Merge

Static Application Security Testing (SAST) analysiert Quellcode ohne dessen Ausführung. Das Tool parst die Codebasis, erstellt einen abstrakten Syntaxbaum und gleicht Muster mit bekannten Schwachstellen-Signaturen ab. Die Ausführung von SAST bei jedem Pull Request erkennt SQL-Injection, XSS und hartcodierte Anmeldedaten, bevor der Code den Hauptbranch erreicht.

Semgrep hat sich 2026 zum De-facto-Standard unter den Open-Source-SAST-Tools entwickelt. Im Gegensatz zu regex-basierten Scannern versteht Semgrep die Codestruktur und unterstützt benutzerdefinierte Regeln in YAML.

# .github/workflows/sast.yml
name: SAST Scan

on:
  pull_request:
    branches: [main, develop]

jobs:
  semgrep:
    runs-on: ubuntu-latest
    container:
      image: semgrep/semgrep:latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Semgrep
        run: semgrep scan --config=auto --sarif --output=semgrep.sarif
        
      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep.sarif

Das Flag --config=auto lädt Community-Regeln, die zu den erkannten Sprachen passen. Die SARIF-Ausgabe integriert sich mit dem GitHub Security Tab zur Nachverfolgung von Findings über die Zeit.

DAST: Laufzeittests finden, was statische Analyse übersieht

Dynamic Application Security Testing (DAST) greift eine laufende Anwendung an, um Schwachstellen zu finden, die sich nur zur Laufzeit manifestieren. Fehlerhafte Authentifizierung, Autorisierungslücken und Geschäftslogik-Bugs erfordern tatsächliche HTTP-Anfragen zur Erkennung. SAST kann nicht feststellen, dass ein Admin-Endpunkt keine ordnungsgemäße Zugriffskontrolle hat, aber DAST wird versuchen, ohne Anmeldedaten darauf zuzugreifen und die Schwachstelle melden.

OWASP ZAP bleibt das am häufigsten eingesetzte Open-Source-DAST-Tool. ZAP 3.0, Anfang 2026 veröffentlicht, fügte native Unterstützung für GraphQL- und gRPC-Scanning hinzu.

# .github/workflows/dast.yml
name: DAST Scan

on:
  deployment:
    types: [created]

jobs:
  zap-scan:
    runs-on: ubuntu-latest
    steps:
      - name: ZAP Full Scan
        uses: zaproxy/action-full-scan@v0.12.0
        with:
          target: ${{ secrets.STAGING_URL }}
          rules_file_name: '.zap/rules.tsv'
          cmd_options: '-a -j -l WARN -z "-config api.disablekey=true"'
          
      - name: Upload Report
        uses: actions/upload-artifact@v4
        with:
          name: zap-report
          path: report_html.html

DAST läuft nach dem Deployment, da ein laufendes Ziel benötigt wird. Die Staging-Umgebung dient als Testoberfläche und hält die Produktion vom Scan-Traffic isoliert.

SCA: Dependency-Scanning für bekannte Schwachstellen

Software Composition Analysis (SCA) scannt Abhängigkeiten gegen Schwachstellendatenbanken wie die National Vulnerability Database und GitHub Advisory Database. Eine einzige verwundbare transitive Abhängigkeit kann die gesamte Anwendung gefährden. Der Datadog-Report 2026 stellte fest, dass 42% der Dienste von Bibliotheken abhängen, die nicht mehr aktiv gewartet werden.

Trivy scannt Container, Dateisysteme und Git-Repositories auf Schwachstellen in einem einzigen Binary. Es generiert SBOM-Ausgaben in den Formaten CycloneDX und SPDX.

# .github/workflows/sca.yml
name: Dependency Scan

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 6 * * *'  # Täglich um 6 Uhr

jobs:
  trivy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@0.28.0
        with:
          scan-type: 'fs'
          scan-ref: '.'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
          
      - name: Upload Trivy scan results
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: 'trivy-results.sarif'

Der geplante tägliche Scan erfasst neu bekannt gewordene CVEs auch ohne Codeänderungen. Die Filterung auf CRITICAL und HIGH-Schweregrade verhindert Alert-Müdigkeit durch Findings mit geringem Risiko.

Supply-Chain-Sicherheit: SBOM und SLSA-Provenienz

Der EU Cyber Resilience Act, dessen Meldepflichten im September 2026 in Kraft treten, schreibt die Erstellung einer Software Bill of Materials (SBOM) für in der EU verkaufte Produkte vor. Eine SBOM listet jede Komponente in der Software auf, einschließlich direkter Abhängigkeiten, transitiver Abhängigkeiten und deren Versionen.

SLSA (Supply-chain Levels for Software Artifacts) ergänzt SBOM durch die Verifizierung, wie Software erstellt wurde. SBOM beantwortet die Frage "Welche Komponenten sind in dieser Software?" während SLSA die Frage beantwortet "Kann dem Build-Prozess vertraut werden?"

# .github/workflows/supply-chain.yml
name: Supply Chain Security

on:
  push:
    tags:
      - 'v*'

jobs:
  build-with-provenance:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
      attestations: write
    steps:
      - uses: actions/checkout@v4
      
      - name: Build container image
        run: docker build -t myapp:${{ github.ref_name }} .
        
      - name: Generate SBOM
        uses: anchore/sbom-action@v0.17.0
        with:
          image: myapp:${{ github.ref_name }}
          format: cyclonedx-json
          output-file: sbom.json
          
      - name: Sign with Cosign
        uses: sigstore/cosign-installer@v3.7.0
        
      - name: Sign image and attach SBOM
        run: |
          cosign sign --yes myapp:${{ github.ref_name }}
          cosign attach sbom --sbom sbom.json myapp:${{ github.ref_name }}
          cosign sign --yes --attachment sbom myapp:${{ github.ref_name }}

Sigstores Cosign signiert Artefakte mittels schlüsselloser Signierung, unterstützt durch die Fulcio-Zertifizierungsstelle. Die Signatur bindet das Artefakt an den CI-Workflow, der es erstellt hat, und ermöglicht die Verifizierung, dass das Image aus einer vertrauenswürdigen Pipeline stammt.

Secrets-Erkennung: Die erste Verteidigungslinie

Hartcodierte Secrets bleiben der häufigste Sicherheitsfund in Codebasen. AWS-Zugriffsschlüssel, Datenbankpasswörter und API-Tokens, die in die Versionskontrolle committed werden, haben Sicherheitsverletzungen in jedem Maßstab verursacht. Die Secrets-Erkennung läuft als Pre-Commit, um Anmeldedaten zu blockieren, bevor sie in das Repository gelangen.

Gitleaks erkennt Secrets mittels Regex-Mustern und Entropie-Analyse. Ein Pre-Commit-Hook verhindert, dass Secrets jemals committed werden.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks
        args: ['--verbose']

# .github/workflows/secrets.yml
name: Secrets Detection

on:
  pull_request:

jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          
      - name: Gitleaks scan
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Die Option fetch-depth: 0 klont die vollständige Historie, wodurch Gitleaks alle Commits im PR scannen kann, nicht nur den letzten.

DevSecOps-Interview-Fragen: Was Recruiter fragen

DevSecOps-Interviews bewerten sowohl Sicherheitswissen als auch praktische CI/CD-Erfahrung. Die folgenden Fragen erscheinen häufig in Interviews 2026 für Senior DevOps- und Platform-Engineering-Positionen. Weitere Pipeline-Sicherheitsfragen finden sich im CI/CD Pipeline Security Interview-Modul.

"Wie würden Sie Shift-Left-Security in einer bestehenden Pipeline implementieren?"

Shift-Left-Security verlagert Tests früher in den Entwicklungszyklus. Die praktische Implementierung umfasst das Hinzufügen von Pre-Commit-Hooks für Secrets-Erkennung, SAST-Scans bei Pull Requests und SCA-Prüfungen in der Build-Phase. Der Schlüssel ist die inkrementelle Einführung: Mit Secrets-Erkennung beginnen, da sie die niedrigste False-Positive-Rate und das höchste Signal hat, dann SCA für bekannte CVEs hinzufügen, dann SAST-Regeln abstimmen, um Rauschen zu reduzieren, bevor sie als blockierende Prüfung aktiviert werden.

"Erklären Sie den Unterschied zwischen SAST und DAST. Wann würden Sie jeweils einsetzen?"

SAST analysiert Quellcode ohne Ausführung. Es findet SQL-Injection, XSS und unsichere Kryptographie durch Musterabgleich gegen die Codestruktur. SAST läuft früh, bei jedem PR, da es nur den Code benötigt.

DAST greift eine laufende Anwendung an. Es findet Authentifizierungsumgehungen, fehlerhafte Zugriffskontrolle und Injection-Schwachstellen, die sich nur zur Laufzeit manifestieren. DAST läuft nach dem Deployment gegen eine Staging-Umgebung.

Die beiden ergänzen sich. SAST fängt Programmierfehler vor dem Merge ab; DAST verifiziert, dass sich die bereitgestellte Anwendung sicher verhält. Eine ausgereifte Pipeline führt beide aus.

"Was ist eine SBOM und warum ist sie erforderlich?"

Eine Software Bill of Materials listet jede Komponente in der Software auf, einschließlich direkter und transitiver Abhängigkeiten mit exakten Versionen. Regulatorische Anforderungen wie der EU Cyber Resilience Act schreiben die SBOM-Erstellung für Produkte, die ab September 2026 in den EU-Markt eintreten, vor.

Praktisch ermöglicht SBOM eine schnelle Reaktion auf Vorfälle. Wenn eine neue CVE veröffentlicht wird, kann das Sicherheitsteam die SBOM-Datenbank abfragen, um jeden Dienst zu identifizieren, der die verwundbare Komponente ausführt, anstatt alle Repositories manuell zu scannen.

"Wie verhindern Sie Alert-Müdigkeit bei Sicherheitstools?"

Alert-Müdigkeit tritt auf, wenn Entwickler Sicherheitsfunde ignorieren, weil das Signal-Rausch-Verhältnis zu niedrig ist. Prävention erfordert die Abstimmung jedes Tools, bevor blockierende Gates aktiviert werden. Für SAST werden Regeln deaktiviert, die in der Codebasis False Positives produzieren, und schrittweise nach Bereinigung aktiviert. Für SCA liegt der Fokus auf CRITICAL- und HIGH-Schweregrad-Findings mit bekannten Exploits. Für DAST werden Baseline-Scans konfiguriert, um False Positives von zukünftigen Läufen auszuschließen.

Die zu verfolgende Metrik ist die Zeit bis zur Behebung echter Schwachstellen. Wenn diese Zahl steigt, ignorieren Entwickler Warnungen.

Container- und Laufzeitsicherheit

Container-Image-Scanning erkennt Schwachstellen vor dem Deployment. Laufzeitsicherheit überwacht Container in der Produktion auf anomales Verhalten. Die Kombination adressiert sowohl bekannte Schwachstellen (CVEs in Basis-Images) als auch unbekannte Bedrohungen (kompromittierte Container, Cryptominer).

Trivy scannt Images als Teil der Build-Pipeline. Falco überwacht das Laufzeitverhalten mittels eBPF.

# .github/workflows/container-security.yml
name: Container Security

on:
  push:
    branches: [main]

jobs:
  scan-image:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .
        
      - name: Scan image
        uses: aquasecurity/trivy-action@0.28.0
        with:
          image-ref: myapp:${{ github.sha }}
          format: 'table'
          exit-code: '1'
          severity: 'CRITICAL'
          ignore-unfixed: true

Das Flag ignore-unfixed: true überspringt Schwachstellen ohne verfügbare Patches. Dies verhindert das Blockieren von Deployments für CVEs, die derzeit nicht behoben werden können.

Für Laufzeitsicherheit erkennen Falco-Regeln verdächtige Aktivitäten in laufenden Containern. Das Container Supply Chain Security Modul behandelt Image-Signierung und Admission Control ausführlich.

IaC-Sicherheit: Scanning von Terraform und Kubernetes-Manifesten

Infrastructure as Code führt Sicherheitsrisiken auf der Konfigurationsebene ein. Zu freizügige IAM-Richtlinien, öffentlich zugängliche S3-Buckets und unverschlüsselte Datenbanken resultieren aus unsicheren Standardeinstellungen in IaC-Templates.

Checkov scannt Terraform, CloudFormation, Kubernetes, Helm und Dockerfiles auf Fehlkonfigurationen.

# .github/workflows/iac-scan.yml
name: IaC Security Scan

on:
  pull_request:
    paths:
      - 'terraform/**'
      - 'k8s/**'
      - 'helm/**'

jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@v12
        with:
          directory: .
          framework: terraform,kubernetes,helm
          output_format: sarif
          output_file_path: checkov.sarif
          soft_fail: false
          
      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: checkov.sarif

Der Pfadfilter stellt sicher, dass IaC-Scans nur ausgeführt werden, wenn sich Infrastrukturdateien ändern, was die CI-Zeit für reine Anwendungsänderungen reduziert.

Die vollständige DevSecOps-Pipeline für 2026

Eine produktionsreife DevSecOps-Pipeline im Jahr 2026 integriert diese Tools in jeder Phase:

• Pre-commit: Gitleaks (Secrets), optionales lokales SAST
• Pull Request: Semgrep (SAST), Trivy (SCA), Checkov (IaC)
• Build: Container-Image-Scanning, SBOM-Generierung
• Pre-deploy: Image-Signierung mit Cosign, Admission Control mit Kyverno
• Post-deploy: DAST mit ZAP gegen Staging
• Runtime: Falco für Container-Monitoring, Cloud Security Posture Management

Der kostenlose Stack (Semgrep, Trivy, ZAP, Gitleaks, Checkov, Falco) deckt jede Kategorie ab. Kommerzielle Tools bieten zentrale Dashboards, Policy-Management und reduzierten Abstimmungsaufwand, aber die Sicherheitsabdeckung ist ohne Lizenzkosten erreichbar.

Organisationen, die sich auf DevSecOps-Rollen vorbereiten, sollten den Aufbau dieser Pipelines in persönlichen Projekten üben. Das Cloud Identity and Secrets Management Modul behandelt die Secrets-Management-Seite der Gleichung.