DevSecOps: Sicherheit in Pipelines nach links verlagern

Security nach links zu verschieben bedeutet, Sicherheitsaktivitäten früher im Softwareentwicklungslebenszyklus zu integrieren – in der IDE der Entwickler, bei Code-Reviews und in der CI/CD-Pipeline –, statt die Sicherheit erst als letzte Hürde vor dem Deployment zu prüfen. Traditionelle Sicherheitsprüfungen fanden am Ende des Entwicklungszyklus statt, wodurch die Behebung teuer und zeitaufwendig wurde. Das Erkennen einer Schwachstelle während der Entwicklung kostet für ihre Behebung ungefähr 100-mal weniger, als wenn sie erst nach einem Sicherheitsvorfall in der Produktion entdeckt wird.

DevSecOps erweitert das DevOps-Modell, indem Sicherheit während des gesamten SDLC als gemeinsame Verantwortung von Entwicklungs-, Betriebs- und Sicherheitsteams integriert wird. Ziel ist es, Sicherheitstests zu automatisieren, sodass sie in jeder Phase ausgeführt werden, ohne die Bereitstellung zu verlangsamen. Sicherheit wird dadurch zu einer kontinuierlichen Eigenschaft der Pipeline statt zu einer einmaligen Prüfstufe. In ausgereiften DevSecOps-Programmen erhalten Entwickler innerhalb von Sekunden nach dem Schreiben von Code Sicherheitsfeedback und nicht erst Wochen später nach einer manuellen Prüfung.

SAST (Static Application Security Testing) analysiert Quellcode, Bytecode oder Binärdateien, ohne die Anwendung auszuführen. SAST-Tools suchen nach Mustern, die auf Schwachstellen hinweisen: SQL-Konkatenation, nicht bereinigte Ausgaben, die Verwendung gesperrter Funktionen, fest codierte Zugangsdaten und unsichere kryptografische Verfahren. SAST wird in der CI-Pipeline bei jedem Commit ausgeführt und erkennt Probleme, bevor sie die Qualitätssicherung oder die Produktion erreichen. Zu den verbreiteten Tools gehören Semgrep, SonarQube, Checkmarx und Veracode.

DAST (Dynamic Application Security Testing) testet eine laufende Anwendung, indem schädliche Payloads gesendet und die Antworten beobachtet werden – dabei wird das Verhalten echter Angreifer simuliert. Im Gegensatz zu SAST findet DAST Schwachstellen, die erst zur Laufzeit auftreten: Fehler bei der Authentifizierung, Probleme bei der Sitzungsverwaltung, Fehler in der Geschäftslogik und Injection-Schwachstellen in komplexen Datenflüssen. Zu den verbreiteten DAST-Tools gehören OWASP ZAP (kostenlos), Burp Suite Enterprise und Acunetix. DAST wird in der Pipeline gegen eine Staging-Umgebung ausgeführt.

Container-Images werden aus Basis-Images erstellt, die Betriebssystempakete, Sprachlaufzeiten und Anwendungsabhängigkeiten enthalten – alles potenzielle Quellen bekannter Schwachstellen. Tools zum Scannen von Container-Images analysieren die Image-Layer und identifizieren verwundbare Pakete. Trivy (kostenlos und schnell), Grype (Anchore) und Clair werden häufig eingesetzt. Die Scans werden als Teil der Image-Build-Pipeline ausgeführt und verhindern, dass Images mit kritischen CVEs in die Produktions-Registries übertragen werden.

IaC-Sicherheits-Scanning analysiert Terraform, CloudFormation, Kubernetes-Manifeste und Helm-Charts auf unsichere Fehlkonfigurationen, bevor sie angewendet werden. Tools wie Checkov und tfsec prüfen beispielsweise auf Verstöße wie: S3-Buckets ohne serverseitige Verschlüsselung, Security Groups, die sämtlichen eingehenden Datenverkehr zulassen, IAM-Rollen mit Wildcard-Berechtigungen und Kubernetes-Pods, die als Root ausgeführt werden. IaC-Scanning verhindert Fehlkonfigurationen der Cloud, bevor sie eine Umgebung erreichen.

Secret-Scanning-Tools prüfen Quellcode und Commits auf versehentlich enthaltene Zugangsdaten. Tools wie truffleHog, GitLeaks und detect-secrets durchsuchen die Git-Historie und neue Commits nach Mustern, die API-Schlüsseln, Verbindungszeichenfolgen, privaten Schlüsseln und JWT-Tokens entsprechen. Als Pre-Commit-Hook verhindert Secret-Scanning Commits, die Zugangsdaten enthalten. Als CI-Gate scannt es bei jedem Push alle Dateien im Repository und lässt den Build fehlschlagen, wenn Secrets erkannt werden.

Threat Modeling ist ein strukturierter Prozess, um Sicherheitsanforderungen und Entwurfsfehler zu identifizieren, bevor Code geschrieben wird. Das STRIDE-Modell (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) hilft Teams, Bedrohungen für das Datenflussdiagramm eines Systems systematisch zu erfassen. Threat-Modeling-Sitzungen finden während des Entwurfs statt. Dabei entsteht eine priorisierte Liste von Bedrohungen, die Sicherheitsanforderungen festlegt und die Auswahl von SAST-/DAST-Regeln beeinflusst.

DevSecOps-Pipelines implementieren Sicherheitsprüfungen entweder als blockierende Gates (der Build schlägt fehl, die Bereitstellung wird verhindert) oder als beratende Prüfungen (Befunde werden gemeldet, die Bereitstellung kann fortgesetzt werden). Befunde mit kritischem und hohem Schweregrad aus SAST, Container-Scanning und Secret-Erkennung blockieren typischerweise den Prozess. Befunde mit mittlerem und niedrigem Schweregrad erzeugen Benachrichtigungen oder Tickets, ohne den Prozess zu blockieren. Dieses Gleichgewicht verhindert, dass Sicherheit die gesamte Bereitstellung stoppt, und stellt zugleich sicher, dass wirklich gefährliche Zustände nicht automatisch die Produktion erreichen.

DevSecOps-Programme sollten anhand klarer Metriken gemessen werden. Zu den wichtigsten Metriken gehören: die Mean Time to Remediate (MTTR) für Befunde mit hohem Schweregrad, die Schwachstellendichte (Befunde pro 1.000 Codezeilen im Zeitverlauf), die Escape-Rate (Prozentsatz der nach dem Produktionsstart statt vor dem Produktionsstart gefundenen Schwachstellen) und die Erfolgsquote der Sicherheits-Gates in der Pipeline. Die Entwicklung dieser Metriken im Zeitverlauf zeigt die Wirksamkeit des Programms und unterstützt Investitionsentscheidungen für zusätzliche Tools oder Schulungen.

Der schwierigste Teil von DevSecOps ist kultureller und nicht technischer Natur. Sicherheit muss zur Verantwortung jedes Entwicklers werden und darf nicht nur Aufgabe des Sicherheitsteams sein. Dafür sind erforderlich: Sicherheitsschulungen für Entwickler (Bewusstsein für sicheres Programmieren), in Entwicklungsteams integrierte Security Champions, blameless Post-Mortems, wenn Schwachstellen die Produktion erreichen (Fokus auf Prozessverbesserung statt Bestrafung), sowie die Unterstützung durch die Führungsebene, bei echtem Sicherheitsrisiko Kompromisse bei der Bereitstellungsgeschwindigkeit zuzulassen. Technologie ohne kulturellen Wandel führt zu Scanning-Tools, die Entwickler irgendwann ignorieren.

Testen Sie Ihr Verständnis der Konzepte aus CompTIA Security+ (SY0-701) in dieser Lektion.

In dieser Lektion haben Sie gelernt: DevSecOps integriert SAST, DAST, Secret-Scanning, Container-Scanning und IaC-Scanning als automatisierte Pipeline-Gates; das Blockieren von Befunden mit hohem Schweregrad verhindert, dass gefährliche Zustände die Produktion erreichen; und das frühzeitige Einbinden von Sicherheit senkt die Behebungskosten drastisch, da Schwachstellen während der Entwicklung statt erst nach der Bereitstellung erkannt werden. Als Nächstes beschäftigen wir uns mit physischen Sicherheitskontrollen für Gebäude und Rechenzentren.