Hinter "DevSecOps" steht die Verzahnung des bekannten DevOps-Prinzips mit Mechanismen, die bereits während des Entwicklungsprozesses für das nötige Sicherheitsniveau des Endprodukts sorgen soll.

Zur Erinnerung: Der Begriff "DevOps" beschreibt grob gesagt einen Prozess, bei dem voneinander getrennte "Silos" im Unternehmen aufgebrochen werden, damit die Abteilungen für Entwicklung (Development) und Betrieb (Operations) agil und parallel zusammenarbeiten. Der übergeordnete Zweck ist es, auf gemeinsame Ziele hinzuarbeiten und in höherer Frequenz bessere, stabilere Software auszuliefern. Damit geht meist einher, dass in den verschiedenen Phasen des Entwicklungszyklus verstärkt auf Automation gesetzt wird.

Trotz all dieser Agilität darf der Sicherheitsaspekt jedoch nicht vernachlässigt werden und sollte von Anfang an integraler Teil der Softwareentwicklung sein - quasi Security in der DNA des Codes. Hinter DevSecOps steckt also nicht nur irgendein weiterer Trend. Es ist die logische, grundlegende und vor allem notwendige Evolution der agilen Entwicklungs-Methode.

Der Stand der Dinge

Laut der "Trendstudie DevOps 2017" des Münchener IT-Dienstleisters und Beraters X-cellent Technologies nutzen bereits knapp sechs von zehn Unternehmen (56 Prozent) im süddeutschen Raum DevOps.

Beim Reifegrad hapert es allerdings noch. "In Deutschland hängen die Firmen noch in der ersten Stufe: der Einführung von DevOps," bewertet Peter Mörsch, Principal Business Technology Architect bei CA Technologies, den hiesigen Status quo. Viele Unternehmen würden sich selbst überfordern, wenn sie zusätzlich zu DevOps auch noch die agile Transformation des gesamten Unternehmens anstoßen. Es würden parallel neue Aufgabenfelder definiert und plötzlich sollen alle mit allen sprechen. Das allein sei schon herausfordernd. Zusätzlich müssten dann auch noch neue Software-Lösungen angeschafft werden, damit die neuen Methoden überhaupt richtig abgebildet werden könnten. Entsprechend sei es nicht verwunderlich, dass Unternehmen in Deutschland noch nicht so weit sind. Das wichtigste sei aber: Sie haben begonnen. Und damit sei es nur eine Frage der Zeit, bis sie auch das Thema DevSecOps in Angriff nehmen, schließt Mörsch.

Diese schrittweise Entwicklung von DevOps zu DevSecOps birgt jedoch Risiken.

Agile Unterlassungssünden und ihre Folgen

Um die Sicherheit von Software zu gewährleisten, bedarf es meist hochspezialisierter Fachkräfte und komplexer Prüfmechanismen. Eine DevOps-Strategie, die entsprechende Experten nicht von Anfang an, sondern erst kurz vor der Fertigstellung oder - schlimmer noch - erst nach der Auslieferung der Software hinzuzieht, könnte potentiell katastrophale Folgen haben.

Findet das Security-Team kurz vor der Veröffentlichung noch Sicherheitslücken, muss das Release noch einmal gepatcht werden. Das verlängert den Fertigstellungsprozess merklich und hebelt so den zugrunde liegenden Agilitätsgedanken aus.

Werden die Mängel erst nach der Live-Schaltung entdeckt, muss das Release eine erneute Testphase durchlaufen. Auch hier wird der Prozess in die Länge gezogen und es entstehen unter Umständen Irritationen bei den Anwendern.

Im schlimmsten Fall wird ein Release veröffentlicht und ein Angreifer kompromittiert über eine Schwachstelle das eigene Netzwerk oder das eines Kunden. Es drohen Datenlecks, Systemausfälle und nicht zuletzt Reputationsschäden, Bußgeldzahlungen oder strafrechtliche Konsequenzen, von denen sich das Unternehmen eventuell nicht mehr erholt.

Das Risiko DevOps einzusetzen, ohne die Sicherheits-Teams von Anfang an einzubeziehen, steht also in keinem Verhältnis zu dem Aufwand, bestehende Prozesse entsprechend anzupassen.

Aber wie funktioniert das?

Integriert Klotzen statt inkonsequent Kleckern

Laut Mike Bursell, Chief Security Architect bei Red Hat, geht es bei DevSecOps eigentlich darum, DevOps von Anfang an richtig zu machen: "Wenn DevOps betrieben wird, ohne den Sicherheitsaspekt ins Zentrum des Prozesses zu setzten, dann setzt man DevOps falsch ein." Das bedeute nicht, dass Sicherheit dogmatisch alles diktieren sollte, was man tue, da man sonst Gefahr laufe, sich in einen Stillstand zu manövrieren. Vielmehr sollte Sicherheit als integraler Teil in die DevOps-Zyklen mit eingebaut werden. Das sei, so Bursell, DevSecOps.

Für ihn sei es ein guter DevSecOps-Ansatz, wenn Tools, Prozesse und Arbeitskultur zusammenfließen. Sicherheitsexperten aktiv zu involvieren, zu Teammitgliedern zu machen und zu animieren, ihr breites Fachwissen in die Prozesse einzubetten, ermögliche es, "Sicherheit in der Form innerhalb des DevOps-Modells zu automatisieren, dass alle Beteiligten von ihrer Expertise profitieren," schließt Bursell.

Ähnlich sieht das auch Meera Rao, Senior Principal Consultant und Director für sichere Entwicklungsverfahren bei Synopsys, Anbieter im Bereich Halbleiter-Design-Software (Electronic Design Automation, EDA). Sie habe die Erfahrung gemacht, dass viele Unternehmen es für den wichtigsten Schritt beim Übergang zu agilen oder DevOps-Methoden halten, ein oder mehrere Tools anzuschaffen. "Tools sind aber keine Patentlösung," konstatiert Rao und führt aus, dass DevSecOps nicht auf automatisierte Werkzeuge reduziert werden könne. Die Vorteile gut implementierter Automatisierung seien zwar nicht von der Hand zu weisen. Auf der anderen Seite würden Entwicklungs-, Betriebs- und Sicherheits-Abteilungen aber ebenso Zeit, Mühen und Budget verschwenden, wenn es schlecht eingesetzt würde.

Auch Andreas Meurer, IT Project Manager beim Münchner IT-Projektdienstleister Pentasys AG, räumt der Automatisierung einen hohen Stellenwert ein: "Automatisierungstools, um den Softwarezyklus von der ersten Zeile Code bis zum Produktionsbetrieb möglichst nahtlos zu gestalten, sind eine große Hilfe." Allerdings komme es grundlegend auf die Qualität dieser Tools und Ihres Einsatzes an.

CA-Manager Mörsch sieht bei diesem Prozess zwei Herausforderungen: DevSecOps benötige zwar eine integrierte Automatisierung, das könne aber bedeuten, dass man sich von bislang genutzten Tools trennen muss. Zudem bedürfe es eines tiefen Verständnisses aller Mitarbeiter für die Veränderungen und die Herausforderung des jeweils anderen. "Das kommt nicht von alleine, sondern muss bewusst gefördert und begleitet werden," mahnt Mörsch.

Security ist keine Nebensache

Während sich einige Entwickler durchaus mehr oder weniger tiefgreifend mit den verschiedenen Sicherheitsaspekten ihrer Arbeit auskennen, werden sie ihr Hauptaugenmerk dennoch darauf haben, Software zu schreiben und zu testen.

"Ich liebe Security, aber nicht jeder empfindet so," fasst Bursell von Red Hat die Situation zusammen. Man sollte nicht jedem Entwickler sagen müssen, er solle jetzt ein Sicherheitsexperte werden, denn damit verlange man eine ganze Menge und es würde sowieso nicht passieren.

Habe man aber bestimmte Mitarbeiter oder Rollen im Einsatz, die damit betraut seien, vorhandene Richtlinien innerhalb der Prozesse zu automatisieren, müsse man lediglich sicherstellen, dass diese auch eingehalten würden. Aktive Eingriffe wären dann lediglich nach dem Ausnahmeprinzip nötig.

So viel zum theoretischen Unterbau. Was bedeutet es nun aber konkret für Unternehmen, wenn sie DevSecOps einsetzen möchten?

Die unendliche Geschichte

Über einen Punkt sollten sich Unternehmen im Klaren sein, wenn Sie DevSecOps nutzen möchten: Man wird nie fertig. Agilität bedeutet das Loslösen von festen Zyklen und klassischen "Versionen" zugunsten kontinuierlicher Weiterentwicklung. Des Weiteren muss die Sicherheit der Software mit der sich ständig verändernden Bedrohungslandschaft mithalten, sodass der Entwicklungsprozess einem steten Wandel durch Anpassungen unterworfen ist.

Auf organisatorischer Ebene sind Transparenz und Teamwork die Hauptpfeiler für den Erfolg. Es sollten offene Kommunikationskanäle zwischen allen relevanten Teilnehmern an dem Prozess bestehen. Collaboration-Tools, die zu jeder Zeit den genauen Status der jeweiligen Projekte wiederspiegeln, helfen zudem dabei, übergreifend einen einheitlichen Wissensstand sicherzustellen. Beides trägt dazu bei, Konflikte zwischen den verschiedenen Teams zu vermeiden.

Meera Rao von Synopsys erklärt: "Dabei sollten die Sicherheits-Teams die passenden Tools, Technologien und Prozesse auswählen, die eine enge Zusammenarbeit begünstigen." Würden diese Schritte richtig umgesetzt, könnten die traditionellen Silos, in denen sich Entwicklungs-, Betriebs- und Sicherheitsabteilungen bewegen, aufgebrochen werden.

Zudem sollten leistungsstarke Revisions-Tools und Prozesse mit umfangreichen Change-Logs und Ähnlichem im Einsatz sein, die alle Änderungen im Detail festhalten. So kann man, wenn nötig, schnell zu einem beliebigen Zeitpunkt in der Entwicklung zurückkehren und Fehler beseitigen.

"Es ist wichtig, einen Prozess zu erschaffen, der reproduziert und überprüft werden kann, damit sich die DevSecOps-Teams daran orientieren und ein Budget festlegen können," kommentiert Rao. Werde den Sicherheitsverantwortlichen ermöglicht, sich schnell an veränderte Geschäftsziele und ständig weiterentwickelnde Bedrohungen anzupassen, fördere das den gemeinsamen Change-Prozess innerhalb des DevSecOps-Programms.

Erfolge messen, Probleme identifizieren

Daniel Kennedy, Research Director für Informationssicherheit bei 451 Research konstatiert, dass durch ein funktionierendes Programm für Anwendungssicherheit Defekte früher im Lebenszyklus der Softwareentwicklung entdeckt und korrigiert würden. Hätten Entwickler die Möglichkeit, Static Application Security Testing (SAST) anzuwenden und auf relevantes Schulungsmaterial für das identifizierte Code-Problem zuzugreifen, sollte weniger anfälliger Code in den Builds landen. Damit sollten laut Kennedy "in einem späteren Regressionstest oder Sicherheits-Audit weniger Defekte auftreten."

Um den Erfolg zu messen, gebe es Kennedy zufolge verschiedene Wege. Der offensichtlichste sei, wenn bei der Überprüfung durch ein Sicherheitstool weniger Mängel identifiziert würden. Die Effektivität der fortlaufenden Verbesserung zeigt sich, wenn Defekte weniger oft eingebaut und früher im Zyklus der Softwareentwicklung korrigiert würden. "Das führt schließlich dazu, dass sich weniger Leute früher im Entwicklungsprozess mit den Fehlern befassen müssen und somit weniger Kosten und Aufwand für die Korrektur verursacht werden," schließt Kennedy.

Es gibt einige Standards für Metriken, anhand derer Unternehmen den Erfolg des Change-Programms messen können. Quartalsweise Reviews können helfen sicherzustellen, dass man auf dem richtigen Weg ist. Rao rät dazu, sich an folgenden Fragestellungen zu orientieren:

• Wo stehen wir heute bei der Implementierung von DevSecOps?

• Vor welchen Herausforderungen stehen wir und wie können wir sie überwinden?

• Was funktioniert gut und wie können wir Defizite beseitigen?

Klar ist, dass nichts zu 100 Prozent sicher sein kann. Hat man jedoch den Sicherheitsaspekt mit allen anderen Faktoren eng verzahnt, steigt die Wahrscheinlichkeit, dass kritische Probleme frühzeitig erkannt und beseitigt werden.