DevSecOps im Überblick
Artikel von
0 Min. Lesezeit
Was ist DevSecOps?
DevSecOps bezeichnet die Integration von Sicherheitspraktiken in ein DevOps-Softwarebereitstellungsmodell. Grundlage ist eine Kultur, in der Entwicklung und Betrieb durch Prozesse und Tools dazu befähigt werden, gemeinsam Verantwortung für die Bereitstellung sicherer Software zu übernehmen.
Die Definition des DevSecOps-Modells auf einem hohen Funktionsniveau besteht darin, Sicherheitsziele so früh wie möglich in den Softwareentwicklungszyklus zu integrieren. Auch wenn Sicherheit „in der Verantwortung aller liegt“, sind DevOps-Teams an der Schnittstelle zwischen Entwicklung und Betrieb besonders gut aufgestellt, um Sicherheit umfassend und tiefgreifend umzusetzen.
Was ist der Unterschied zwischen DevOps und DevSecOps?
Der Unterschied zwischen DevOps und DevSecOps lässt sich einfach erklären: Es geht um eine Kultur gemeinsamer Verantwortung. Über DevOps wird seit mehr als einem Jahrzehnt gesprochen und geschrieben, und inzwischen gibt es zahlreiche Definitionen. Im Kern ist DevOps ein Organisationsmodell, das Entwicklungs- und Betriebspraktiken aufeinander abstimmt und als gemeinsame Verantwortung versteht.
Vergleich: DevOps vs. DevSecOps
Was als lose Sammlung bewährter Praktiken begann, die leistungsstarke Softwareentwicklungsteams gemeinsam nutzten, entwickelte sich zu einem modernen Verständnis von Engineering-Kultur und -Prozessen: DevOps. Unternehmen, in denen Entwicklung und Betrieb gemeinsam Verantwortung tragen, können schneller iterieren und sind dadurch erfolgreicher. DevSecOps erweitert diese Philosophie und verankert Sicherheitsziele in der übergeordneten Zielstruktur. DevSecOps sollte als natürliche Weiterentwicklung von DevOps verstanden werden, nicht als separate Idee oder Konzept. Teams, die DevOps-Praktiken erfolgreich anwenden, sollten DevSecOps als evolutionären statt revolutionären Schritt betrachten.
Viele würden zustimmen, dass das Ziel darin bestand, ein Umfeld zu schaffen, in dem geschäftlicher Mehrwert durch einen nahtlosen und nachhaltigen Weg vom Code bis zur Produktion entsteht. Mit diesem neuen Modell kamen Tools und Methoden auf, die das Tempo erhöhten und einen Engpass verursachten: Herkömmliche Sicherheitspraktiken mit langsamen Feedbackzyklen bremsten die schnelllebigen DevOps-Praktiken aus. Infolgedessen wurden Sicherheitsmaßnahmen oft erst nach der Bereitstellung umgesetzt oder von externen Teams in den Prozess eingebracht – was ihn wiederum verlangsamte.
Um den Unterschied zwischen DevOps und DevSecOps deutlicher zu machen: DevSecOps erweitert die Kultur gemeinsamer Verantwortung in DevOps um Sicherheitspraktiken. Maßnahmen zur Erkennung und möglichst direkten Behebung von Sicherheitsproblemen werden früh im Anwendungsentwicklungszyklus eingebunden, statt erst nach der Produktveröffentlichung. Dazu werden Entwicklungsteams in die Lage versetzt, viele Sicherheitsaufgaben eigenständig im Softwareentwicklungszyklus (SDLC) zu erledigen.
Dieser Ansatz trägt dazu bei, die Zahl der Schwachstellen in der Produktionsumgebung zu minimieren und so die Kosten für die Behebung von Sicherheitslücken zu senken. Er ermöglicht Skalierbarkeit und fördert zugleich eine kooperative Kultur, die Sicherheit enger mit den DevOps-Zielen verknüpft. DevSecOps zielt darauf ab, Sicherheit in jede Phase des Bereitstellungsprozesses einzubetten – beginnend mit den Anforderungen – und einen Plan für die Sicherheitsautomatisierung zu erstellen.
Warum DevSecOps wichtig ist
Warum sind DevSecOps-Praktiken wichtig?
Die digitale Transformation ist für fast alle Unternehmen zu einer existenziellen Notwendigkeit geworden. Sie umfasst drei wesentliche Entwicklungen: mehr Software, Cloud-Technologien und DevOps-Methoden.
Mehr Software bedeutet, dass ein größerer Teil des Unternehmensrisikos digital wird. Dadurch steigen die technischen Schulden und die Anforderungen an die Anwendungssicherheit, was den Schutz digitaler Ressourcen zunehmend erschwert.
Die Cloud bedeutet den Einsatz neuerer Technologien, die andere Risiken mit sich bringen, sich schneller verändern und öffentlich stärker zugänglich sind – damit wird das Konzept eines sicheren Perimeters hinfällig oder neu definiert. Außerdem werden viele IT- und Infrastruktur-Risiken in die Cloud verlagert, während andere vollständig softwaredefiniert werden. Das verringert manche Risiken und unterstreicht zugleich die Bedeutung von Berechtigungs- und Zugriffsverwaltung.
Und schließlich bedeutet DevOps eine Veränderung der Art und Weise, wie Software entwickelt und bereitgestellt wird: Der Zyklus vom Schreiben des Codes über die Bereitstellung von Mehrwert für Kunden bis hin zum Lernen aus dem Markt und der anschließenden Anpassung wird beschleunigt. Befähigte Entwicklungsteams stellen Software kontinuierlich und schneller als je zuvor bereit und treffen Technologie- und Implementierungsentscheidungen autonom und ohne Vermittler. Die traditionellen langsamen Feedbackschleifen, die die Entwicklung ausbremsen, werden nicht mehr akzeptiert, da Teams zunehmend auf Selbstständigkeit setzen: Sie schreiben den Code und betreiben ihn auch.
Während sich der Rest des Unternehmens weiterentwickelt, stehen Sicherheitsteams unter höheren Anforderungen und werden oft zunehmend zum Engpass. Veraltete Tools und Praktiken für die Anwendungssicherheit, die für die langsamere Zeit vor der Cloud entwickelt wurden, bringen Sicherheitsteams in den kritischen Pfad der Bereitstellung hochwertiger Anwendungen. Aufgrund des gravierenden Mangels an Sicherheitsexperten sind diese Teams unterbesetzt, werden zum Engpass und können nicht Schritt halten. In der Folge stellen Entwicklungsteams unsichere Anwendungen bereit, Sicherheitsteams brennen aus und die Sicherheitsfunktion wird zum Verhinderer – wodurch die vom Unternehmen angestrebte Beschleunigung zunichtegemacht wird.
Um diese Herausforderungen zu bewältigen, begannen Unternehmen, ihre Praktiken zu ändern – so entstand DevSecOps. Eine DevSecOps-Kultur integriert Sicherheit in DevOps und ermöglicht es Entwicklungsteams, die von ihnen erstellten Produkte im eigenen Tempo abzusichern. Gleichzeitig fördert sie die Zusammenarbeit zwischen Entwicklungs- und Sicherheitsexperten. Sicherheitsteams können dadurch als unterstützende Einheit agieren und ihr Fachwissen sowie Tools bereitstellen, um die Autonomie der Entwickler zu stärken und zugleich die vom Unternehmen geforderte Kontrolle sicherzustellen.
6 Vorteile des DevSecOps-Modells
Schnellere Bereitstellung: Wenn Sicherheit in die Pipeline integriert ist, wird Software schneller bereitgestellt. Fehler werden vor der Bereitstellung erkannt und behoben, sodass Entwickler sich auf die Auslieferung von Funktionen konzentrieren können.
Verbesserte Sicherheitslage: Sicherheit ist von der Entwurfsphase an ein grundlegendes Merkmal. Ein Modell gemeinsamer Verantwortung stellt sicher, dass Sicherheit fest integriert ist – beim Entwickeln und Bereitstellen ebenso wie beim Absichern von Workloads in der Produktionsumgebung.
Geringere Kosten: Werden Schwachstellen und Fehler vor der Bereitstellung erkannt, sinken Risiken und Betriebskosten exponentiell.
Mehr Mehrwert durch DevOps: Die Integration von Sicherheitspraktiken in DevOps verbessert die allgemeine Sicherheitslage und schafft eine Kultur gemeinsamer Verantwortung. Der Snyk/Puppet DevSecOps Insights Report 2020 bestätigte dies für Unternehmen mit ausgereiften DevSecOps-Praktiken.
Bessere Sicherheitsintegration und höheres Tempo: Die Kosten und der Zeitaufwand für die sichere Softwarebereitstellung sinken, wenn Sicherheitsmaßnahmen nicht nach der Entwicklung nachgerüstet werden müssen.
Mehr geschäftlicher Erfolg: Größeres Vertrauen in die Sicherheit entwickelter Software und die Nutzung neuer Technologien fördern das Umsatzwachstum und erweitern das Geschäftsangebot.
Einführung von DevSecOps: Sicherheit in die CI/CD-Pipeline integrieren
Die meisten modernen DevOps-Unternehmen setzen auf eine Kombination aus Continuous-Integration- und Continuous-Deployment- bzw. -Delivery-Systemen in Form einer CI/CD-Pipeline. Die Pipeline bietet eine hervorragende Grundlage für verschiedene automatisierte Sicherheitstests und Validierungen – ganz ohne den manuellen Aufwand durch menschliche Bediener.
DevSecOps-Einführung: Sicherheit in die CI/CD-Pipeline integrieren
Um Sicherheitsziele frühzeitig in die Anwendungsentwicklung zu integrieren, sollten Sie bereits vor der ersten geschriebenen Codezeile beginnen. Sicherheitsexperten können schon in der ersten Konzeptphase des Systems, der Anwendung oder einer einzelnen User Story mitwirken und ein effektives Threat Modeling starten. Statische Analysen, Linter und Policy-Engines können immer dann ausgeführt werden, wenn Entwickler Code einchecken. So werden leicht behebbare Probleme beseitigt, bevor die Änderungen weiter in der Pipeline voranschreiten.
Mit einer ganzheitlichen Software Composition Analysis lässt sich sicherstellen, dass Open-Source-Abhängigkeiten kompatible Lizenzen haben und frei von Schwachstellen sind. Ein positiver Nebeneffekt: Entwickler übernehmen Verantwortung für die Sicherheit ihrer Anwendungen und erhalten sofortiges Feedback zur Sicherheit des von ihnen geschriebenen Codes.
Sobald der Code eingecheckt und erstellt wurde, können Sicherheitstests für die Integration beginnen. Wird der Code in einer isolierten Container-Sandbox ausgeführt, lassen sich Netzwerkaufrufe, Eingabevalidierung und Autorisierung automatisiert testen. Diese Tests liefern schnelles Feedback und ermöglichen es, erkannte Probleme rasch zu beheben und zu priorisieren – bei minimaler Beeinträchtigung des gesamten Ablaufs. Treten beispielsweise unerklärliche Netzwerkaufrufe oder nicht bereinigte Eingaben auf, schlagen die Tests fehl und die Pipeline liefert umsetzbares Feedback in Form von Berichten und Benachrichtigungen an die zuständigen Teams.
Sobald das Bereitstellungsartefakt die erste Reihe von Integrationstests bestanden hat, folgt die nächste Testphase. Nun wird es in einer größeren Sandbox bereitgestellt, einer begrenzten Kopie der späteren Produktionsumgebung. In dieser Phase können weitere Sicherheitstests zur Integration durchgeführt werden – allerdings mit einem anderen Ziel.
Jetzt lassen sich beispielsweise die korrekte Protokollierung und Zugriffskontrollen testen. Protokolliert die Anwendung relevante Sicherheits- und Leistungsmetriken korrekt? Ist der Zugriff auf die richtige Personengruppe beschränkt oder vollständig unterbunden? Auch hier führen Fehler zu konkreten Aufgaben für die zuständigen Teams.
Schließlich gelangt die Anwendung in die Produktionsumgebung. Doch die Arbeit im Rahmen von DevSecOps geht weiter. Automatisiertes Patching und Konfigurationsmanagement stellen sicher, dass in der Produktionsumgebung stets die neuesten und sichersten Versionen der Software-Abhängigkeiten ausgeführt werden. Im Idealfall sorgt eine unveränderliche Infrastruktur dafür, dass die gesamte Umgebung regelmäßig abgebaut und neu erstellt wird und dabei immer wieder die gesamte Testreihe der Pipeline durchläuft.
Mit einer DevSecOps-CI/CD-Pipeline lassen sich Sicherheitsziele in jede Phase integrieren – ohne belastende Bürokratie und zusätzliche Hürden. So bleibt die schnelle Bereitstellung geschäftlichen Mehrwerts gewährleistet.
Eine DevSecOps-Kultur fördern
Wie kann ein Unternehmen also den evolutionären Schritt von „DevOps“ zu „DevSecOps“ vollziehen? Es reicht nicht, einem ohnehin ausgelasteten DevOps-Team einfach einige Sicherheits-KPIs zuzuweisen und es dabei zu belassen. Dafür braucht es eine kooperative Kultur gemeinsamer Verantwortung und schneller Iterationen.
Wenn Sicherheitsziele frühzeitig integriert werden sollen, muss sich das so einfach wie möglich umsetzen lassen. Es sollte nicht an den Entwicklern hängen bleiben, Sicherheitsteams und -ziele in den Wertstrom einzubinden. Zusätzliche Schritte würden lediglich die Zeit bis zur Bereitstellung neuer Funktionen für Kunden verlängern. Die Sicherheitsfunktion sollte agil arbeiten und Sicherheit pragmatisch mit möglichst geringen Unterbrechungen umsetzen.
Während der Planungsphase – insbesondere bei Infrastrukturfragen – sollten Sicherheitsexperten in Gespräche einbezogen werden. Sie sollten befähigt sein, sich gegen schlechte oder unsichere Entscheidungen auszusprechen, und zugleich über das nötige Wissen verfügen, um Alternativen anzubieten. Oft sagen überlastete Sicherheitsteams einfach „Nein“ und überlassen es den DevOps-Teams, Alternativen zu finden. Auch hier geht es darum, Sicherheitsorganisationen mit den richtigen Ressourcen auszustatten.
Wenn Sicherheits- und DevOps-Teams frühzeitig und regelmäßig zusammenarbeiten, werden Sicherheitsziele fest in der Infrastruktur verankert. Funktionen und Anwendungen, die in der Produktionsumgebung bereitgestellt werden, sind das Ergebnis einer umfassenden und effektiven Zusammenarbeit zwischen Sicherheit, Entwicklung und Betrieb. Sicherheitsteams müssen nicht nachträglich zusätzliche Funktionen oder Audits von Entwicklungsteams einfordern – sie wissen, dass diese von Anfang an integriert wurden.
Wenn Ihr Unternehmen dazu übergegangen ist, DevSecOps zu praktizieren, wissen Sie: Sie entwickeln nicht nur schnell weiter und begeistern Ihre Kunden mit neuen Funktionen und verbesserter Funktionalität, sondern bieten dieses Erlebnis auch mit einem entsprechenden Maß an Sicherheit.
Lesen Sie, wie Sie DevSecOps in 4 Schritten implementieren.