DevOps Pipeline-Sicherheit 2026: DevSecOps Best Practices und Interviewfragen

Die Sicherheit von DevOps-Pipelines ist zu einem entscheidenden Differenzierungsmerkmal für Unternehmen geworden, die Software im großen Maßstab ausliefern. Die OWASP Top 10 CI/CD Security Risks identifiziert die gefährlichsten Schwachstellen in modernen Pipelines, von unzureichender Flusskontrolle bis hin zu kompromittierten Build-Abhängigkeiten. Dieser Leitfaden behandelt die wesentlichen DevSecOps-Praktiken, die Interviewer von Kandidaten im Jahr 2026 erwarten.

Verständnis der CI/CD-Angriffsfläche

Moderne CI/CD-Pipelines präsentieren eine komplexe Angriffsfläche, die Quellcode-Repositories, Build-Runner, Artefakt-Registries und Deployment-Ziele umfasst. Die tj-actions/changed-files-Kompromittierung im März 2025 hat Secrets aus über 23.000 Repositories geleakt, indem bösartiger Code in eine weit verbreitete GitHub Action injiziert wurde. Der TanStack-Angriff Anfang 2026 veröffentlichte über 170 vergiftete npm-Pakete mit gültiger SLSA Build Level 3 Provenance, was demonstriert, dass selbst kryptographische Attestierungen umgangen werden können, wenn Angreifer den Build-Prozess kontrollieren.

Diese Vorfälle verdeutlichen drei kritische Kontrollpunkte:

• Quellintegrität: Branch-Protection-Regeln, signierte Commits und erforderliche Code-Reviews verhindern, dass unautorisierte Änderungen die Build-Pipeline erreichen
• Build-Isolation: Ephemere Runner, minimale Berechtigungen und Artefakt-Verifizierung begrenzen den Explosionsradius kompromittierter Abhängigkeiten
• Secrets-Hygiene: Kurzlebige Credentials, OIDC-Federation und Secrets-Scanning eliminieren die statischen Tokens, nach denen Angreifer suchen

Interviewer fragen Kandidaten häufig, die Vertrauensgrenzen in einer typischen Deployment-Pipeline nachzuzeichnen. Eine starke Antwort kartiert jede Phase, in der ein Angreifer Code injizieren oder Credentials exfiltrieren könnte.

SAST und SCA: Schwachstellen frühzeitig erkennen

Static Application Security Testing (SAST) analysiert Quellcode auf Sicherheitslücken, ohne das Programm auszuführen. Software Composition Analysis (SCA) identifiziert bekannte Schwachstellen in Drittanbieter-Abhängigkeiten. Die Ausführung beider bei jedem Pull Request erfasst die Mehrheit der häufigen Sicherheitsprobleme, bevor Code gemergt wird.

# .github/workflows/security.yml
name: Security Scan

on:
  pull_request:
    branches: [main]

jobs:
  sast:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@v4
      
      - name: Run CodeQL
        uses: github/codeql-action/analyze@v3
        with:
          languages: javascript,typescript
          queries: security-extended

  sca:
    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: .
          severity: HIGH,CRITICAL
          exit-code: 1

Der obige Workflow führt CodeQL für SAST und Trivy für SCA aus. Das Setzen von exit-code: 1 bei Trivy führt zum Build-Fehlschlag, wenn hohe oder kritische Schwachstellen auftreten. GitHub Advanced Security und GitLab Ultimate beinhalten integrierte SAST-Funktionen, die sich in ihre jeweiligen Merge-Request-Workflows integrieren.

Secrets-Management mit OIDC-Federation

Langlebige Credentials, die in CI/CD-Plattformen gespeichert sind, bleiben der am häufigsten ausgenutzte Angriffsvektor bei Pipeline-Kompromittierungen. GitHub Actions OIDC ersetzt statische Secrets durch kurzlebige Tokens, die zur Laufzeit vom Cloud-Anbieter ausgestellt werden.

# .github/workflows/deploy.yml
name: Deploy to AWS

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write  # Required for OIDC
      contents: read
    steps:
      - uses: actions/checkout@v4
      
      - name: Configure AWS credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
          aws-region: us-east-1
          # No AWS_ACCESS_KEY_ID or AWS_SECRET_ACCESS_KEY stored anywhere
      
      - name: Deploy to ECS
        run: aws ecs update-service --cluster prod --service api --force-new-deployment

Die AWS IAM-Rollen-Trust-Policy beschränkt, welche Repositories und Branches die Rolle übernehmen können:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main"
        }
      }
    }
  ]
}

Die Bedingung beschränkt die Credential-Ausstellung auf den main-Branch eines bestimmten Repositories. Azure und GCP bieten äquivalente OIDC-Federation-Funktionen. Für Secrets, die existieren müssen, bieten HashiCorp Vault und Cloud-native Optionen wie AWS Secrets Manager zentralisierte Rotation und Zugriffs-Logging.

Container-Sicherheit und SBOM-Generierung

Container-Images führen Abhängigkeiten über den Anwendungscode hinaus ein. Basis-Images, Systempakete und Build-Tools tragen alle potenzielle Schwachstellen. Das Scannen von Images während des Build-Prozesses und die Generierung einer Software Bill of Materials (SBOM) bietet Transparenz in die vollständige Abhängigkeitskette.

# GitLab CI container security
container_scanning:
  stage: test
  image: registry.gitlab.com/gitlab-org/security-products/analyzers/container-scanning:7
  variables:
    CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    CS_DOCKERFILE_PATH: Dockerfile
  script:
    - /analyzer run
  artifacts:
    reports:
      container_scanning: gl-container-scanning-report.json
      cyclonedx: gl-sbom.cdx.json

Das SBOM-Artefakt im CycloneDX-Format ermöglicht es nachgelagerten Konsumenten, auf neu offengelegte Schwachstellen zu prüfen, ohne neu zu bauen. Supply-Chain-Sicherheits-Frameworks wie SLSA erfordern die SBOM-Generierung als Baseline-Kontrolle.

Dynamic Application Security Testing in Staging

DAST-Tools testen laufende Anwendungen auf Schwachstellen, die statische Analyse nicht erkennen kann, einschließlich Authentifizierungsfehler, Injection-Schwachstellen und Sicherheitsfehlkonfigurationen. Die Ausführung von DAST gegen eine Staging-Umgebung vor dem Produktions-Deployment fängt Probleme ab, die frühere Gates überleben.

# .gitlab-ci.yml
dast:
  stage: dast
  image: registry.gitlab.com/gitlab-org/security-products/analyzers/dast:5
  variables:
    DAST_WEBSITE: https://staging.example.com
    DAST_AUTH_URL: https://staging.example.com/login
    DAST_USERNAME: $DAST_USER
    DAST_PASSWORD: $DAST_PASSWORD
    DAST_AUTH_VERIFICATION_URL: https://staging.example.com/dashboard
  script:
    - /analyze
  artifacts:
    reports:
      dast: gl-dast-report.json
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

OWASP ZAP bietet eine kostenlose Alternative für Teams ohne GitLab Ultimate. Authentifizierte Scans testen Funktionalität hinter Login-Wänden, wo sensible Operationen typischerweise residieren. Für Kubernetes-Umgebungen validiert API-Sicherheitstesting Ingress-Konfigurationen und Service-Mesh-Policies.

Infrastructure as Code Sicherheitsscanning

Terraform, Kubernetes-Manifeste und Helm-Charts definieren Infrastruktur, die Angreifer ins Visier nehmen. IaC-Scanning fängt Fehlkonfigurationen ab, bevor sie Cloud-Umgebungen erreichen.

# Checkov IaC scanning in GitHub Actions
iac-scan:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    
    - name: Run Checkov
      uses: bridgecrewio/checkov-action@v12
      with:
        directory: terraform/
        framework: terraform
        soft_fail: false
        output_format: sarif
        output_file_path: checkov.sarif
    
    - name: Upload SARIF
      uses: github/codeql-action/upload-sarif@v3
      with:
        sarif_file: checkov.sarif

Checkov validiert Terraform-Konfigurationen gegen Sicherheits-Benchmarks einschließlich CIS und SOC2. Die SARIF-Ausgabe integriert sich mit dem GitHub Security Tab für einheitliches Schwachstellen-Tracking. Teams, die Ansible verwenden, können ansible-lint mit Sicherheitsregeln zur gleichen Pipeline-Stufe hinzufügen.

GitHub Actions Supply Chain Hardening

Das Pinnen von Actions auf vollständige Commit-SHAs verhindert tag-basierte Angriffe, bei denen Maintainer oder kompromittierte Accounts bösartige Versionen auf bestehende Tags force-pushen. Die Megalodon-Kampagne im Mai 2026 hat über 5.700 bösartige Commits über Tausende von Repositories in einem einzigen sechsstündigen Fenster gepusht.

# Pin to commit SHA, not tag
steps:
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2
  
  # Avoid mutable tags like @v4 or @latest
  # Bad: uses: actions/checkout@v4

Dependabot aktualisiert SHA-gepinnte Actions, wenn neue Versionen veröffentlicht werden. Die OWASP DevSecOps Guideline empfiehlt zusätzliche Kontrollen:

• Workflow-Berechtigungen auf das Minimum beschränken mit permissions:-Blöcken
• pull_request_target-Trigger deaktivieren oder auf gelabelte PRs von Collaborators beschränken
• GITHUB_TOKEN mit read-only-Defaults auf Organisationsebene verwenden
• Required Status Checks und Branch Protection auf Standard-Branches aktivieren

Häufige DevSecOps-Interviewfragen

Interviewer bewerten sowohl technische Tiefe als auch praktische Erfahrung. Diese Fragen erscheinen häufig in DevOps-Sicherheitsinterviews.

F: Wie würden Sie verhindern, dass Secrets in ein Repository committed werden?

Pre-Commit-Hooks mit Tools wie detect-secrets oder gitleaks scannen gestagete Änderungen vor dem Commit. Serverseitige Push-Regeln in GitHub Enterprise oder GitLab blockieren Commits, die Muster enthalten, die bekannten Secret-Formaten entsprechen. Secrets-Scanning sollte auch in CI als Sicherheitsnetz laufen, da Entwickler lokale Hooks umgehen können.

F: Erklären Sie den Unterschied zwischen SAST, DAST und SCA.

SAST analysiert Quellcode ohne Ausführung und findet Bugs wie SQL-Injection-Muster und hardcodierte Credentials. SCA identifiziert bekannte Schwachstellen in Abhängigkeiten durch Abgleich von Paketversionen mit CVE-Datenbanken. DAST testet laufende Anwendungen durch das Senden bösartiger Anfragen und Beobachten der Antworten. Eine ausgereifte Pipeline führt alle drei aus: SAST und SCA bei jedem PR, DAST gegen Staging vor Produktions-Releases.

F: Was ist das Prinzip der minimalen Berechtigung in CI/CD?

Build-Jobs sollten nur die Berechtigungen haben, die zum Abschluss ihrer spezifischen Aufgabe erforderlich sind. Ein Job, der nach Staging deployt, benötigt keine Produktions-Credentials. OIDC-Federation erzwingt dies durch die Ausstellung von Credentials, die auf spezifische Repositories, Branches und Workflow-Jobs beschränkt sind. Die OWASP CI/CD Top 10 listet unzureichendes Identitäts- und Zugriffsmanagement als Top-Risiko, weil kompromittierte Jobs mit übermäßigen Berechtigungen die Angriffsfläche dramatisch erweitern.

F: Wie verifizieren Sie die Integrität von Container-Images?

Content-Trust-Signaturen (Docker Content Trust, Sigstore cosign) bieten kryptographische Verifizierung, dass Images von vertrauenswürdigen Pipelines gebaut wurden. SBOM-Attestierungen dokumentieren die Komponenten innerhalb von Images. Admission Controller in Kubernetes lehnen unsignierte Images oder Images mit bekannten kritischen Schwachstellen ab. Registry-Scanning fängt Schwachstellen ab, die nach der Build-Zeit erscheinen.

F: Beschreiben Sie einen Supply-Chain-Angriff auf CI/CD und wie man ihn verhindert.

Der tj-actions/changed-files-Angriff kompromittierte eine weit verbreitete GitHub Action und injizierte Code, der Secrets zu von Angreifern kontrollierten Endpoints exfiltrierte. Präventionsmaßnahmen umfassen: Pinnen von Actions auf Commit-SHAs anstelle von Tags, Verwendung von Dependabot zur Aktualisierung gepinnter Versionen, Einschränkung welche Actions über Policies auf Organisationsebene laufen können, und Überwachung von Workflow-Runs auf unerwartete Netzwerkverbindungen oder Credential-Zugriffe.

Aufbau einer DevSecOps-Roadmap für technische Interviews

Kandidaten, die strukturiertes Denken über Sicherheitsimplementierung demonstrieren, stechen hervor. Ein praktisches DevSecOps-Rollout priorisiert High-Impact, Low-Effort-Kontrollen zuerst:

• Secrets-Scanning und Branch Protection sofort aktivieren, da beide kostenlos sind und die häufigsten Angriffsvektoren blockieren
• SAST und SCA zu Pull-Request-Checks im ersten Sprint hinzufügen, um Schwachstellen vor dem Merge zu erfassen
• Von statischen Credentials zu OIDC-Federation migrieren, um die gefährlichsten Secrets aus CI/CD-Plattformen zu eliminieren
• Container-Scanning und SBOM-Generierung als Teil von Image-Builds implementieren
• IaC-Scanning für Terraform, Kubernetes und Cloud-Konfiguration deployen
• DAST für Anwendungen mit Authentifizierung oder sensitivem Datenhandling hinzufügen
• Runtime-Monitoring mit Falco oder Äquivalent für Produktions-Kubernetes-Cluster etablieren

Interviewer schätzen Kandidaten, die Tradeoffs anerkennen. Sicherheitsscanning fügt Pipeline-Latenz hinzu. Falsch-Positive erzeugen Alert-Fatigue. Eine ausgereifte DevSecOps-Praxis stimmt Schwellenwerte ab, akzeptiert kalkulierte Risiken mit kompensierenden Kontrollen und misst kontinuierlich die mittlere Zeit zur Behebung.