DevSecOps

„Shift Left, sie sagten. Es wird einfach, sie sagten."

Sinn & Zweck

DevSecOps ist der Versuch, Security in den DevOps-Prozess zu integrieren, anstatt sie am Ende dranzukleben. Das "Sec" in der Mitte ist symbolisch: Security soll kein Nachgedanke sein, sondern integraler Bestandteil von Entwicklung und Betrieb.

Die traditionelle Vorgehensweise:

Dev ────────→ Ops ────────→ Security ────────→ "Nein."
                                                  ↓
                                           Zurück zu Dev
                                                  ↓
                                           6 Wochen verloren

DevSecOps:

Dev+Sec+Ops ────────────────────────────────→ "Schon gefixed!"
                                                    ↓
                                              Release on time

Prinzipien

1. Shift Left

Security-Aktivitäten so früh wie möglich im Entwicklungsprozess.

Traditionell:
Requirements → Design → Code → Test → Deploy → [SECURITY]

Shift Left:
[SECURITY] → Requirements → Design → Code → Test → Deploy → [SECURITY]

2. Automatisierung

Alles, was automatisiert werden kann, wird automatisiert. Menschen skalieren nicht.

3. Kontinuierliche Security

Security ist kein Gate, sondern ein kontinuierlicher Prozess.

4. Kollaboration

Dev, Sec und Ops arbeiten zusammen, nicht gegeneinander.

5. Kultur vor Tools

Tools allein machen keine Security. Menschen und Prozesse schon.

Die Pipeline – Security überall

┌─────────────────────────────────────────────────────────────────────────────┐
│                           DevSecOps Pipeline                                  │
├───────────┬───────────┬───────────┬───────────┬───────────┬───────────────────┤
│   Plan    │   Code    │   Build   │   Test    │  Deploy   │     Operate      │
├───────────┼───────────┼───────────┼───────────┼───────────┼───────────────────┤
│ Threat    │ IDE       │ SAST      │ DAST      │ IaC       │ SIEM             │
│ Modeling  │ Security  │           │           │ Security  │                  │
│           │ Plugins   │           │           │           │                  │
├───────────┼───────────┼───────────┼───────────┼───────────┼───────────────────┤
│ Security  │ Pre-commit│ SCA       │ Pentest   │ Container │ Runtime          │
│ Backlog   │ Hooks     │           │           │ Scanning  │ Protection       │
├───────────┼───────────┼───────────┼───────────┼───────────┼───────────────────┤
│ Risk      │ Code      │ License   │ IAST      │ Secret    │ Vulnerability    │
│ Assessment│ Review    │ Compliance│           │ Management│ Management       │
└───────────┴───────────┴───────────┴───────────┴───────────┴───────────────────┘

Tools nach Phase

Plan

Threat Modeling: Microsoft TMT, OWASP Threat Dragon
Ticket Management: JIRA (Security Labels), GitHub Issues
Wiki: Confluence mit Security Playbooks

Code (Pre-Commit)

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/zricethezav/gitleaks
    hooks:
      - id: gitleaks
  - repo: https://github.com/PyCQA/bandit
    hooks:
      - id: bandit

IDE Plugins:

SonarLint
Snyk
Checkov
GitGuardian

Build (CI)

# GitHub Actions Security Pipeline
name: Security Checks
on: [push, pull_request]

jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Semgrep
        uses: returntocorp/semgrep-action@v1
  
  sca:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Snyk
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  
  secrets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Gitleaks
        uses: gitleaks/gitleaks-action@v2
  
  container:
    runs-on: ubuntu-latest
    steps:
      - name: Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'myapp:${{ github.sha }}'

Test (CD)

  dast:
    runs-on: ubuntu-latest
    steps:
      - name: OWASP ZAP
        uses: zaproxy/action-baseline@v0.7.0
        with:
          target: 'https://staging.example.com'

Deploy

IaC Security: Checkov, Terrascan, tfsec
Kubernetes: Falco, OPA/Gatekeeper, Kyverno
Secrets: HashiCorp Vault, AWS Secrets Manager

Operate

SIEM: Splunk, Elastic SIEM, Sumo Logic
RASP: Contrast, Sqreen
WAF: AWS WAF, Cloudflare, ModSecurity

Security Gates

Definition

Automatische Checks, die den Build/Deploy blockieren, wenn Security-Kriterien nicht erfüllt sind.

Beispiel-Policy

security_policy:
  sast:
    block_on:
      - critical
      - high
    warn_on:
      - medium
    ignore:
      - low
      
  sca:
    block_on:
      - cvss >= 9.0
      - license: ["GPL-3.0", "AGPL"]
    
  container:
    block_on:
      - critical_vulnerabilities > 0
      
  secrets:
    block_on:
      - any_secret_found: true

Das Dilemma

Strikte Gates = Sichere Software, aber frustrierte Devs
Lockere Gates = Schnelle Releases, aber unsichere Software

Lösung: Risk-based Gating. Kritische Apps brauchen striktere Gates.

Metriken & KPIs

Security-Metriken

Metrik	Beschreibung	Ziel
MTTD	Mean Time to Detect	Minimieren
MTTR	Mean Time to Remediate	< 30 Tage (kritisch)
Vulnerability Density	Vulns per KLOC	Senken
Fix Rate	% gefixte Vulns	> 90%
False Positive Rate	Unnötige Alerts	< 10%
Coverage	% gescannter Repos	100%

Dashboard-Beispiel

┌────────────────────────────────────────────────────────────┐
│                  Security Dashboard                         │
├────────────────────────────────────────────────────────────┤
│ Open Vulnerabilities: 47 (↓ 12 vs. last week)              │
│ ├── Critical: 2 (both > 7 days old ⚠️)                     │
│ ├── High: 8                                                │
│ ├── Medium: 22                                             │
│ └── Low: 15                                                │
├────────────────────────────────────────────────────────────┤
│ MTTR (Critical): 4.2 days  │  SLA: 7 days ✓               │
│ MTTR (High): 18 days       │  SLA: 30 days ✓              │
├────────────────────────────────────────────────────────────┤
│ Scans this week: 1,247                                     │
│ Failed builds (security): 23 (1.8%)                        │
│ Secrets detected: 3 (blocked)                              │
└────────────────────────────────────────────────────────────┘

Risiken & Grenzen

Tool Sprawl

"Wir haben jetzt:
- 3 SAST Tools
- 2 SCA Tools
- 4 Container Scanner
- 2 Secret Scanner
- Und niemand schaut die Dashboards an."

Alert Fatigue

10.000 Findings pro Woche = 0 Findings, die jemand liest.

False Positives

Entwickler verlieren das Vertrauen, wenn 80% der Alerts Fehlalarme sind.

Velocity vs. Security

PM: "Feature muss morgen live!"
Security: "Aber der SAST hat..."
PM: "Morgen. Live."

Skill Gap

DevOps-Engineers sind keine Security-Experten. Security-Experten verstehen kein Kubernetes.

"Not My Job" Mentalität

Dev: "Security kümmert sich drum." Sec: "Ops kümmert sich drum." Ops: "Dev kümmert sich drum." Niemand: kümmert sich drum

Vorteile

Geschwindigkeit

Security ist kein Bottleneck mehr. Automatisierte Checks in Sekunden statt wochenlanger Reviews.

Frühe Erkennung

Bug in IDE gefunden: 10 Minuten Fix
Bug in Production: 10 Tage Fix + Incident + Post-Mortem + Therapie

Konsistenz

Jeder Commit wird gleich geprüft. Keine "Das hat der Senior geschrieben, das passt schon"-Ausnahmen.

Skalierung

Die Pipeline skaliert mit dem Team. 10 Entwickler oder 1000 – dieselben Checks.

Nachvollziehbarkeit

Jeder Build ist dokumentiert. Auditors lieben das.

Kulturwandel

Wenn Security Teil der Pipeline ist, wird sie Teil der Kultur.

Best Practices

1. Start Small

Nicht alles auf einmal. Erst Secret-Scanning, dann SAST, dann...

2. Developer Experience priorisieren

Schlecht: "Build failed. See log for details." (5000 Zeilen)
Gut: "SQL Injection in api/users.py:42. Fix: Use parameterized query."

3. Fix the Process, not the People

Wenn Devs Security umgehen, ist der Prozess schlecht, nicht die Devs.

4. Security Champions

Security-Enthusiasten in jedem Team als Multiplikatoren.

5. Blameless Culture

Fehler passieren. Wichtig ist, dass sie gemeldet und behoben werden.

6. Feedback Loops

Findings müssen actionable sein und schnell beim Entwickler ankommen.

7. Measure & Improve

Was nicht gemessen wird, wird nicht verbessert.

Toolchain-Beispiel (Full Stack)

# Complete DevSecOps Toolchain
source_control:
  - GitHub/GitLab
  - Branch Protection Rules
  - Signed Commits

pre_commit:
  - gitleaks (secrets)
  - pre-commit hooks

ci_pipeline:
  sast:
    - Semgrep
    - SonarQube
  sca:
    - Snyk
    - Dependabot
  container:
    - Trivy
    - Grype
  iac:
    - Checkov
    - tfsec
  secrets:
    - Gitleaks
    - TruffleHog

cd_pipeline:
  dast:
    - OWASP ZAP
  kubernetes:
    - Falco
    - OPA Gatekeeper

runtime:
  waf:
    - AWS WAF
  monitoring:
    - Datadog
    - Splunk
  secrets:
    - HashiCorp Vault

Fazit

DevSecOps ist keine Technologie, sondern eine Kultur. Die Tools sind wichtig, aber ohne die richtige Einstellung der Menschen und Prozesse bleiben sie nutzlos.

Das Ziel ist nicht, Security perfekt zu machen – das ist unmöglich. Das Ziel ist, Security kontinuierlich zu verbessern, automatisiert wo möglich und menschlich wo nötig.

"Security is everyone's job" ist leicht gesagt. DevSecOps ist der Versuch, es wahr zu machen.

Weiterführende Ressourcen: