Illustration: Absmeier, Pixabay

Wenn man DevSecOps erklären will, beginnt man am besten mit der Definition von DevOps. DevOps kombiniert Praktiken aus der Softwareentwicklung und dem IT-Betrieb. Um es an einem einfachen Beispiel zu illustrieren: Developer brauchen Umgebungen, in denen sie Software entwickeln können. Dazu zählen solche, in denen sie Code programmieren und zu den Repositories hinzufügen, CI/CD-Plattformen, die den eingereichten Code in Anwendungen umsetzen, bis hin zu Servern, auf denen die Anwendungen zunächst getestet werden. Anschließend gehen sie in die Produktion, wo sie ausgeführt und von Kunden genutzt werden.

Entwickler selbst sind aber nicht diejenigen, die diese Umgebungen vorbereiten oder warten. Man braucht ein IT-Team mit dem nötigen Wissen um die betrieblichen Abläufe, um den Entwicklungsprozess mit der passenden Umgebung zu unterstützen. Man könnte annehmen mit DevOps ist gemeint, dass Entwicklungsteams und IT-Mitarbeiter jeweils das tun, was sie am besten können. Ganz so einfach ist es aber nicht. DevOps basiert auf der Prämisse, dass beide Seiten zusammenarbeiten – mehr noch: die Bedürfnisse der jeweils anderen Gruppe verstehen, um auf ein gemeinsames Ziel hinzuarbeiten. Nämlich einen hochgradig agilen Softwareentwicklungsprozess zu initiieren, einen kontinuierlich sich wiederholenden Zyklus aus Planung, Coding, Erstellung, Test, Freigabe, Bereitstellung, Betrieb und Überwachung.

Wann DevOps funktioniert und wann nicht

Die Herausforderung besteht darin, dass Menschen, Prozesse und Technologien harmonisch in einer funktionierenden Einheit zusammenspielen müssen, um die geforderte Agilität zu erzielen. Die Praxis sieht oft anders aus. Sei es, weil sich die zugewiesenen Budgets der beiden Abteilungen oder Teams unterscheiden. Sei es, dass die Ziele nicht deckungsgleich sind, so dass es den Beteiligten schwerfällt, sich auf einen gemeinsamen Nenner zu einigen.

Hier ist das Management gefordert, sich für eine DevOps-Kultur stark zu machen – und zwar nicht nur in der Entwicklungs- und IT-Abteilung. Auch andere Bereiche wie Vertrieb, Produktmanagement, Support und Security, sollten verstanden haben, was DevOps bedeutet und sie alle auf ein Ergebnis hinarbeiten: dem Kunden qualitativ hochwertige Software und Dienstleistungen zu liefern.

Zwar hat Sicherheit bei der Softwareentwicklung schon immer eine Rolle gespielt, aber DevOps-Teams erkannten zunehmend, dass sie stärker in den gesamten DevOps-Prozess integriert werden müssten. Nur verwenden unterschiedliche Teams auch unterschiedliche Sicherheitstools. Entwickler nutzen SAST, SCA und andere Tools, das Sicherheitsteam verwendet beim Testen von Applikationen DAST und IAST, und die IT-Abteilung versucht, die Produktionsumgebung mit Anti-Malware-Tools und Netzwerksicherheitssoftware zu schützen.

DevOps-Kultur und Sicherheit: DevSecOps

DevSecOps soll nun dafür sorgen, dass eine sichere Softwareentwicklung besser zur DevOps-Kultur passt. Das geht nur, wenn Teams eine Sicherheitssoftware im Einklang mit bestehenden Prozessen verwenden können und diese Tools zum richtigen Zeitpunkt eingesetzt werden. Die Geburtsstunde von »Shift left«. Damit erhöhte sich naturgemäß der Druck auf Entwicklerseite. Nicht zuletzt deshalb, weil Art und Umfang der Testergebnisse, Developer schlichtweg überforderten.

Bei der Verschiebung nach links ging es nicht darum, Tests so schnell wie möglich durchzuführen. Man beginnt vielmehr mit dem Testen so früh wie möglich innerhalb des Softwarelebenszyklus, und verteilt die Tests im Unternehmen, damit die entsprechenden Teams geeignete Tools einsetzen.

Ziel ist ein synchronisierter Prozess, um sichere Software so schnell wie möglich bereitzustellen.

Um Anwender in die richtige Richtung zu leiten, ist »Shift Everywhere« wahrscheinlich der geeignetere Begriff. »Shift Everywhere« hat neue Ideen hervorgebracht, wie z.B. die intelligente Orchestrierung von Sicherheitstools. Damit ist gemeint, dass diese Tools genau dann eingesetzt werden, wenn sie gebraucht werden und wozu sie gebraucht werden. Sogenannte ASOC-Tools sammeln die von den Sicherheitstools gemeldeten Probleme, konsolidieren die Ergebnisse und bieten die Möglichkeit kritische Aspekte zu priorisieren.

»Was ist DevSecOps?«: DevOps umfasst eine Reihe von Entwicklungs- (Dev) und IT-Betriebspraktiken (Ops), die den agilen Prozess im Lebenszyklus der Softwareentwicklung unterstützen und eine kontinuierliche Lieferung mit hoher Qualität ermöglichen. DevSecOps erweitert jetzt DevOps, um Sicherheitspraktiken in die DevOps-Kultur zu integrieren.

DevOps in der Diskussion

Soweit das Ziel. Gerade in jüngster Zeit verliert DevOps aber an Zuspruch, und Entwickler sind inzwischen deutlich verhaltener geworden, was agile Methoden anbelangt. Eine der Ursachen: Das Verständnis dessen, was DevOps ausmacht, wofür DevOps steht und wie man DevOps implementiert, ist oftmals unter den Beteiligten recht verschieden. Und das zu einem so hohen Grad, dass inzwischen das gesamte Konzept unter falschen Vorstellungen, Missverständnissen und Implementierungen zu leiden hat.

Warum das so ist, lässt sich einfach illustrieren: Wenn man in einem Raum voller Menschen alle bittet, sie mögen sich die Farbe Grün vorstellen, dann hat jeder seine eigene Interpretation der Farbe im Kopf. Trotzdem wird sich niemand der Anwesenden scheuen, über die Farbe Grün zu sprechen. Genau das passiert bei DevOps. DevOps ist eine Idee, eine Arbeitsweise, die die Lücke zwischen Entwicklung und IT schließen und es beiden erlauben soll, bessere Ergebnisse zu liefern – und sich darüber hinaus schneller auf die sich ständig ändernden Arbeitsbereiche einzustellen. In vielen Fällen hat das dazu geführt, dass die Entwicklung einfach neue zusätzliche Aufgaben bekommen hat. So sollte es nicht sein.

Aber auch die Erwartungshaltung spielt eine Rolle, wenn Ingenieure von der DevOps-Methode enttäuscht sind. DevOps ist eben nicht statisch, d. h. ich definiere einmal und so funktioniert es in Zukunft. DevOps ist ein dynamischer, sich ständig verändernder Prozess, der an die jeweilige Arbeitsweise angepasst werden muss. An dieser Stelle gilt es, den Prozess genauer unter die Lupe zu nehmen. Welche Aufgaben haben die einzelnen Teams und wie können Sie deren Interaktion reibungslos und zügig gestalten? Das ist die Frage. Werkzeuge unterstützen diesen Prozess, aber ohne den Prozess haben Sie nur Werkzeuge und potenziell unzufriedene Benutzer. Es geht aber immer um das ganze Paket aus Menschen, Prozessen und Technologien.

In einem traditionell geführten Unternehmen kümmert sich die IT-Abteilung um die Infrastruktur, die Plattformen und alles, was technisch nötig ist, damit alle ihren Job machen können. Dann gibt es die Entwicklungsabteilung, den Vertrieb, der die Software verkauft und die IT-Sicherheit, die dafür sorgt, dass die besagte Software sicher ist. Nicht zu vergessen Marketing, Produktmanagement, Support usw. Augenscheinlich arbeiten alle auf das gleiche Ziel hin, nämlich den Umsatz – und Wachstumstopf zu füllen. Dennoch handelt es sich um voneinander getrennte Abteilungen mit unterschiedlichen Budgets und Zielen. Es entstehen die typischen Silos, die zwar voneinander abhängig sind, aber hauptsächlich an der Umsetzung der eigenen Ziele arbeiten (nicht zuletzt, um ihre Existenz zu legitimieren).

Genau diese Silos soll DevOps aufbrechen, so dass die beschriebenen Einheiten in dieselbe Richtung und auf dasselbe Ziele hin marschieren. Das bedeutet aber gerade nicht, die Verantwortung dafür alleinig in Richtung der Entwickler zu verschieben. Vielmehr geht es darum, eine DevOps-Kultur zu schaffen, zu der jeder gehört, die jeder versteht und zu der jeder beiträgt.

Einen ganz ähnlichen Effekt konnten wir übrigens beim Wandel von der Wasserfall-Methode hin zum Konzept der Agilität beobachten. »Agile« ist eine großartige Idee, die jedoch ziemlich unterschiedlich interpretiert und umgesetzt worden ist. Fehler bei der Umsetzung führten bei denen einen zu neuen Problemen, während andere mit dem Konzept erfolgreich vorangekommen sind. Das geht unter Umständen sogar soweit, dass ein Entwicklungsteam erfolgreicher ist als ein anderes – in ein und demselben Unternehmen und unter ein und derselben Leitung.

Aus einem Konzept ein funktionierendes Modell zu machen ist alles andere als trivial. Vor allem, wenn die Erwartungen von Anfang an zu hochgesteckt sind. Dazu kommt: Menschen neigen dazu, alles wörtlich zu nehmen. »Shift left« ist das beste Beispiel. Es wurden sogar eigens Firmen gegründet, um Entwicklungsteams zu unterstützen, denen aufgrund eines missverstandenen »Shift Left«, ständig neue Aufgaben zugewiesen wurden.

Ein Beispiel für so ein Missverständnis sind AST-Technologien. Man ging einfach davon aus, dass mit diesen Tools, Entwickler einfach alles tun (können): Code entwickeln, gewährleisten, dass der Code sicher ist, und sich auch noch um die Einhaltung der Vorgaben für OSS-Komponenten kümmern. Aufgaben, für die früher mehrere Teams erforderlich waren, sollten nun die übernehmen, die ohnehin massiv unter Druck stehen – weil sie nämlich neben ihrer eigentlichen Arbeit mit Markttrends, zukünftigen Anforderungen und Fehlerbehebungen Schritt halten müssen.

Aus unserer Sicht sollte der DevSecOps-Ansatz überall umgesetzt werden. Für jeden Teil des Entwicklungsprozesses sollte man die Mitarbeiter mit den erforderlichen Werkzeugen ausgestatten. Tools, die es ihnen erlauben sowohl den eigenen Part zu erledigen als auch abteilungsübergreifend zusammenzuarbeiten, um die DevOps-Kultur wirklich zu leben. Das gilt nicht nur für die Entwicklung. Management hin oder her. Wenn Sie ein Konzept nicht auf die Bedürfnisse der Beteiligten anpassen, steigt die Gefahr, dass es bei der Umsetzung gehörig hakt.

Boris Cipot, Senior Sales Engineer, Synopsys Software Integrity Group