Begriff
DevSecOps
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Früher:
- Entwickler (Dev) bauen Software.
- Admins (Ops) installieren sie.
- Ganz am Ende kommt der Sicherheitsbeauftragte (Sec) und sagt: "Halt, alles unsicher. Neu machen!" (Alle sind genervt).
DevSecOps integriert Sicherheit von Anfang an. Sicherheit ist nicht mehr der Bremser am Ende, sondern Teil des täglichen Bau-Prozesses. Jeder Entwickler ist ein bisschen Sicherheits-Experte. Das Mantra: "Security is everyone's responsibility."
Merksatz: Die Erweiterung von DevOps um Sicherheitsaspekte, wobei Sicherheit als geteilte Verantwortung bereits im Entwicklungsprozess integriert wird.
Automatisierung ist der Schlüssel. In deine CI/CD-Pipeline (Jenkins/GitLab) baust du Scanner ein:
- SAST (Static Analysis): Prüft den Code bevor er läuft ("Passwort im Klartext gefunden!").
- SCA (Software Composition Analysis): Prüft deine Bibliotheken ("Du nutzt eine alte Version von Log4j, die gehackt werden kann!"). Wenn der Scanner meckert, stoppt der Build. Das Problem kommt gar nicht erst in Produktion.
1. Shift Left
Das Kern-Prinzip. Im Zeitstrahl (Links: Planung -> Rechts: Release) schiebt man die Sicherheit nach Links. Je früher man einen Bug findet, desto billiger ist er (Faktor 100). Ein Design-Fehler in der Planung kostet 1 Stunde. Nach dem Release kostet er Millionen (Datenleck).
2. Policy as Code
Sicherheitsregeln werden programmiert.
Statt einer PDF-Richtlinie ("Keine offenen Ports!") schreibt man einen Test:
expect(server.port).to_be_closed().
Wenn jemand aus Versehen den Port öffnet, schlägt der Test fehl.
1. SBOMs und Vulnerability Exploitability eXchange (VEX)
In modernen Clouds ist das Inkludieren von Open Source Libraries das Haupteinfallstor (Supply Chain Attacks). Der US-Executive Order von 2021 hat Software Bill of Materials (SBOM) quasi verpflichtend gemacht. Tools generieren im Build-Prozess ein standardisiertes Manifest (CycloneDX, SPDX), das den exakten Dependency-Baum bis ins letzte Transitiv-Level dokumentiert. Da SCA-Scanner oft >500 False Positives ausspucken ("Diese Node_module hat eine CVE"), etabliert sich VEX. Ein VEX-Dokument ist eine maschinenlesbare Assertion des Dev-Teams: "Ja, Paket X ist verwundbar, aber wir rufen die verwundbare Funktion Y niemals auf (Not Affected)". Dies drückt die Alarm-Fatigue der Ops-Teams drastisch.
2. DAST vs. IAST (Interactive Application Security Testing)
SAST analysiert toten Code, DAST (Dynamic Analysis) greift blind eine laufende App über HTTP an. IAST ist die High-Tech-Evolution beider Welten. Das Tool wird als Agent oder Instrumentation Instrument (Java Agent, Node-Loader) tief im Speicher der laufenden Applikation verankert. Klickt nun eine QA-Testsuite (oder ein normaler User) durch die App, analysiert der IAST-Agent jeden Datenfluss: "Der String aus dem Input-Feld lief exakt durch Controller X, wurde nicht in Service Y escaped und landete nackt im SQL-Statement Z". Es liefert Stack-Traces an den Entwickler, ohne dass Raten von DAST notwendig ist, gepaart mit null False-Positives von SAST.
3. Security Chaos Engineering & eBPF
Shift-Left reicht nicht aus, wenn Netzwerkfehlkonfigurationen auftreten. Der DevSecOps "Right-Guard" nutzt Runtime-Tools (wie Falco/Cilium) via eBPF. Parallel simulieren Security-Teams absichtlich Einbrüche (Purple Teaming). Über Continuous Security Validation werfen Container kleine Malware-Dummies ins Kubernetes, die via Reverse-Shells raustelefonieren wollen. Erkennt die CI/CD Pipeline nicht augenblicklich im SIEM Dashboard das "Blocked" Flag, wird der Build auf rot geschaltet, weil die Runtime-Abwehr (Isolation) fehlschlug. Das testet nicht den Code, sondern die Resilienz der Architektur.
Quick-Check
Brauche ich noch Pentester?
Ja. Automatisierte Tools finden 80% der Fehler (die einfachen). Für die komplexen Logik-Fehler brauchst du immer noch menschliche Hacker (White Hats).Verlangsamt das nicht alles?
Am Anfang ja. Aber langfristig wirst du schneller, weil du nicht mehr kurz vor Release alles stoppen und reparieren musst ("Hotfix-Feuerwehr").Ist es nur ein Buzzword?
Ein bisschen. Eigentlich sollte "DevOps" schon immer Sicherheit beinhalten. Aber weil es oft vergessen wurde, hat man das "Sec" explizit in den Namen geschoben.