DevSecOps – Mittendrin statt nur dabei

Wir erinnern uns: Mit dem Vortrag „10+ Deploys per Day: Dev and Ops Cooperation“ hat Flickr 2009 ein großes Umdenken bei den Entwicklungsprozessen angestoßen.

Zu diesem Zeitpunkt waren Entwicklung und Operations strikt getrennt und den Betriebsteams wurde am Ende des Entwicklungsprozesses ein „fertiges“ Produkt zum Betrieb übergeben. Fehler, die sich erst im Betrieb manifestieren, wurden an das Entwicklungsteam gemeldet, das diese dann – außerhalb der Betriebsumgebung – gefixt hat.

Diese zeitaufwändige Methodologie hat sich gerade im Bereich der Web-Anwendungsentwicklung als Flaschenhals und Innovationskiller erwiesen. Mit DevOps sollen Entwickler und Betrieb nun im gleichen Boot sitzen und Updates in kleineren Einheiten und viel, viel kürzeren Zyklen in die produktive Umgebung übernehmen („deployen“).

Dazu werden viele Aufgaben weitestgehend automatisiert und permanent („continous“) im Hintergrund ausgeführt. Fehler werden somit früher erkannt und adressiert. Der gesamte Prozess von der Entwicklung bis zum Betrieb soll wortwörtlich „agiler“ und damit schneller werden.

Laut der „Trendstudie DevOps 2017“ nutzen in Deutschland erst etwas mehr als die Hälfe der Unternehmen DevOps und sie stehen dabei in vielen Fällen noch auf der ersten Stufe, der eigentlichen Implementierung von DevOps.

Im SAP-Umfeld, das traditionell noch viel stärker segmentiert ist (OS/Datacenter, DB, Basis, Anwendung), liegt diese Zahl vermutlich noch deutlich darunter. Immerhin gelten bei unternehmenskritischen Anwendungen „Never touch a running system“-Devisen sehr viel stärker als bei anderen Web-Anwendungen.

Auch lassen sich viele der Konzepte von DevOps, z. B. kontinuierliche Integration und automatisierte Unit-Tests, nur schwer in traditionelle SAP-Entwicklungsprozesse integrieren. Somit ist DevOps – noch bevor es wirklich im SAP-Umfeld angekommen ist – schon wieder überholt oder vielmehr ergänzt worden.

Denn wenn Security ein Kriterium für den Betrieb von Anwendungen wird und genauso wie zuvor funktionale Defekte das Potenzial hat, die Ergebnisse des agilen DevOps-Prozesses zurück ans Reißbrett zu schicken, dann sollte auch Security früh in den Entwicklungsprozess eingebunden werden.

Genau diesen Ansatz verfolgt DevSecOps. Security-Experten sollen nicht erst damit betraut werden, das fertige Produkt quasi „von außen“ abzusichern, sondern die Lücken, die beim Betrieb zu Sicherheitsproblemen werden können, bereits „Upstream“, also früh im Software Development Lifecycle erkennen und – idealerweise durch besseren, sichereren Code – verhindern.

Selbst wenn sich manche DevOps-Konzepte nicht eins zu eins auf SAP-Entwicklung übertragen lassen, bleibt es eine Tatsache, dass sich viele der „Critical“ oder gar „Hot News“ Security Notes der letzten Jahre durch die konsequente Einbindung von Security in den Entwicklungsprozess hätten vermeiden lassen können. Selbiges gilt natürlich für die durchschnittlich zwei Millionen Zeilen Custom Code, die es in produktiven SAP-Systemen gibt.

Tools, die viele der agilen DevSecOps-Ansätze erst möglich machen, gibt es im SAP-Bereich zahlreich: von exzellent integrierten Werkzeugen zur statischen Code-Analyse, Static Code Security Testing (SAST) bis zur Testautomatisierung von Packaged Solutions.

Solche Tools und die kontinuierliche Kooperation und kombinierte Brainpower von SAP-Entwicklern, Security-Experten und Operations-Teams führen zwangsläufig zur Vermeidung vieler offensichtlicher Security-Patzer in Custom Code. Security wird in den Code eingebaut statt von außen vorgelagert.

In Anbetracht der durchschnittlichen Kosten eines SAP-Security-Vorfalls, die laut einer Studie des Ponemon-Institutes bei 4,5 Millionen US-Dollar liegen, sollte also seitens der Unternehmen die Motivation hoch sein, DevSecOps-Konzepte auch auf die SAP-Anwendungsentwicklung anzuwenden.

Vielleicht mangelt es aber nur am passenden Buzzword? In diesem Fall werfe ich gerne DevSecSAPOps in den Ring.