Die Software-Entwicklung hat sich die vergangenen Jahre dynamisch weiterentwickelt. Agile Methoden haben vor allem die Zusammenarbeit zwischen Business und Development verbessert, sodass Anforderungen schneller und besser getestet umgesetzt werden konnten. Mit DevSecOps rücken Entwicklung und Betrieb enger zusammen und verbessern den gesamten Bau-, Test- und Auslieferungsprozess kontinuierlich.
Mit DevSecOps werden Risiken frühzeitig erkannt und nachhaltig Mehrwert geschaffen. Wie Sicherheit möglichst früh im Prozess automatisiert und über alle Phasen überprüft werden kann, ist Teil des neuen DevSecOps-Ansatzes. Die dahinterstehende Idee des Shift-Left geht schon im Artikel „Software Engineering Economics“ aus den 1980er Jahren von Barry Boehm zurück.
Inzwischen haben sich viele Firmen mit Scrum wieder stärker auf die schnellere Umsetzung von Fachlichkeit konzentriert. Dabei wurden auch gleich der Erstellungs-, Paketierungs-, Test- und Qualitätsprozess automatisiert. Doch auch wenn die Integration und das Deployment verbessert wurden, gab es immer noch Schwierigkeiten, die neu entwickelten Funktionen in ausreichender Qualität in Produktion zu bringen. Viele Firmen oder Produkthersteller entwickeln zwar agil, rollen Releases oft nur quartalsweise aus. Inzwischen haben populäre Produkte wie Java oder Windows nach außen keine Versionsnummern mehr, sondern nur noch den Monat und das Jahr der Veröffentlichung.
Ganz anders sieht es bei Cloud-native Firmen oder Providern aus. Hier gibt es gar keine aktuell laufende einheitliche Version, da alle Dienste und Services eigene Versionsnummern und einen eigenen Lebenszyklus haben. Oft werden aus unterschiedlichen Gründen sogar mehrere Versionen parallel betrieben. Das setzt eine viel engere Zusammenarbeit zwischen Entwicklung und Betrieb voraus.
Nach dem Amazon Motto „you built it you run it” ist das cross-funktional aufgestellte Team nicht nur für die Erstellung, sondern auch für den erfolgreichen Betrieb seiner Dienste verantwortlich. Deswegen ist das Team auch bestrebt, neue Funktionen möglichst schnell und reibungsfrei zum Kunden zu bringen, denn nur dort kann Software wirklich einen Wert generieren. So entstand die Idee des DevOps-Teams. Wie diese zusammenarbeiten, ist in jeder Firmenkultur unterschiedlich. Doch viele eint die gemeinsame Verantwortung für die dauerhafte Optimierung des gesamten Software-Entwicklungsprozesses.
Da bei der Entwicklung am Anfang die Umsetzung fachlicher User Stories im Vordergrund steht, geraten technische Qualitätsanforderungen oft in Vergessenheit. Sicherheitsexperten sind immer Mangelware und die Zahl und die Auswirkungen von bekannten Sicherheitslücken nimmt weiter zu. Ein Grund dafür sind die agile Entwicklung und die Cloud, die es ermöglicht, mit DevOps getesteten Code automatisiert in Produktion zu bringen.
Die dadurch neu gewonnene Freiheit und Flexibilität haben jedoch ihren Preis, und der ist höher, als man oft bereit ist zu zahlen. Deswegen reicht es nicht, die Umsetzung fachlicher Anforderungen zu beschleunigen, wenn nicht dafür gesorgt wird, dass die zur Nutzung notwendigen Qualitätsziele, wie z. B. Sicherheit, Robustheit oder Skalierbarkeit, nicht erreicht werden. War es bei Quartals-Releases oft noch möglich, einen extern Beauftragten Sicherheitstest durchführen zu lassen. Bei DevOps orientieren Prozessen ist das praktisch unmöglich, da sich ständig etwas ändert und damit Sicherheit noch stärker ganzheitlich als punktuell gesehen werden muss.
Daher hat sich der Gedanke von DevSecOps entwickelt, schon recht früh anzusetzen und über das Scannen des Codes und der verwendeten Abhängigkeiten Schwachstellen automatisiert zu erkennen und dadurch schneller beheben und testen zu können, bevor diese zu größeren Aufwänden („technische Schulden“) oder Problemen („zero day exploits“) führen können. Durch das Scannen z. B. der verwendeten Open Source-Bibliotheken wird als Nebenprodukt auch ein Open Source-Kompatibilitätscheck regelmäßiger durchgeführt, um zu verhindern, dass keine nicht zugelassenen Open Source-Lizenzen zum Einsatz kommen.
Neben der Minimierung des rechtlichen Risikos werden auch spätere Umbaumaßnahmen für den Austausch solcher Komponenten vermieden. Ebenso bleibt der Code immer frisch, da es ohne größeren Zusatzaufwand möglich ist, die Software parallel mit den verfügbaren aktuellen Programmiersprachen oder Bibliotheksversionen zu testen. Größere Änderungen, Fehlerkorrekturen oder Versionssprünge verlieren dadurch etwas den Schrecken. Es wird normal, diese Änderungen mit zu testen und in Produktion zu bringen. So ist es bei bekannten Sicherheitslücken nicht notwendig, die bestehende Entwicklungs-Pipeline anzuhalten, um sich auf die Behebung der kritischen Lücken zu konzentrieren. Diese werden einfach mit dem nächsten Sprint behoben.
Kontinuierlich sicherer entwickeln heißt, weniger Sicherheitslücken in der Produktion zu haben, die behoben werden müssen. Die Reaktionszeiten werden kürzer und die Software-Qualität nimmt zu. Sicherheit ist nicht umsonst. Doch Investitionen und mehr Sicherheit – sowohl der DevSecOps-Pipeline als auch in ihren einzelnen Schritten – rechnet sich schnell. Dies haben unabhängige Untersuchungen gezeigt, wie zum Beispiel der Accelerate State of DevOps Report. Dies ist vielleicht ein kleiner Anstoß, sich mit diesem immer wichtiger werdenden Thema zu beschäftigen.
Weitere Beiträge zum Thema DevSecOps:
https://puppet.com/blog/2020-state-of-devops-report-is-here/
https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
