DevSecOps vs. DevOps: Wo Security ins Spiel kommt

DevOps hat die Art verändert, wie Teams Software bauen und ausliefern. Continuous Integration, automatisierte Deployments, Infrastructure as Code sind alles Standard in modernen Engineering-Teams. Was in vielen Pipelines aber immer noch fehlt, ist Security als fester Bestandteil des Prozesses, nicht als nachgelagerter Checkpoint. Genau hier setzt DevSecOps an.

Was DevOps gut macht und wo es aufhört

DevOps bringt Entwicklung und Betrieb zusammen. Automatisierte Pipelines sorgen dafür, dass Code schnell und zuverlässig in Produktion landet. Das Ergebnis: kürzere Release-Zyklen, weniger manuelle Fehler, bessere Zusammenarbeit zwischen Teams.

Das Problem liegt darin, dass in vielen Organisationen Security parallel läuft. Es ist ein separater Prozess, der erst kurz vor dem Release oder sogar danach greift. Ein Penetration Test zwei Wochen vor Go-Live, ein Security Review als Bottleneck im Sprint. Das erzeugt Reibung, Verzögerungen und im schlimmsten Fall ein falsches Sicherheitsgefühl.

Typische Symptome:

• Vulnerabilities werden erst in Produktion entdeckt
• Security-Reviews blockieren Releases um Tage oder Wochen
• Entwickler sehen Security als “Problem des anderen Teams”
• Dependency-Updates passieren reaktiv statt proaktiv

DevSecOps: Security als Teil der Pipeline

DevSecOps ist kein neues Framework und kein zusätzliches Tool. Es ist die konsequente Erweiterung von DevOps um Security. Diese ist integriert in jeden Schritt der Pipeline, nicht angehängt am Ende.

Der Kerngedanke ist Shift Left. Sicherheitsprüfungen werden so früh wie möglich in den Entwicklungsprozess verschoben. Statt am Ende zu testen, ob die Anwendung sicher ist, wird in jeder Phase automatisiert geprüft.

DevOps:     Plan → Code → Build → Test → Deploy → Monitor
DevSecOps:  Plan → Code+SAST → Build+SCA → Test+DAST → Deploy+Compliance → Monitor+Threat Detection

Der Unterschied liegt nicht in zusätzlichen Phasen, sondern in der Integration von Security-Checks in bestehende Schritte.

Die vier Säulen von DevSecOps in der Praxis

Static Application Security Testing (SAST)

SAST-Tools analysieren den Quellcode, bevor er überhaupt kompiliert oder ausgeführt wird. Das passiert idealerweise schon im Merge Request, bevor der Code im Hauptbranch landet.

# GitLab CI: SAST-Stage mit Semgrep
sast:
  stage: test
  image: returntocorp/semgrep
  script:
    - semgrep scan --config auto --json --output semgrep-results.json src/
  artifacts:
    reports:
      sast: semgrep-results.json
  rules:
    - if: $CI_MERGE_REQUEST_ID

Semgrep ist hier ein guter Einstieg: Open Source, schnell, und die Regelsets lassen sich an die eigene Codebasis anpassen. Alternativen wie SonarQube bieten breitere Abdeckung, bringen aber mehr Setup-Aufwand mit.

Software Composition Analysis (SCA)

Die meisten Anwendungen bestehen zu 70–90 % aus Third-Party-Dependencies. SCA-Tools prüfen diese Abhängigkeiten auf bekannte Schwachstellen (CVEs) und Lizenzprobleme.

# GitLab CI: Dependency Scanning mit Trivy
dependency_scan:
  stage: test
  image: aquasec/trivy:latest
  script:
    - trivy fs --scanners vuln --format json --output trivy-deps.json .
  artifacts:
    reports:
      dependency_scanning: trivy-deps.json
  allow_failure: false

Wichtig: allow_failure: false bedeutet, dass ein kritischer CVE den Build tatsächlich stoppt. Das ist anfangs unbequem, aber genau das ist der Punkt. Security-Findings dürfen nicht ignorierbar sein.

Dynamic Application Security Testing (DAST)

DAST-Tools testen die laufende Anwendung von außen, ähnlich einem automatisierten Penetration Test. Das passiert typischerweise in einer Staging-Umgebung nach dem Deployment.

# GitLab CI: DAST mit OWASP ZAP
dast:
  stage: dast
  image: ghcr.io/zaproxy/zaproxy:stable
  script:
    - zap-baseline.py -t $STAGING_URL -r zap-report.html -J zap-report.json
  artifacts:
    paths:
      - zap-report.html
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

OWASP ZAP im Baseline-Modus ist ein realistischer Einstieg. Der Full Scan dauert deutlich länger und eignet sich eher für wöchentliche Scheduled Pipelines als für jeden Commit.

Container und Infrastructure Security

Wer Container einsetzt, muss auch Container-Images scannen. Unpatched Base Images sind eine der häufigsten Angriffsvektoren in Kubernetes-Umgebungen.

# GitLab CI: Container Image Scanning
container_scan:
  stage: test
  image: aquasec/trivy:latest
  script:
    - trivy image --severity HIGH,CRITICAL --format json
        --output trivy-image.json $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  artifacts:
    reports:
      container_scanning: trivy-image.json

Trivy deckt hier sowohl OS-Packages als auch Application-Dependencies im Image ab. In Kombination mit einem Admission Controller in Kubernetes (z. B. Kyverno oder OPA Gatekeeper) lässt sich verhindern, dass ungescannte Images überhaupt deployed werden.

Was sich im Team ändert

DevSecOps ist nicht nur ein Pipeline-Thema. Es verändert, wie Teams arbeiten und wer wofür verantwortlich ist.

Shared Responsibility bedeutet, dass Security nicht mehr die alleinige Aufgabe eines dedizierten Security-Teams ist. Jeder Entwickler trägt Verantwortung für die Sicherheit des eigenen Codes. Das bedeutet nicht, dass alle Security-Experten werden müssen, aber ein Grundverständnis für OWASP Top 10, sichere Defaults und Dependency-Management gehört dazu.

Security Champions ist ein bewährtes Modell. Hier werden Entwickler als Champions definiert, die sich besonders für Security interessieren und als Ansprechpartner im Team fungieren. Das ist kein neuer Titel und keine neue Rolle, sondern eine zusätzliche Perspektive.

Guardrails statt Gates: Statt Security-Reviews als Blocker einzusetzen, setzen reife DevSecOps-Teams auf automatisierte Guardrails. Die Pipeline stoppt bei kritischen Findings automatisch. Alles andere wird als Warning geloggt und im nächsten Sprint adressiert.

Wann lohnt sich der Umstieg?

Nicht jedes Team braucht von Tag eins eine vollausgebaute DevSecOps-Pipeline. Aber der Einstieg lohnt sich früher, als viele denken:

Dependency Scanning (SCA) und Secret Detection lohnen sich sofort. Beides lässt sich in unter einer Stunde in jede CI/CD-Pipeline integrieren und deckt die häufigsten Schwachstellen ab.

Als nächstes kommt SAST im Merge Request. Semgrep oder SonarQube als Quality Gate. Findings müssen gefixt werden, bevor Code gemerged wird.

Mittelfristig: DAST in der Staging-Umgebung, Container Image Scanning, und ein Admission Controller in Kubernetes.

Langfristig: Threat Modeling als Teil des Feature-Plannings, Security Scorecards pro Service, und automatisierte Compliance-Checks gegen Standards wie ISO 27001 oder BSI Grundschutz.

Secret Detection: der Quick Win

Ein Punkt, der in keiner Pipeline fehlen sollte, ist die automatische Erkennung von Secrets im Code. API-Keys, Passwörter und Private Keys landen häufiger im Repository, als man denkt.

# GitLab CI: Secret Detection mit gitleaks
secret_detection:
  stage: test
  image: zricethezav/gitleaks:latest
  script:
    - gitleaks detect --source . --report-format json
        --report-path gitleaks-report.json
  artifacts:
    reports:
      secret_detection: gitleaks-report.json
  rules:
    - if: $CI_MERGE_REQUEST_ID

Gitleaks prüft nicht nur den aktuellen Stand, sondern kann auch die Git-Historie durchsuchen. Erfahrungsgemäß der Check mit dem besten Aufwand-Nutzen-Verhältnis. Wer Supply-Chain-Risiken ernst nimmt, sollte auch aktuelle Vorfälle wie den Trivy-npm-Angriff im Blick behalten — und überlegen, ob die Architektur (Monolith oder Microservices) zur eigenen Sicherheits- und Deployment-Strategie passt.

Fazit

DevSecOps ersetzt DevOps nicht, es erweitert es um die Dimension, die in vielen Pipelines fehlt. Der Einstieg muss nicht komplex sein: Dependency Scanning und Secret Detection in die bestehende CI/CD-Pipeline integrieren, das Team für die OWASP Top 10 sensibilisieren, und Security-Findings als echte Blocker behandeln. Der Rest wächst organisch. Wer heute mit Shift-Left anfängt, spart sich morgen den Penetration-Test-Marathon vor dem Release. Und das Team lernt, Security nicht als Bremse zu sehen, sondern als Teil der Engineering-Kultur.

Wir unterstützen Teams beim Aufbau sicherer CI/CD-Pipelines und DevSecOps-Prozesse. Jetzt Beratungsgespräch vereinbaren →

Häufige Fragen

Welche Security-Tools sind am wichtigsten?

Dependency Scanning (SCA) und Secret Detection geben das beste Aufwand-Nutzen-Verhältnis. Sie kosten unter einer Stunde Setupzeit und decken die häufigsten Schwachstellen ab. SAST und DAST folgen danach, Container Image Scanning für wer mit Docker arbeitet.

Wie lange braucht ein Security-Scan?

SAST-Scans sind schnell: zwei bis fünf Minuten. Dependency Scanning ähnlich. DAST-Baseline dauert zehn bis 20 Minuten. Full DAST kann eine Stunde brauchen und läuft besser als wöchentlich geplanter Scan, nicht in jeder Pipeline.

Was macht man mit Security-Findings?

Critical und High-Findings sollten Builds sofort stoppen. Medium-Findings werden im nächsten Sprint gefixt. Low-Findings können als Backlog-Items landen. Wichtig: Findings müssen adressiert werden, nicht ignorierbar sein.

Wie viel kostet DevSecOps-Infrastruktur?

Open-Source-Tools wie Semgrep, Trivy und Gitleaks sind kostenlos. SonarQube Community ist kostenlos, Enterprise-Version bezahlt. OWASP ZAP ist kostenlos. Kosten entstehen eher durch Setups- und Adminisatration, nicht Lizenzierung.