Die durchschnittliche Zeit vom Commit bis zur Produktion hat sich in den letzten drei Jahren von Wochen auf Stunden verkürzt. Doch das Security-Review dauert immer noch Tage — und das ist ein Problem. Dieser Leitfaden zeigt, wie man fünf Schichten von Sicherheitsscans direkt in die CI/CD-Pipeline integriert, damit der Build stoppt, bevor eine Schwachstelle in die Produktion gelangt. Keine Theorie — konkrete Konfigurationen für GitHub Actions, GitLab CI und Jenkins.

Warum manuelles Security-Review 2026 nicht mehr ausreicht¶

Stellen Sie sich ein Entwicklungsteam vor, das 15 Mal am Tag deployt. Jedes Deployment durchläuft Code Review, Unit Tests, Integrationstests und Linting. Aber das Security-Review? Das erledigt ein einzelner Security-Engineer, der nicht hinterherkommt, sodass „kritische” Pull Requests mit dem Vermerk „Security-Review später” gemergt werden. Später kommt nie.

Das ist kein Einzelfall. Laut dem Snyk 2025 State of Application Security Report geben 76 % der Organisationen zu, dass Sicherheitstests ihren Release-Zyklus verlangsamen. Das Ergebnis? Entweder wird die Sicherheit umgangen oder Deployments sind langsamer als nötig. Beides ist falsch.

Die DevSecOps-Pipeline löst diesen Kompromiss radikal: Sicherheitsprüfungen laufen automatisch, parallel zu anderen Tests, bei jedem Commit. Entwickler erhalten Feedback in Minuten, nicht in Tagen. Das Security-Team wechselt von der Rolle des Gatekeepers zur Rolle des Architekten — es definiert Regeln, anstatt jeden Pull Request zu prüfen.

Bei CORE SYSTEMS implementieren wir DevSecOps-Pipelines für Kunden von Fintech bis zum öffentlichen Sektor. Aus der Praxis wissen wir, dass eine richtig konfigurierte Pipeline die Anzahl der Sicherheitsvorfälle in der Produktion um 60–80 % reduziert und gleichzeitig den Release-Zyklus beschleunigt, da das manuelle Warten auf Security-Freigaben entfällt.

Fünf Schichten des Sicherheitsscans¶

Eine DevSecOps-Pipeline ist nicht ein einzelnes Tool — sie ist eine Orchestrierung von fünf komplementären Scan-Schichten. Jede Schicht fängt eine andere Art von Schwachstelle in einer anderen Phase des Code-Lebenszyklus ab. Wenn Sie eine auslassen, haben Sie einen blinden Fleck.

1. SAST — Static Application Security Testing¶

SAST analysiert Quellcode ohne ihn auszuführen. Es sucht nach Mustern, die zu Schwachstellen führen: SQL-Injection, XSS, hartcodierte Secrets, unsichere Deserialisierung, Path Traversal. SAST sieht Code so, wie ein Entwickler ihn liest — es kann auf die genaue Zeile zeigen und erklären, warum sie problematisch ist.

Semgrep ist 2026 der De-facto-Standard für SAST in modernen Teams. Im Gegensatz zu Legacy-Tools (Fortify, Checkmarx) ist es Open-Source, schnell und seine Regeln werden in YAML geschrieben, nicht in einer proprietären Sprache. Semgrep Pro ergänzt Cross-File- und Cross-Function-Analyse (Taint Tracking), was False Positives dramatisch reduziert.

Konkretes Beispiel: Semgrep-Regel zur SQL-Injection-Erkennung in Python:

`# .semgrep/sql-injection.yml

rules:

• id: python-sql-injection

  patterns:

  • pattern: |

    cursor.execute(f”…{$VAR}…”)

  • pattern-not: |

    cursor.execute(f”…{int($VAR)}…”)

  message: |

  SQL injection: user input $VAR interpolated

  directly into SQL query. Use parameterized queries.

  severity: ERROR

  languages: [python]

  metadata:

  cwe: CWE-89

  owasp: A03:2021`

In der Praxis kombinieren wir Semgrep mit kundenspezifischen Regeln für den jeweiligen Tech-Stack. Einer unserer Fintech-Kunden hatte einen internen ORM-Wrapper, der Standard-Parameterized-Queries umging — generisches SAST hat das nie erkannt. Eine benutzerdefinierte Semgrep-Regel schon.

2. SCA — Software Composition Analysis¶

Moderne Anwendungen bestehen zu 70–90 % aus Open-Source-Abhängigkeiten. SCA scannt diese Abhängigkeiten gegen bekannte Schwachstellendatenbanken (NVD, GitHub Advisory Database, OSV) und identifiziert Bibliotheken mit CVEs.

Snyk Open Source geht über einfaches CVE-Matching hinaus. Es analysiert die Erreichbarkeit — ob Ihr Code tatsächlich die verwundbare Funktion in einer Abhängigkeit aufruft. Log4j (CVE-2021-44228) ist im Dependency Tree? Snyk prüft, ob Ihre Anwendung überhaupt JNDI-Lookup verwendet. Wenn nicht, ändert sich die Priorität dramatisch.

Wichtige SCA-Metriken, die wir verfolgen:

• Abhängigkeiten mit bekannten CVEs: Wie viele Abhängigkeiten haben aktive CVEs? Ziel: 0 kritisch, <5 hoch.
• Dependency Freshness: Wie alt sind Ihre Abhängigkeiten? Eine Abhängigkeit, die 3+ Jahre ohne Update ist, ist ein Red Flag.
• Lizenz-Compliance: Verwenden Sie eine GPL-Bibliothek in einem proprietären Produkt? SCA erkennt es, bevor es ein Anwalt tut.
• Transitive Abhängigkeiten: Ihre direkte Abhängigkeit ist OK, aber deren Abhängigkeit hat ein kritisches CVE. SCA scannt den gesamten Baum.

3. DAST — Dynamic Application Security Testing¶

DAST testet eine laufende Anwendung von außen — wie ein Angreifer. Es sendet fehlerhafte Requests, testet die Authentifizierung, sucht nach exponierten Endpunkten und überprüft HTTP-Security-Header. DAST findet Dinge, die SAST nicht sehen kann: fehlkonfigurierte Server, fehlende CORS-Policy, Session-Management-Probleme.

In der CI/CD-Pipeline läuft DAST typischerweise gegen die Staging-Umgebung nach einem erfolgreichen Deploy. OWASP ZAP (Zed Attack Proxy) ist die Open-Source-Wahl; für Enterprise-Deployment empfehlen wir Burp Suite Enterprise oder Snyk DAST (ehemals Probely).

Beispiel der ZAP-Integration in GitHub Actions:

`# .github/workflows/dast.yml

dast-scan:

runs-on: ubuntu-latest

needs: deploy-staging

steps:

- name: ZAP Full Scan

  uses: zaproxy/[email protected]

  with:

    target: 'https://staging.example.com'

    rules_file_name: '.zap/rules.tsv'

    cmd_options: '-a -j'

- name: Upload SARIF

  uses: github/codeql-action/upload-sarif@v3

  with:

    sarif_file: 'report.sarif'`

4. Container-Scanning¶

Wenn Sie Container deployen (und 2026 — wer tut das nicht?), müssen Sie sowohl das Basis-Image als auch die Anwendungsschicht scannen. Ein verwundbares Alpine-Basis-Image mit einem CVE in OpenSSL oder libcurl ist ein Einstiegspunkt, den SAST nie sehen wird.

Trivy von Aqua Security ist der am weitesten verbreitete Open-Source-Container-Scanner. Es scannt OS-Pakete, sprachspezifische Abhängigkeiten, IaC-Fehlkonfigurationen und Secrets — alles in einem Tool. Bei CORE SYSTEMS implementieren wir Trivy als obligatorischen Schritt in der CI-Pipeline und als Admission Controller in Kubernetes (über den Trivy Operator).

`# Trivy in CI — GitHub Actions

container-scan:

runs-on: ubuntu-latest

steps:

- name: Build image

  run: docker build -t myapp:${{ github.sha }} .

- name: Trivy vulnerability scan

  uses: aquasecurity/[email protected]

  with:

    image-ref: 'myapp:${{ github.sha }}'

    format: 'sarif'

    output: 'trivy-results.sarif'

    severity: 'CRITICAL,HIGH'

    exit-code: '1' # fail build on findings

- name: Upload to GitHub Security

  uses: github/codeql-action/upload-sarif@v3

  with:

    sarif_file: 'trivy-results.sarif'`

Wichtiges Detail: Scannen Sie das fertige Image, nicht nur das Dockerfile. Ein Multi-Stage-Build kann im finalen Stage andere Pakete enthalten als im Builder-Stage. Und scannen Sie bei jedem Build — täglich erscheinen neue CVEs.

5. IaC-Scanning — Infrastructure as Code¶

Terraform, Helm Charts, Kubernetes-Manifeste, CloudFormation, Pulumi — Ihre Infrastruktur ist Code und braucht ein Security-Review wie jeder andere Code. IaC-Scanning deckt Fehlkonfigurationen auf, bevor sie in die Produktion gelangen: S3-Buckets ohne Verschlüsselung, Security Groups mit 0.0.0.0/0, Kubernetes-Pods mit privileged: true.

Checkov von Bridgecrew (Palo Alto) ist der umfassendste Open-Source-IaC-Scanner. Er unterstützt über 1.000 eingebaute Regeln für Terraform, CloudFormation, Kubernetes, Helm, ARM-Templates und Docker. Benutzerdefinierte Policies werden in Python oder YAML geschrieben.

`# Checkov in GitLab CI

iac-scan:

stage: test

image: bridgecrew/checkov:latest

script:

- checkov -d ./terraform/

  --framework terraform

  --output sarif

  --soft-fail-on LOW

  --hard-fail-on CRITICAL,HIGH

  --skip-check CKV_AWS_18 # intentional public bucket

- checkov -d ./k8s/

  --framework kubernetes

  --hard-fail-on CRITICAL`

Bei CORE SYSTEMS implementieren wir Checkov mit einem kundenspezifischen Policy-Paket für jeden Kunden. Ein Bankkunde hat strikte Regeln zur Verschlüsselung im Ruhezustand für alle Storage-Services. Ein E-Commerce-Kunde benötigt spezifische Netzwerkisolierungsregeln für PCI-DSS-Compliance. Generische Regeln reichen nicht aus.

Komplette Pipeline — Wie alles zusammenpasst¶

Fünf Tools sind fünf bewegliche Teile. Der Schlüssel liegt in der Orchestrierung — wann jedes läuft, wie Ergebnisse aggregiert werden und wann der Build stoppt.

Hier ist eine Referenz-Pipeline-Architektur, die wir als Grundlage für die meisten Kunden-Deployments verwenden:

Phase 1: Pre-commit & PR (Sekunden)¶

Secret Detection: git-secrets oder gitleaks als Pre-commit-Hook. Stoppt Commits mit AWS-Keys, API-Tokens, privaten Schlüsseln.

SAST (Fast-Modus): Semgrep mit –fast-Flag — scannt nur geänderte Dateien. Feedback in 30 Sekunden.

Warum hier: Der Entwickler bekommt sofort Feedback, vor dem Push. Günstigster Ort zum Beheben.

Phase 2: CI-Build (Minuten)¶

SAST (Full-Modus): Semgrep Cross-File-Analyse des gesamten Repositories. Taint Tracking, Data-Flow-Analyse.

SCA: Snyk test oder Trivy fs Scan — vollständiger Dependency Tree, Erreichbarkeitsanalyse, Lizenzprüfung.

IaC-Scan: Checkov auf Terraform, Helm, K8s-Manifeste. Parallel zu SAST und SCA.

Container-Scan: Trivy Image-Scan nach Docker Build. Schwellenwert: CRITICAL = Fail, HIGH = Warnung.

Warum hier: Diese Scans laufen parallel (1–3 Minuten insgesamt). Build-Fehler stoppt den Merge in main.

Phase 3: Post-deploy Staging (Minuten–Stunde)¶

DAST: ZAP oder Burp Suite gegen die Staging-Umgebung. Baseline-Scan (5 Min.) bei jedem Deploy, Full Scan (30–60 Min.) als nächtlicher Cron-Job.

API Security Testing: OpenAPI-Spec-Validierung, Fuzz-Testing von API-Endpunkten, Authentifizierungs- und Autorisierungs-Grenzfälle.

Warum hier: DAST benötigt eine laufende Anwendung. Staging ist eine sichere Umgebung für destruktive Tests.

Phase 4: Production Runtime (kontinuierlich)¶

Container-Runtime-Scanning: Trivy Operator in Kubernetes — kontinuierliches Scanning laufender Images gegen neu veröffentlichte CVEs.

SBOM-Monitoring: CycloneDX oder SPDX SBOM wird zur Build-Zeit generiert und kontinuierlich überwacht. Neues CVE in einer Abhängigkeit? Alert.

Warum hier: Ein neues CVE erscheint nach dem Deploy. Runtime-Scanning stellt sicher, dass Sie innerhalb von Stunden davon erfahren, nicht Wochen.

Komplette GitHub-Actions-Pipeline — Copy-paste-fertig¶

Hier ist eine reale Konfiguration, die wir als Grundlage verwenden. Passen Sie die Schwellenwerte und Skip-Check-Listen nach Ihrer Risikobereitschaft an:

`# .github/workflows/devsecops.yml

name: DevSecOps Pipeline

on:

pull_request:

branches: [main, develop]

push:

branches: [main]

jobs:

# — SAST —

sast:

runs-on: ubuntu-latest

permissions:

  security-events: write

steps:

  - uses: actions/checkout@v4

  - name: Semgrep SAST

    uses: semgrep/semgrep-action@v1

    with:

      config: >-

        p/default

        p/owasp-top-ten

        p/cwe-top-25

        .semgrep/

    env:

      SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_TOKEN }}

# — SCA —

sca:

runs-on: ubuntu-latest

steps:

  - uses: actions/checkout@v4

  - name: Snyk dependency scan

    uses: snyk/actions/node@master

    with:

      args: --severity-threshold=high

    env:

      SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

# — IaC Scan —

iac:

runs-on: ubuntu-latest

steps:

  - uses: actions/checkout@v4

  - name: Checkov IaC scan

    uses: bridgecrewio/checkov-action@v12

    with:

      directory: ./infrastructure/

      framework: terraform,kubernetes

      soft_fail_on: LOW,MEDIUM

      hard_fail_on: CRITICAL,HIGH

# — Container Scan —

container:

runs-on: ubuntu-latest

needs: [sast, sca] # build only if code is clean

steps:

  - uses: actions/checkout@v4

  - name: Build image

    run: docker build -t app:${{ github.sha }} .

  - name: Trivy container scan

    uses: aquasecurity/[email protected]

    with:

      image-ref: 'app:${{ github.sha }}'

      format: 'sarif'

      severity: 'CRITICAL,HIGH'

      exit-code: '1'

  - name: Generate SBOM

    run: trivy image --format cyclonedx

      --output sbom.json app:${{ github.sha }}

  - uses: actions/upload-artifact@v4

    with:

      name: sbom

      path: sbom.json`

Secret Management — Erste Verteidigungslinie¶

Der GitGuardian 2025 State of Secrets Sprawl Report enthüllte 12,8 Millionen neue hartcodierte Secrets auf öffentlichem GitHub im Jahr 2024. AWS-Keys, Datenbank-Zugangsdaten, API-Tokens — alles in Repositories committed. Und das sind nur öffentliche Repos. In privaten ist die Situation schlimmer, weil Entwickler ein falsches Sicherheitsgefühl haben.

Ein Pre-commit-Hook mit gitleaks ist das Minimum. Konfiguration:

`# .pre-commit-config.yaml

repos:

• repo: https://github.com/gitleaks/gitleaks

  rev: v8.22.0

  hooks:

  • id: gitleaks

DevSecOps Pipeline — Sicherheitsautomatisierung in CI/CD 2026¶

[extend]

useDefault = true

[[rules]]

id = “internal-api-key”

description = “Internal API key pattern”

regex = ‘’‘CORE_API_[A-Za-z0-9]{32,}’‘’

tags = [“api”, “internal”]`

Aber ein Pre-commit-Hook ist Opt-in — ein Entwickler kann ihn mit --no-verify umgehen. Daher muss Secret-Scanning auch in der CI laufen als serverseitige Schranke. GitHub bietet natives Secret-Scanning mit Push Protection. GitLab hat Secret Detection als Teil seiner CI-Vorlage. Für Self-Hosted-Lösungen verwenden Sie gitleaks oder TruffleHog in einem CI-Job.

Wie Sie Ihr Team nicht in False Positives ertränken¶

Der schnellste Weg, die DevSecOps-Adoption zu beenden, ist, Entwickler mit Hunderten von Alerts zu überfluten, von denen 80 % False Positives sind. Das Team beginnt, Sicherheitsfunde zu ignorieren, und der gesamte Aufwand ist verschwendet. Bei CORE SYSTEMS lösen wir das mit einem dreistufigen Ansatz:

1. Schweregrad-basiertes Gating: Nicht alle Funde sind gleich. Build scheitert nur bei CRITICAL und HIGH. MEDIUM erzeugt eine Warnung im PR-Kommentar. LOW geht ins Security-Dashboard — blockiert nie den Build.

2. Baseline und Unterdrückung: Bei der erstmaligen Integration eines Tools in ein bestehendes Projekt erhalten Sie Hunderte von Funden aus Legacy-Code. Lösung: Erstellen Sie eine Baseline-Datei mit bestehenden Funden. CI meldet dann nur neue Funde. Legacy-Funde werden während eines Tech-Debt-Sprints bearbeitet, nicht als Blocker für jeden PR.

`# Semgrep — bestehende Funde ignorieren

Bei erstmaliger Integration:¶

semgrep –config auto –sarif –output baseline.sarif .

In CI — nur neue Funde:¶

semgrep –config auto –baseline-commit ${{ github.event.pull_request.base.sha }}`

3. Regel-Tuning: Generische Regelsätze enthalten Regeln, die für Ihren Stack keinen Sinn ergeben. Java-Serialisierungsregeln in einem Python-Projekt? Deaktivieren. PHP-spezifisches XSS in einem Go-Backend? Deaktivieren. Überprüfen Sie monatlich unterdrückte Funde — wenn eine Regel >50 % False Positives erzeugt, modifizieren oder ersetzen Sie sie durch eine benutzerdefinierte Version.

SBOM und Supply-Chain-Security — Pflicht, nicht Nice-to-have¶

Der EU Cyber Resilience Act (CRA), der 2027 in Kraft tritt mit einer Übergangsfrist ab 2025, verlangt eine Software Bill of Materials (SBOM) für alle Produkte mit digitalen Elementen, die auf dem EU-Markt verkauft werden. Die US Executive Order 14028 verlangt dasselbe für Bundeslieferanten.

Eine SBOM ist kein PDF, das Bibliotheken auflistet. Es ist eine maschinenlesbare Datei (CycloneDX- oder SPDX-Format), die enthält:

• Komponenten: alle Abhängigkeiten — direkte und transitive, einschließlich Versionen.
• Lizenzen: unter welcher Lizenz jede Komponente steht.
• Schwachstellen: bekannte CVEs zum Zeitpunkt der Erstellung.
• Herkunft: woher die Komponente stammt (Registry, Commit-Hash).

Die SBOM-Generierung gehört als Build-Artefakt in die CI-Pipeline:

`# SBOM-Generierung mit Trivy

trivy image –format cyclonedx \

–output sbom-$(date +%Y%m%d).cdx.json \

myapp:${{ github.sha }}

Alternative: syft (Anchore)¶

syft packages myapp:${{ github.sha }} \

-o cyclonedx-json=sbom.cdx.json

Validierung und Signierung¶

cosign attest –predicate sbom.cdx.json \

–type cyclonedx \

myapp:${{ github.sha }}`

Bei CORE SYSTEMS implementieren wir SBOM-Pipelines mit kontinuierlicher Überwachung — die SBOM wird bei jedem Build generiert und in einem zentralen Registry gespeichert (Dependency-Track). Wenn ein neues CVE erscheint, identifiziert das System automatisch alle deployten Versionen, die die betroffene Komponente enthalten, und erstellt ein Ticket mit Priorität basierend auf Schweregrad und Erreichbarkeit.

Erfolgsmetriken — Was messen und welche Ziele setzen¶

Eine DevSecOps-Pipeline ohne Metriken ist Sicherheitstheater. Sie messen, um zu wissen, ob die Investition funktioniert. Hier sind die Metriken, die wir ab dem ersten Tag empfehlen:

• Mean Time to Remediation (MTTR): Durchschnittliche Zeit von der Schwachstellen-Erkennung bis zur Behebung. Ziel für kritische CVEs: <24 Stunden. Hoch: <7 Tage. MTTR unter 72 Stunden für kritische liegt im oberen Dezil.
• Escape Rate: Wie viele Schwachstellen passieren die gesamte Pipeline und erreichen die Produktion. Ziel: <5 % aller Funde. Dies ist die ultimative Pipeline-Effektivitätsmetrik.
• False-Positive-Rate: Wie viele Funde das Security-Team als False Positive markiert. Über 30 % = Pipeline braucht Tuning. Über 50 % = Entwickler nehmen Alerts nicht mehr ernst.
• Security-Debt-Trend: Gesamtzahl offener Sicherheitsfunde über die Zeit. Sollte sinken oder stabil sein, nie steigen.
• Pipeline-Fehlerrate: Wie viele Builds bei Sicherheitsprüfungen scheitern. Über 20 % = Regeln zu streng oder zu viele False Positives.
• Developer Friction: Wie viel Zeit Sicherheitsscans zur CI-Pipeline hinzufügen. Ziel: <5 Minuten für SAST+SCA+Container-Scan. Über 10 Minuten beginnen Entwickler zu umgehen.
• Coverage: Wie viele Repositories eine aktive DevSecOps-Pipeline haben. Ziel: 100 % für Produktions-Workloads.

Wir empfehlen ein Grafana-Dashboard mit Daten aus SARIF-Reports, aggregiert über DefectDojo oder GitHub Security Overview. Ein wöchentliches Security-Standup (15 Minuten) zur Überprüfung dieser Metriken hält das Team rechenschaftspflichtig.

Implementierungs-Roadmap — 8 Wochen von Null zur Produktion¶

Sie brauchen kein Jahr, um eine DevSecOps-Pipeline aufzubauen. Mit klaren Prioritäten und den richtigen Tools haben Sie in 8 Wochen eine funktionsfähige Pipeline:

Wochen 1–2: Grundlagen¶

Secret-Scanning: gitleaks Pre-commit-Hook + CI-Job. Sofortiger Nutzen, minimaler Aufwand.

SCA: Snyk oder Trivy fs Scan in CI. Eine der einfachsten Erweiterungen — npm audit / pip-audit reicht nicht.

Ergebnis: Jeder PR hat Secret-Scan und Dependency-Scan. Build scheitert bei kritischem CVE.

Wochen 3–4: SAST & Container¶

SAST: Semgrep mit p/default + p/owasp-top-ten Regelsätzen. Baseline für bestehenden Code.

Container-Scanning: Trivy Image-Scan nach Docker Build. Schwellenwert je nach Kontext setzen.

Ergebnis: PR-Kommentare mit SAST-Funden. Container-Images vor Push zum Registry gescannt.

Wochen 5–6: IaC & DAST¶

IaC-Scanning: Checkov auf Terraform/Kubernetes. Kundenspezifisches Policy-Paket für Ihre Umgebung.

DAST: ZAP Baseline-Scan gegen Staging nach jedem Deploy. Full Scan als nächtlicher Cron.

Ergebnis: Infrastruktur-Fehlkonfigurationen im PR erkannt. Staging automatisch gescannt.

Wochen 7–8: Observability & Tuning¶

Dashboard: Grafana-Dashboard mit MTTR, Escape Rate, False-Positive-Rate. Daten aus DefectDojo oder nativem GitHub/GitLab.

Tuning: False Positives überprüfen, Schwellenwerte anpassen, benutzerdefinierte Regeln für spezifische Muster.

SBOM: Automatische Generierung zur Build-Zeit, Upload zu Dependency-Track.

Ergebnis: Messbare DevSecOps-Pipeline mit Metriken und kontinuierlichem Verbesserungsprozess.

Häufigste Fehler aus der Praxis¶

In zwei Jahren des Deployments von DevSecOps-Pipelines für Kunden haben wir immer wieder dieselben Fehler gesehen:

• „Wir schalten alles auf einmal in allen Repositories ein”: Entwickler bekommen über Nacht Hunderte von Alerts. Ergebnis: Widerstand, Umgehung, Deaktivierung. Starten Sie mit einem Pilotprojekt, stimmen Sie die Regeln ab, dann rollen Sie aus.
• Security-Team definiert Regeln ohne Entwickler: Regeln, die für den jeweiligen Stack keinen Sinn ergeben, erzeugen False Positives und Frustration. Entwickler müssen von Anfang an Teil der Regeldefinition sein.
• Keine Ownership über Funde: Security-Scan findet 200 Funde, aber niemand hat sie im Backlog. Jeder Fund braucht einen Verantwortlichen und ein SLA für die Behebung.
• Basis-Images ignorieren: Das Team scannt seinen Code, verwendet aber ein 3 Jahre altes Node.js-Basis-Image mit 47 CVEs. Basis-Image-Hygiene ist fundamental — Versionen pinnen, Distroless- oder Chainguard-Images verwenden.
• Fehlende Feedback-Schleife: Pipeline läuft, aber niemand liest die Ergebnisse. Integration in PR-Kommentare, Slack-Benachrichtigungen für kritische Funde, wöchentliches Security-Standup — das sind die Mechanismen, die die Aufmerksamkeit aufrechterhalten.
• Security als Gate statt als Leitplanke: Eine DevSecOps-Pipeline sollte keine Wand sein, gegen die PRs prallen. Sie sollte ein Leitfaden sein — Soft-Fail mit klarer Kommunikation ist besser als Hard-Fail ohne Kontext.

Tools im Kontext — Entscheidungsmatrix 2026¶

Die Tool-Auswahl hängt vom Tech-Stack, Budget und davon ab, ob Sie einen Best-of-Breed- oder Single-Vendor-Ansatz bevorzugen:

Open-Source-Stack (0 EUR Lizenzkosten)¶

SAST: Semgrep OSS — Community-Regeln, Single-File-Analyse, schnell.

SCA: Trivy fs — scannt Lockfiles, unterstützt 20+ Paketmanager.

Container: Trivy image — OS-Pakete + Sprach-Abhängigkeiten in einem Scan.

IaC: Checkov — 1.000+ Regeln, Terraform/K8s/CloudFormation/Helm.

DAST: OWASP ZAP — automatisierter Baseline- und Full Scan.

Secrets: gitleaks — Pre-commit + CI, benutzerdefinierte Regex-Muster.

Enterprise-Stack (konsolidiert)¶

Snyk-Plattform: SAST (Snyk Code), SCA (Snyk Open Source), Container (Snyk Container), IaC (Snyk IaC) — ein Dashboard, eine Policy Engine, IDE-Integration.

Alternative: GitHub Advanced Security — CodeQL für SAST, Dependabot für SCA, Secret-Scanning, natives SARIF-Aggregation.

DAST: Burp Suite Enterprise oder Snyk DAST — geplante Scans, CI-Integration, authentifiziertes Scanning.

Bei CORE SYSTEMS implementieren wir beide Varianten je nach Kundenkontext. Startups und kleinere Teams beginnen mit dem Open-Source-Stack — Trivy + Semgrep + Checkov deckt 80 % der Anforderungen bei null Lizenzkosten ab. Enterprise-Kunden mit 50+ Repositories profitieren typischerweise von einer konsolidierten Plattform (Snyk, GitHub Advanced Security), da die Reduzierung des operativen Aufwands die Lizenzkosten ausgleicht.

Fazit: Eine Pipeline ist ein Produkt, kein Projekt¶

Eine DevSecOps-Pipeline ist keine einmalige Implementierung. Sie ist ein internes Produkt, das einen Verantwortlichen, eine Roadmap, eine Feedback-Schleife und kontinuierliche Verbesserung braucht. Regeln ändern sich mit neuen Arten von Schwachstellen. Tools werden aktualisiert. Schwellenwerte werden strenger, wenn das Team reift.

Fangen Sie klein an — Secret-Scanning und SCA in einem Repository. Fügen Sie alle zwei Wochen Schichten hinzu. In zwei Monaten haben Sie eine Pipeline, die 90 % der Schwachstellen abfängt, bevor sie einen Pull Request erreichen. Und noch wichtiger — Entwickler werden Sicherheit als Teil ihres Workflows behandeln, nicht als Hindernis.

Im Jahr 2026 ist die Frage nicht, ob man Sicherheit in CI/CD automatisieren soll. Die Frage ist, wie viele Schwachstellen Sie in die Produktion durchlassen, bevor Sie anfangen. Jeder Tag ohne DevSecOps-Pipeline ist ein Tag, an dem Sie sich auf Glück verlassen statt auf ein System.