Grundlagen
Der DevSecOps Workflow
6 Phasen von Code-Commit bis Production – Security an jedem Schritt.
Was ist ein DevSecOps Workflow?
Ein DevSecOps Workflow beschreibt, wie Security-Prüfungen in den gesamten Software-Entwicklungsprozess integriert sind – von der ersten Idee bis zum laufenden Betrieb.
Im Unterschied zu klassischen Ansätzen, bei denen Security einmalig am Ende geprüft wird, ist Security im DevSecOps Workflow ein dauerhafter Bestandteil jedes Schrittes. Das Ergebnis: Probleme werden früher gefunden, schneller behoben und teuren Nachbesserungen vorgebeugt.
Die 6 Phasen des DevSecOps Workflows
Phase 1: Plan & Design
Sicherheit beginnt vor dem ersten Commit. In der Planungsphase werden Threat Models erstellt: Welche Angriffsvektoren gibt es? Was muss besonders geschützt werden?
Security-Aktivitäten in dieser Phase:
- Threat Modeling (STRIDE, PASTA)
- Security Requirements definieren
- Compliance-Anforderungen klären (NIS2, DSGVO, BSI)
Phase 2: Code
Entwickler schreiben Code – und bekommen direkt im Editor oder bei jedem Commit automatisches Sicherheitsfeedback.
- Pre-Commit Hooks – Secret Detection läuft bevor Code gepusht wird
- SAST – Static Application Security Testing analysiert Code-Muster auf Schwachstellen
- Linting mit Security-Regeln – z.B. keine SQL-Concatenation, kein eval()
Praxisbeispiel: Ein Entwickler committed versehentlich einen AWS-API-Key. Ein Secret-Detection-Hook in der Pipeline schlägt sofort an – bevor der Code das Repository erreicht.
Phase 3: Build
Wenn Code in die CI-Pipeline kommt, starten automatisiert weitere Prüfungen.
- Dependency Scanning – bekannte CVEs in genutzten Libraries werden gemeldet
- SBOM-Generierung – Software Bill of Materials für Audit-Nachweise
- Container Scanning – Docker-Base-Images auf Sicherheitslücken prüfen
Phase 4: Test
Neben funktionalen Tests laufen Security-spezifische Tests gegen die laufende Anwendung.
- DAST – Dynamic Application Security Testing: Angriffe gegen die laufende App simulieren
- API Security Testing – Endpunkte auf Authentifizierung, Rate Limiting, Injection prüfen
- Compliance Checks – Policy-as-Code (z.B. OPA, Kyverno) überprüft Infrastruktur-Konfiguration
Phase 5: Release & Deploy
Bevor Software in Produktion geht, werden letzte Security-Gates durchlaufen.
- Artefakt-Signierung – nur signierte und verifizierte Images gelangen in Prod
- Deployment Policies – Infrastructure as Code wird auf Compliance geprüft
- Approval Workflows – bei kritischen Änderungen greift ein Review-Gate
Phase 6: Operate & Monitor
Nach dem Deployment hört DevSecOps nicht auf. In der Produktion läuft kontinuierliches Monitoring.
- Runtime Security – z.B. Falco überwacht ungewöhnliches Verhalten in Containern
- SIEM-Integration – Logs werden zentral gesammelt und auf Anomalien analysiert
- Vulnerability Management – neue CVEs werden laufend gegen die Produktion geprüft
Security Gates: Die Qualitätsschranken im Workflow
Ein wichtiges Konzept im DevSecOps Workflow sind Security Gates – definierte Haltepunkte, bei denen die Pipeline stoppt, wenn Sicherheitskriterien nicht erfüllt sind.
Beispiele:
- Pipeline bricht ab, wenn SAST eine Schwachstelle mit Severity "Critical" findet
- Deployment in Prod ist gesperrt, wenn Dependency Scanner eine CVSS ≥ 9.0 Lücke meldet
- Container-Image wird nicht deployed, wenn es keine gültige Signatur hat
Gates klingen nach Bürokratie – sind aber das Gegenteil davon. Sie machen Sicherheitsentscheidungen automatisch, konsistent und nachvollziehbar.
Werkzeuge im DevSecOps Workflow
Der Workflow ist tool-agnostisch. Je nach CI/CD-System und Stack passen verschiedene Werkzeuge:
| Phase | Open Source | Commercial |
|---|---|---|
| SAST | Semgrep, Bandit, SpotBugs | Checkmarx, Veracode |
| Dependency Scan | OWASP Dependency-Check, Trivy | Snyk, JFrog Xray |
| Container Scan | Trivy, Grype, Clair | Prisma Cloud, Anchore |
| Secret Detection | Gitleaks, truffleHog | GitGuardian |
| DAST | OWASP ZAP, Nuclei | Burp Suite Enterprise |
| Policy-as-Code | OPA, Kyverno | Styra DAS |
Wie fängt man an?
Der häufigste Fehler: alles auf einmal implementieren wollen. Ein realistischer Einstieg in drei Schritten:
- Secret Detection in die bestehende CI-Pipeline einbauen (Gitleaks läuft in Minuten)
- Dependency Scanning hinzufügen – Trivy oder Snyk sind in jede Pipeline integrierbar
- SAST für die wichtigste Sprache konfigurieren und auf "warn only" stellen – erstmal verstehen, dann enforzen
Von dort aus baut man schrittweise auf – Phase für Phase, Tool für Tool.
Den Workflow in die eigene Pipeline bringen
Theorie ist gut. Aber der echte Unterschied entsteht, wenn du das in deiner eigenen Pipeline umsetzt – mit Begleitung, Labs und direktem Feedback.