Deep Dive: DevSecOps

Was ist DevSecOps?

DevSecOps steht für eine Methodik der Software-Delivery, die das DevOps-Modell um Security-Prozesse als dritte Kernsäule ergänzt. Dem liegt die Prämisse zugrunde, Entwicklung und Operations kulturell zu verzahnen und Prozess- und Tooling-Strukturen zu etablieren, durch die sie bei der Auslieferung sicherer Software als Einheit agieren.

Ganz allgemein basiert das DevSecOps-Modell auf der Maßgabe, Security-Ziele so früh wie möglich im Lifecycle der Software-Entwicklung zu adressieren. Sicherheit ist zwar per se eine Thematik, die alle gleichermaßen zu verantworten haben. Als Schnittstelle zwischen Software-Entwicklung und -Betrieb sind DevOps-Teams jedoch einzigartig dafür positioniert, Sicherheitsfragen in ganzer Breite und Tiefe zu adressieren.

Worin liegen die Unterschiede zwischen DevOps und DevSecOps?

Einfach ausgedrückt liegt der Unterschied zwischen DevOps und DevSecOps in der Kultur, die allen die gleichen Verantwortlichkeiten zuschreibt. DevOps ist inzwischen bereits seit mehr als zehn Jahren ein Thema, und so kursieren entsprechend viele unterschiedliche Definitionen rund um das Konzept. Im Kern lässt es sich jedoch als Paradigma geteilter Verantwortlichkeiten zwischen Entwicklung und Operations beschreiben.

DevOps vs. DevSecOps

Ursprünglich ging es dabei um ein eher lose definiertes Konstrukt allgemeingültiger Methodiken, die den Teams aus der Software-Entwicklung zu mehr Erfolg verhelfen. Daraus erwachsen ist jedoch gewissermaßen das Referenzmodell Nr. 1 für eine moderne Dev-Kultur und zugehörige Prozesse. So steht DevOps heute für Organisationsstrukturen, in denen Entwicklung und Operations als Einheit mit geteilten Verantwortlichkeiten fungieren, die Iterationen agiler umsetzt und so schneller erfolgreiche Software-Delivery ermöglicht. Diesen Grundgedanken erweitert das DevSecOps-Modell um Security als weiteres tragendes Ziel im Kontext des Gesamterfolgs. Perspektivisch ist es also keineswegs ein für sich allein stehendes Konzept, sondern vielmehr logische Konsequenz der den DevOps-Prinzipien zugrunde liegenden Leitgedanken. Teams, die bereits nach diesen agieren, sollten DevSecOps also eher als nächsten Schritt ihrer Entwicklung denn als grundlegende Erneuerung ihrer bestehenden Strukturen betrachten.

Denn hinter der Umsetzung dieser Strukturen stand ja in aller Regel die Idee, größeren Value durch eine nahtlose Prozesskette generieren zu können, in der Code konsequent schneller in die Produktion überführt werden kann. Grundlage hierfür sollten neue Tools und Methodiken bilden, die höhere Release-Frequenzen und eine engere Taktung der Delivery möglich machen. Zurück blieb dabei jedoch eine Engstelle am Security-Ende. Denn dort griffen noch immer konventionelle Methodiken mit langsamen Feedback-Cycles, die die Dynamik des DevOps-Modells ausbremsen. So stellte man Sicherheitsfragen zumeist hinten an, adressierte sie also entweder erst nach dem Produktions-Rollout, oder sie wurden von externen Teams in den Prozesses hineinoktroyiert – mit ebenso bremsendem Effekt.

Genau hier macht das DevSecOps-Modell den entscheidenden Unterschied. Denn Security-Methodiken fügen sich dabei organisch in die Kultur der geteilten Verantwortlichkeiten ein, die das DevOps-Konzept ausmachen. Sicherheitsrelevante Probleme werden also nicht erst nach dem Produkt-Release adressiert, sondern bereits in den früheren Phasen des Dev-Lifecycle einer Anwendung aufgedeckt und idealerweise auch behoben. Umgesetzt wird dies durch Strukturen, die es Entwicklern ermöglichen, das Gros der Security-Aufgaben eigenständig innerhalb des SDLC zu erledigen.

Hierdurch wird erreicht, dass Schwachstellen vor dem Produktions-Rollout auf ein bestmögliches Minimum reduziert werden, entsprechend also auch weniger Kosten im Zusammenhang mit ihrer Behebung entstehen. Zudem werden Prozesse besser skalierbar, da die Bereiche Security und DevOps näher aneinander rücken, die Prioritäten des jeweils anderen besser verstehen und in enger Zusammenarbeit in gemeinsame Ziele überführen. Das übergeordnete Ziel der DevSecOps-Methodik besteht dabei darin, Security von der Anforderungsanalyse bis zur Delivery in den gesamten Entwicklungsprozess zu integrieren und über die verschiedenen Phasen hinweg weitestmöglich zu automatisieren.

DevSecOps als Kernprämisse

Was macht DevSecOps als Methodik so wichtig?

Für die meisten Unternehmen ist die Digitalisierung heute nicht einfach nur Option, sondern existenzentscheidend. Die damit verbundenen Transformationsprozesse stützen sich dabei auf drei Tragsäulen: mehr Software, Cloud-Technologie und DevOps-Methodiken.

Im Zuge von mehr bzw. einer umfangreicheren Nutzung von Software verschiebt sich der Risikovektor zunehmend ins Digitale: Infolge wachsender technischer Schuld nimmt auch die Komplexität im Zusammenhang mit der Sicherheit von Anwendungen und digitalen Strukturen insgesamt zu.

Die Cloud bringt neue technologische Konzepte und mit ihnen neue Risiken mit sich, unterliegt einer schnellen Entwicklungsdynamik und ist öffentlich zugänglich. Das Konzept eines sicheren Perimeters verliert damit seine Gültigkeit bzw. muss neu definiert werden. Im Zuge dessen verschieben sich mit IT und Infrastruktur verbundene Risikopotenziale in die Cloud, zugleich entfallen diese für andere Elemente, die nunmehr komplett via Software definiert werden. Hier nehmen jedoch Fragen nach dem Management des Zugriffs und damit verbundener Rechte eine zentrale Rolle ein.

DevOps bringt dabei eine grundlegend neue Methodik zur Entwicklung und Auslieferung von Software auf den Plan: Von der Code-Produktion über die Value-Generierung bis hin zur Auswertung der Marktreaktion und der Feature-Adaption erfolgt die gesamte Delivery in erheblich verkürzten Zyklen. In Continuous-Delivery-Manier liefern Dev-Teams Software dabei schneller aus als je zuvor, treffen Entscheidungen rund um zugrunde liegende Technologien und Implementierung weitgehend autonom und ohne Eingriff einer zwischengeschalteten Prüfstelle. Denn klassische Feedback-Prozesse mit langsamen Durchlaufzeiten sind angesichts solcher Dynamiken weder praktikabel noch akzeptierbar. So agieren die Teams stattdessen in Eigenregie, gewissermaßen nach dem Motto „Code schreiben und laufen lassen“.

Vor diesem Hintergrund wachsen freilich die Anforderungen an das Security-Team, das so aber immer häufiger zum Hemmschuh wird. Das Dilemma: Konventionelle AppSec-Tools- und -Methodiken sind auf noch weniger dynamische Szenarien in Zeiten vor der Cloud ausgelegt, zugleich soll aber die Qualität ausgelieferter Anwendungen weiterhin auf hohem Niveau sichergestellt werden. Angesichts der chronischen Unterbesetzung ihrer Teams nicht zuletzt auch aufgrund des gravierenden Fachkräftemangels im Security-Bereich werden sie so zur Engstelle, die nicht mehr so recht Schritt halten kann. Die Konsequenz davon: Dev-Teams liefern unsichere Anwendungen aus, im Security-Team stellen sich Abnutzungserscheinungen ein und Sicherheit als Funktionsbereich gerät zum lästigen Bremsklotz für genau die Prozesse, die man eigentlich beschleunigen wollte.

Diesen denkbar unbefriedigenden Zuständen suchte man etwas entgegenzusetzen, und so wurde mit DevSecOps schließlich eine Erweiterung bestehender Konzepte ins Leben gerufen, die Sicherheit thematisch und methodisch in die DevOps-Kultur trägt. Hierdurch wird es auf der einen Seite möglich, dass Entwickler ihren Code im Tempo ihrer Release-Frequenz sicher machen, auf der anderen Seite entsteht eine engere Partnerschaft zwischen ihnen und dem Fachbereich Security: Dieser übernimmt nun die Rolle einer Anlaufstelle für das Dev-Team, die ihm mit Know-how und zielführenden Tools zu mehr Eigenständigkeit in punkto Security verhilft, und zugleich die einer Kontrollinstanz, die das Sicherheitsniveau insgesamt steuert und überwacht.

Sechs Vorteile des DevSecOps-Modells

1. Schnellere Releases: Werden Security-Themen direkt in der Pipeline adressiert, sind höhere Release-Frequenzen möglich, da Schwachstellen noch vor dem Deployment identifiziert und behoben werden. Denn Entwickler werden so nicht unnötig von der Feature-Entwicklung abgelenkt.

2. Gestärktes Sicherheitsprofil: Sicherheit wird bereits in der Design-Phase adressiert und zieht sich von dort aus durchgängig in einem Modell der geteilten Verantwortlichkeiten weiter. Von der Entwicklung zum Deployment bis zu den Workloads in der Produktion wird Security so als Methodik eng in sämtliche Phasen integriert.

3. Kosteneinsparungen: Durch die Erkennung von Schwachstellen und Fehlern noch vor dem Rollout werden Risiken ebenso wie operative Kosten in exponentiellem Maße reduziert.

4. Mehr Value-Generierung aus DevOps-Methodiken: Geteilte Verantwortlichkeiten in punkto Security bedeuten stärkere Sicherheit im DevOps-Kontext. Wie aus dem DevSecOps Insights Report 2020 von Snyk und Puppet hervorgeht, nehmen diese Vorteile mit zunehmendem Reifegrad der zugehörigen Methodiken zudem weiter zu.

5. Engere Integration und höhere Effizienz von Security-Prozessen: Sichere Software wird bei geringerem Kosten- und Zeitaufwand ausgeliefert, da Sicherheitskontrollen nicht mehr im Nachgang ins Deployment eingepasst werden müssen.

6. Förderung zentraler geschäftlicher Erfolgsfaktoren: Durch wachsendes Vertrauen in die Sicherheit von Software-Entwicklungen und den sicheren Einsatz neuer Technologie werden Umsatzchancen stimuliert und ein breiter angelegtes Angebotsspektrum möglich.

Umsetzung von DevSecOps: Security-Integration in die CI/CD-Pipeline

Modernen DevOps-Konzepten liegt zumeist ein Modell zugrunde, das Continuous Integration und Continuous Delivery/Integration als CI/CD-Pipeline kombiniert. Diese bildet das perfekte Grundgerüst, um eine Vielzahl von Security-Tests automatisiert einzubringen und zugleich auch die Validierung ohne jegliche manuelle Eingriffe abzuwickeln.

Der Weg zu DevSecOps: Integration von Security-Prozessen in die CI/CD-Pipeline

Die Bestimmung der Anforderungen und Zielsetzungen für die Sicherheit einer Anwendung wird dabei weit vorgezogen. Angesetzt wird hier, noch bevor überhaupt die erste Codezeile entstanden ist. So wird das Bedrohungsprofil noch bei der Konzeptionierung von System- und Anwendungsdesign sowie User Stories anhand von Threat Modelling ermittelt. Im weiteren Verlauf lassen sich dann statische Code-Analysen, Linter und Policy-Engines implementieren, die jedes Mal greifen, wenn Entwickler einen Code-Check-in vornehmen. So lässt sich bereits das Gröbste ausfiltern, bevor der Code im Workflow weitergereicht wird.

Software Composition Analysis (SCA) kann dabei übergreifend in der gesamten Pipeline ausgeführt und so gewährleistet werden, dass nur den Vorgaben gemäß lizenzierte und zudem nicht mit Schwachstellen belastete Open-Source-Abhängigkeiten genutzt werden. Bedeutend ist dabei zudem, dass sich durch das direkte Feedback dazu, wie es um die Sicherheit ihres jeweiligen Codes bestellt ist, bei Entwicklern auch insgesamt ein stärkeres Bewusstsein für die Thematik einstellen wird.

Im Anschluss an den Check-in des Codes in den Build lässt sich eine weitere Scan-Strecke in Form von Security Integration Tests ansetzen. Umgesetzt wird dies mit einer Container-Sandbox, in der der Code isoliert ausgeführt und automatisierte Tests etwa für Netzwerkaufrufe, Input-Validierung und Autorisierung durchgeführt werden können. Feedback zu den Testergebnissen steht dabei umgehend zur Verfügung. Dies macht schnelle Iterationen möglich, zudem lassen sich potenziell erkannte Probleme nach Priorität abarbeiten. Unterbrechungen im Gesamt-Workflow werden so auf ein Minimum reduziert. Werden im Rahmen der Testings etwa unerwartete Netzwerkaufrufe oder nicht bereinigte Daten-Inputs erkannt, wird der Build abgewiesen. Dabei generiert die Testing-Pipeline Reports mit konkret umsetzbarem Feedback zur Problemstellung und benachrichtigt die jeweils zuständigen Teams.

Wurde das Deployment-Artefakt von der ersten Reihe der Integrationstests durchgewunken, geht es in einer ausgedehnter angelegten Sandbox weiter, die bereits bis zu einem gewissen Grad die zukünftige Produktionsumgebung nachbildet. Auch hierbei werden Integrationstests angewendet, doch sind die Zielsetzungen anders gelagert.

So geht es nun etwa um Tests auf korrektes Logging oder Zugriffskontrollen, bei denen untersucht wird, ob die Anwendung Security- und Performance-Metrics korrekt erfasst und Zugriffsrechte wie vorgesehen auf den richtigen Nutzerkreis beschränkt (oder auch komplett verweigert). Auch hier wird bei Feststellung von Unzulänglichkeiten der Build blockiert und den relevanten Teams Fixing-Tasks zugewiesen.

Ist auch dieser Schritt abgeschlossen, kann die Anwendung in die Produktion übergehen. Im DevSecOps-Workflow ist damit jedoch keineswegs bereits das Ende erreicht. Denn von hier ab lassen sich automatisiertes Patching und Konfigurationsmanagement ansetzen und so gewährleisten, dass in der Produktionsumgebung stets nur die aktuellsten und sichersten Versionen der jeweils genutzten Software-Abhängigkeiten ausgeführt werden. Idealerweise bleibt die Infrastruktur dabei unveränderlich. In diesem Zusammenhang bedeutet dies, dass die gesamte Umgebung regelmäßig komplett verworfen und neu aufgezogen wird, um erneut die gesamte Teststrecke entlang sämtlicher Punkte der Pipeline zu durchlaufen.

In einer solchen DevSecOps-Pipeline auf Grundlage der CI/CD-Prinzipien lassen sich Zielsetzungen und Anforderungen rund um Security mühelos in jeder Phase implementieren – ganz ohne unnötige Hindernisse, die einer schnellen Value-Generierung entgegenstehen würden.

DevSecOps als Kulturthema

Wie aber gelingt es, eine solche Entwicklung organisch zu vollziehen? Denn es wird kaum ausreichen, dem DevOps-Team eine Handvoll Security-KPIs vorzusetzen, die es künftig innerhalb seiner ohnehin schon eng getakteten Prozessen zu erfüllen hat. Vielmehr gilt es, einen kulturellen Evolutionsprozess anzustoßen, der von Austausch und schneller Iteration geprägt ist.

Denn praktikabel lassen sich Security-Aspekte nur in der Pipeline vorziehen, wenn dies mit minimalen Reibungspunkten verbunden ist. Die damit verbundenen Anforderungen und Ziele wie auch das Security-Team selbst dürfen also nicht in einer Weise in die Wertschöpfungskette eingreifen, die für Entwickler zusätzliche Prozessschritte und damit im Ergebnis wieder Verzögerungen im Delivery-Cycle bedeuten. Vielmehr gilt es, dass das Security-Team sein Prozesskonstrukt agil und pragmatisch in Development-Strukturen einpasst.

In der Planungsphase etwa sollte es insbesondere in punkto Infrastruktur involviert und hier auch in der Lage sein, bei sicherheitstechnisch unvorteilhaften oder risikobehafteten Entscheidungen zu unterbrechen, zugleich aber auch fundiert adäquate Alternativen zu unterbreiten. Gerade hierbei überlässt es das DevOps-Teams aufgrund der eigenen Überforderung nämlich oft sich selbst. Damit es hier statt mit bloßen Vetos zu reagieren auch unterstützend wirken kann, ist die besagte Ausstattung mit Ressourcen entscheidend, die es in diesem Kontext zur Verfügung hat.

Das Ergebnis ist ein enger Austausch zwischen Security und DevOps, die sicherheitsbezogene Ziele in enger Zusammenarbeit mit allen Aspekten der Infrastruktur verzahnen. Features und Anwendungen, die in die Produktion überführt werden, entstehen als Produkt aus so umfassender wie effektiver Zusammenarbeit zwischen den Teams aus Security, Entwicklung und Operations. Statt im Nachgang zusätzliche Adaptionen einfordern oder Audits beim Dev-Team anstellen zu müssen, kann das Security-Team so von Anfang an auf die Sicherheit im Ergebnis vertrauen.

Unternehmen, die den Schritt in Richtung DevSecOps erfolgreich meistern, sind nicht nur bestens für schnelle Iteration und damit schnellere Feature-Innovation und funktionale Optimierung aufgestellt. Sie rollen all dies auch in der Gewissheit aus, dabei stets ein Höchstmaß an Sicherheit zu garantieren.