DevSecOps: Sicherheit in DevOps integrieren

Einführung

DevSecOps ist die Praxis der Integration von Sicherheit in jede Phase des Softwareentwicklungslebenszyklus – von der Planung und Codierung bis hin zu Tests, Bereitstellung und Betrieb. Anstatt Sicherheit als letztes Tor (oder, schlimmer noch, als nachträglicher Einfall) zu betrachten, macht DevSecOps Sicherheit zu einer kontinuierlichen, gemeinsamen Verantwortung aller Entwicklungs-, Betriebs- und Sicherheitsteams.

Die Kernphilosophie ist „Shift Left“ – Beheben Sie Sicherheitsbedenken so früh wie möglich im Entwicklungsprozess, wenn sie am kostengünstigsten und am einfachsten zu beheben sind. Die Behebung einer in der Produktion gefundenen Schwachstelle kostet 100-mal mehr als die Behebung einer Schwachstelle, die während des Entwurfs entdeckt wurde.

---

Die Shift-Left-Philosophie

Kosten für die Behebung von Schwachstellen

Stage         Cost to Fix          Detection
──────────────────────────────────────────────
Design        $1                   Threat modeling, architecture review
Development   $6                   SAST, peer review
Testing       $15                  DAST, penetration testing
Staging       $40                  Integration tests
Production    $100+                Incident response, breach

Quelle: IBM System Science Institute

Sicherheit als Code

So wie DevOps „Infrastruktur als Code“ brachte, bringt DevSecOps „Sicherheit als Code“:

# .sast.yml — Security policies defined in code
version: 1.0
policies:
  sql_injection:
    severity: critical
    action: block_build
  hardcoded_secret:
    severity: high
    action: alert_and_review
  deprecated_api:
    severity: medium
    action: warn

---

Die DevSecOps-Pipeline

Plan → Code → Build → Test → Deploy → Operate
 │      │       │       │       │        │
 ├─ Threat Model
 │      ├─ SAST
 │              ├─ Dependency Scan
 │              ├─ Container Scan
 │                      ├─ DAST
 │                      ├─ IaC Scan
 │                              ├─ Sign
 │                              ├─ Policy Check
 │                                      ├─ Monitoring
 │                                      ├─ SIEM
 │                                      ├─ Incident Response

1. Planungsphase – Bedrohungsmodellierung

Bevor Sie Code schreiben, identifizieren Sie potenzielle Bedrohungen mithilfe von Frameworks wie STRIDE:

Kategorie	Beispiel	Schadensbegrenzung
**Verdammtes Blödsinn	Der Angreifer gibt sich als Benutzer aus	Authentifizierung (MFA, JWT)
Tampering	Angreifer verändert Daten während der Übertragung	TLS, Signieren
**Zurückweisung	Der Benutzer lehnt eine Aktion ab	Audit-Protokollierung
**Offenlegung von Informationen	Datenleck durch Fehlermeldungen	Richtige Fehlerbehandlung
Denial of Service	API mit Anfragen überhäufen	Ratenbegrenzung
**Erhöhung von Privilegien	Der reguläre Benutzer erhält Administratorzugriff	RBAC, Autorisierungsprüfungen

Tool: OWASP Threat Dragon – Open-Source-Tool zur Bedrohungsmodellierung mit STRIDE-Unterstützung.

2. Codephase – Statische Anwendungssicherheitstests (SAST)

SAST analysiert den Quellcode auf Schwachstellen, ohne ihn auszuführen.

// SAST will flag this as SQL injection
app.get('/user', (req, res) => {
  const sql = `SELECT * FROM users WHERE id = '${req.query.id}'`;
  db.query(sql);
});

// Corrected version
app.get('/user', (req, res) => {
  const sql = 'SELECT * FROM users WHERE id = ?';
  db.query(sql, [req.query.id]);
});

SAST-Tools:

Werkzeug	Sprachen	Integration
SonarQube	Über 30 Sprachen	GitHub/GitLab CI, Jenkins
Semgrep	Python, Go, JS, TS, Java usw.	CLI, CI, Pre-Commit
CodeQL	C/C++, C#, Java, JS/TS, Python	Erweiterte GitHub-Sicherheit
Checkmarx	Über 20 Sprachen	Unternehmens-SDLC

CI-Integration:

# GitHub Actions — SAST on every PR
name: SAST
on: [pull_request]
jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: p/default
      - name: Check results
        run: |
          if [ -f semgrep-results.json ]; then
            CRITICAL=$(jq '.results | map(select(.severity=="CRITICAL")) | length' semgrep-results.json)
            if [ "$CRITICAL" -gt 0 ]; then
              echo "❌ $CRITICAL critical vulnerabilities found"
              exit 1
            fi
          fi

3. Build-Phase – Abhängigkeits- und Container-Scanning

Abhängigkeitsscan

Open-Source-Bibliotheken machen 60–80 % der modernen Anwendungen aus. Jede Abhängigkeit ist ein potenzieller Angriffsvektor.

Bemerkenswerte Angriffe auf die Lieferkette:

• Event-Stream (2018) – Schädliches Paket hat Bitcoin aus Wallets gestohlen.
• SolarWinds (2020) – Mehr als 18.000 Organisationen waren von einer Backdoor-Build-Pipeline betroffen.
• Log4j (2021) – Kritischer RCE in weit verbreiteter Protokollierungsbibliothek.
• xz utils (2024) – SSH-Hintertür in der Linux-Komprimierungsbibliothek.

# Dependency scanning with Trivy
$ trivy fs --scanners vuln --severity CRITICAL,HIGH .
Total: 14 (CRITICAL: 3, HIGH: 11)

┌──────────────────────┬──────────────────┬──────────┬───────────────────┐
│ Package              │ Vulnerability ID  │ Severity │ Installed Version │
├──────────────────────┼──────────────────┼──────────┼───────────────────┤
│ lodash               │ CVE-2024-1234     │ CRITICAL │ 4.17.20           │
│ express              │ CVE-2024-5678     │ HIGH     │ 4.18.1            │
└──────────────────────┴──────────────────┴──────────┴───────────────────┘

Abhängigkeitsversionen sperren und Integritäts-Hashes verwenden:

// package-lock.json ensures reproducible builds with hashes
"lodash": {
  "version": "4.17.21",
  "integrity": "sha512-v2kDEe57lecTulaDIuNTPy3Ry4gLGJ6Z1O3vE1krgXZNrsQ+LFTGHVxVjcXPs17LhbZVGedAJv8XZ1tvj5FvSg=="
}

Scannen von Containerbildern

# Bad practice: large base image, runs as root
FROM node:20
COPY . .
RUN npm install
USER root
CMD ["node", "app.js"]

# Good practice: minimal base image, non-root user
FROM node:20-alpine
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
COPY --chown=appuser:appgroup . .
RUN npm ci --production
USER appuser
CMD ["node", "app.js"]

# Scan container image
$ trivy image myapp:latest
┌──────────────────┬──────────────────┬──────────┐
│ Library          │ Vulnerability    │ Severity │
├──────────────────┼──────────────────┼──────────┤
│ libcrypto        │ CVE-2024-9999    │ CRITICAL │
│ bash             │ CVE-2024-8888    │ HIGH     │
└──────────────────┴──────────────────┴──────────┘

Recommendation: Use distroless or scratch base images

4. Testphase – Dynamic Application Security Testing (DAST)

DAST testet die laufende Anwendung auf Schwachstellen:

# OWASP ZAP automated scan
docker run -v $(pwd):/zap/wrk:rw zaproxy/zap-stable \
  zap-cli quick-scan \
  --self-contained \
  --start-options '-config api.addrs.addr.name=.*' \
  http://staging.example.com

# Generate HTML report
zap-cli report -o zap-report.html -f html

DAST-Abdeckung (OWASP Top 10):

• A01: Zugriffskontrolle defekt
• A02: Kryptografische Fehler
• A03: Injektion (SQL, NoSQL, OS-Befehl)
• A04: Unsicheres Design
• A05: Fehlkonfiguration der Sicherheit
• A06: Anfällige Komponenten
• A07: Authentifizierungsfehler
• A08: Datenintegritätsfehler
• A09: Protokollierungs-/Überwachungsfehler
• A10: SSRF

5. Bereitstellungsphase – Richtliniendurchsetzung

Signieren und Verifizieren

# Cosign — sign container images
cosign sign --key cosign.key registry.example.com/myapp:latest

# Verify before deployment
cosign verify --key cosign.pub registry.example.com/myapp:latest

Zulassungscontroller (Kubernetes)

# OPA/Gatekeeper — Deny privileged containers
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sBlockPrivilegedContainers
metadata:
  name: no-privileged-containers
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    enforcementAction: deny
  validation:
    message: "Privileged containers are not allowed"
    deny:
      conditions:
        - key: "spec.containers[].securityContext.privileged"
          operator: In
          values: ["true"]

6. Betriebsphase – Kontinuierliche Überwachung

Sicherheitsinformations- und Ereignismanagement (SIEM)

# Filebeat configuration for shipping logs to ELK
filebeat.inputs:
  - type: container
    paths:
      - /var/log/containers/*.log
output.elasticsearch:
  hosts: ["https://elasticsearch:9200"]
  username: "filebeat"
  password: "${ELASTIC_PASSWORD}"

SIEM-Erkennungsregeln:

# Elastic Security rule: Multiple failed logins
sequence by source.ip
  with maxspan=5m
  [authentication where event.action == "login_failed"] |
  [authentication where event.action == "login_failed"] |
  [authentication where event.action == "login_success"]

Laufzeitschutz

• Falco – Laufzeitsicherheitsüberwachung für Container und Kubernetes.
• AppArmor / SELinux – Obligatorische Zugriffskontrolle unter Linux.
• Seccomp – Beschränken Sie die für Container verfügbaren Systemaufrufe.

# Falco rule: Shell in container
- rule: Terminal shell in container
  desc: A shell was spawned in a container
  condition: container.id != host
    and proc.name in (bash, zsh, sh, ash)
    and spawned_process
  output: "Shell spawned in container (user=%user.name container=%container.id)"
  priority: WARNING

---

DevSecOps-Kultur

Bei DevSecOps geht es sowohl um Kultur und Prozesse als auch um Tools:

Kulturelle Prinzipien

Prinzip	Traditionell	DevSecOps
Wertpapiereigentum	Es gehört dem Sicherheitsteam	Jeder besitzt es
Wenn Sicherheit passiert	Ende der Entwicklung	Durchgehend durchgehend
Wie Feedback abgegeben wird	„Nein“ (Blocker)	„Ja, wenn…“ (Enabler)
Teamstruktur	Separate Silos	Funktionsübergreifend
Automatisierung	Manuelle Sicherheitstore	Automatisierte Sicherheitskontrollen
Geschwindigkeit vs. Sicherheit	Kompromiss (langsam und sicher vs. schnell und unsicher)	Beides – automatisierte Sicherheit ermöglicht Geschwindigkeit

Aufbau eines DevSecOps-Programms

1. Klein anfangen – Fügen Sie SAST und Abhängigkeitsscan zu einer Pipeline hinzu.
2. Wert anzeigen – Verfolgen Sie erkannte Schwachstellen vor der Produktion.
3. Automatisieren, nicht blockieren – Sicherheitsschleusen sollten Feedback geben, keine Blocker.
4. Schulung von Entwicklern – Sicherheitsexperten in jedem Team.
5. Messung – Mittlere Behebungszeit (MTTR), Schwachstellendichte.

Security Champions-Programm

Benennen Sie Sicherheits-Champions innerhalb der Entwicklungsteams:

• Sie fungieren als Vermittler zwischen Sicherheit und Entwicklung.
• Überprüfen Sie die Ergebnisse des Sicherheitstools.
• Führen Sie Peer-Sicherheitsüberprüfungen durch.
• Bleiben Sie über bewährte Sicherheitspraktiken auf dem Laufenden.

---

Zusammenfassung der DevSecOps-Toolchain

Phase	Werkzeugoptionen	Zweck
Bedrohungsmodellierung	OWASP Threat Dragon, Microsoft Threat Modeling Tool	Erkennen Sie Bedrohungen frühzeitig
SAST	SonarQube, Semgrep, CodeQL, Checkmarx	Statische Codeanalyse
Abhängigkeit	Snyk, Dependabot, Trivy, OWASP DC	Open-Source-Schwachstellenmanagement
Container	Trivy, Clair, Docker Scout, Grype	Scannen von Bildern auf Schwachstellen
DAST	OWASP ZAP, Burp Suite, Acunetix	Laufzeit-Schwachstellentests
IaC	Checkov, tfsec, Terrascan, KICS	Erkennung von Fehlkonfigurationen der Infrastruktur
Geheimnisse	GitGuardian, TruffleHog, Gitleaks	Geheimnisse im Code erkennen
Unterzeichnung	Cosign, Sigstore, Notar	Signieren und Verifizieren von Artefakten
Politik	OPA/Gatekeeper, Kyverno, Sentinel	Durchsetzung von Richtlinien
Laufzeit	Falco, AppArmor, Seccomp	Bedrohungserkennung zur Laufzeit
SIEM	ELK, Splunk, Datadog Security, Sentinel	Protokollaggregation und Bedrohungserkennung

---

Abschluss

DevSecOps verwandelt Sicherheit von einem Engpass in einen Wegbereiter. Durch die Integration von Sicherheitsprüfungen in jede Phase des Entwicklungslebenszyklus und deren Automatisierung in CI/CD-Pipelines können Unternehmen:

1. Schwachstellen früher erkennen – wenn ihre Behebung 100-mal günstiger ist.
2. Schneller versenden – Automatisierte Sicherheitsschleusen sind schneller als manuelle Überprüfungen.
3. Risiko reduzieren – Kontinuierliche Sicherheitsüberwachung erkennt, was Menschen übersehen.
4. Sicherheitskultur aufbauen – Sicherheit liegt in der Verantwortung jedes Einzelnen.

Beginnen Sie mit den wirkungsvollsten und reibungsärmsten Tools: SAST und Abhängigkeitsscan. Fügen Sie Container-Scanning, DAST- und IaC-Scanning schrittweise hinzu. Messen Sie den Fortschritt, feiern Sie Erfolge und wiederholen Sie den Vorgang.