50% weniger Fehler? DevSecOps & Best Practices

Wir alle nutzen Software im Internet. Doch wie kommt diese Software überhaupt online? Das passiert im sogenannten Deployment. Das ist der Prozess, in dem die gebaute Software ausgeliefert wird, sodass diese für uns bereitsteht. Der getrennte Entwickler-und-Operations-Prozess ist jedoch etwas in die Jahre gekommen.

DevSecOps. Dieses Wort klingt erst einmal kryptisch. Wenn man sich jedoch ansieht, woher diese Bezeichnung kommt, ergibt die Zusammensetzung durchaus Sinn. Wollte man vor einigen Jahren Software (etwa online) zur Verfügung stellen, so wurde die Software zuerst von Entwickler:innen gebaut. Wenn diese fertig war, gab es eventuell Tests auf den lokalen Rechnern in der Entwicklungsabteilung. Im Anschluss landete die Software dann auf dem Tisch der Abteilung für Infrastruktur (Operations, kurz: Ops). Die Abteilung durfte sich dann auf fünf unterschiedlichen Servern anmelden, um dort die Software zum Laufen zu bringen. Mit etwas Glück enthielt diese sogar eine brauchbare Dokumentation.

Aber welche Probleme gibt es dabei? Natürlich war es auch schon vor DevSecOps möglich, brauchbare Dokumentationen anzufertigen. Die größten Probleme liegen jedoch im abgeschlossenen Prozess an sich. Das herkömmliche Deployment sieht vor, dass durch die Entwicklung ein fertiges Produkt entsteht und leicht veröffentlicht werden kann. In der Praxis ist das allerdings nicht möglich. In der Software sind Fehler, die Entwicklung war nicht primär auf die Veröffentlichung ausgerichtet und einige Dinge funktionieren in der Produktivumgebung gar nicht erst. Dieser Aufwand für die Veröffentlichung sorgt für weniger Auslieferungen der Software. Das wiederum sorgt zumeist für noch größere Softwareänderungen zum Termin der nächsten Auslieferung. Die Anzahl der Probleme wächst.

DevSecOps soll diesen Prozess ändern. Das bisher eher bekannte DevOps ist eine Zusammensetzung aus Development und Operations. Die Wortkombination ist eine Methodik, die gleich mehrere Sachen bedeutet. So geht es etwa darum, die Kommunikationsbarriere zwischen den Entwickler:innen und dem Operations-Team zu brechen. Die Software soll somit besser für die Veröffentlichung ausgelegt sein. Aber nicht nur das soll für eine Verbesserung sorgen. Im Vordergrund steht auch die Auseinandersetzung beider Seiten mit dem jeweils anderen Wissensstand. Die Software muss so gebaut sein, dass sie auch veröffentlicht werden kann. Umgekehrt ist es für Operations auch wichtig, Software-Entwicklung zu verstehen. Vor allem für das Errichten einer Automatisierung der Infrastruktur.

Die Anforderungen für eine gute Infrastruktur werden immer anspruchsvoller. Es wird sich immer mehr auf Software verlassen. Einzelne Ausfälle sorgen für finanzielle Schäden in Millionenhöhe – durch einzelne minutenlange Unverfügbarkeit. Streikt die Online-Plattform für Rezepte, funktioniert die Küchenmaschine zu Hause nur noch eingeschränkt. Wenn die Logistik-Software ihrem Dienst nicht waltet, gibt es schwerwiegende Verzögerungen in zahlreichen Prozessabläufen auf Straßen. Betroffen sind unter anderem Lebensmittel-Transporte, die nach zu langer Wartezeit hinfällig werden. Oder die Krankenhaus-Software, die dringend für Operationen benötigt wird.

Zuverlässige Software und Infrastruktur sollte also hochverfügbar sein (High Availability, kurz: HA). Im Laufe der DevOps-Entwicklung hat sich dazu inzwischen die Cloud, sowie Continuous Integration (CI) und Continuos Deployment (CD) etabliert. Das beschreibt den Prozess, direkt nach dem Entwickeln einer einzigen Änderung diese automatisch zu verarbeiten, zu testen und zu veröffentlichen. Dafür ist keine manuelle Installation durch Operations nötig. Die Software wird automatisch mit vorgefertigten Tests geprüft und analysiert. Statt diesen Softwarestand überall gleichzeitig verfügbar zu machen, gibt es das Canary Deployment. Der Begriff stammt vom Kanarienvogel ab, der im 20. Jahrhundert dafür genutzt wurde, um in Minen schlechte Luftqualität (durch etwa Gase) bemerkbar zu machen, bevor die Bergleute unter Tage davon betroffen waren. Kurz gesagt: Das Canary Deployment soll die Veröffentlichung abbrechen, sobald Probleme auftreten. Die Infrastruktur selbst soll auftretende Probleme beheben, indem entsprechende Anwendungen und Teile der Struktur von selbst neu gestartet werden oder entsprechende Alarme auslösen.

Die selbstheilende Infrastruktur (engl. self healing) ist somit auch Teil des DevOps-Kerns. Diese ganzen Prinzipien sollen dazu beitragen, das Veröffentlichen so schnell und einfach wie möglich zu gestalten. DevOps soll die Produktivität, Verfügbarkeitsrate und mehr optimieren. Einige Beispiele aus der Realität versprechen dabei Erfolg:

"For example, Nordstrom found that after applying DevOps practices to its organization, it was able to increase the number of features it delivered per month by 100%, reduce defects by 50%, reduce lead times (the time from coming up with an idea to running code in production) by 60%, and reduce the number of production incidents by 60% to 90%. After HP’s LaserJet Firmware division began using DevOps practices, the amount of time its developers spent on developing new features went from 5% to 40%, and overall development costs were reduced by 40%. Etsy used DevOps practices to go from stressful, infrequent deployments that caused numerous outages to deploying 25 to 50 times per day, with far fewer outages.", (Brikman, 2022)

Weniger Softwarefehler, schnellere Entwicklung und reduzierte Anzahlen an Ausfällen werden genannt. Doch wenn DevOps so gut funktioniert, warum braucht es dann DevSecOps?

Was ist DevSecOps?

Während DevOps für die Kombinatorik aus Development und Operations steht, enthält DevSecOps die Komponente der Sicherheit (Security). Die Jahre haben uns gelehrt, dass die Sicherheit integraler Bestandteil der IT sein sollte. Es wird empfohlen, etwa 10% der jährlichen IT-Ausgaben in Sicherheitsmaßnahmen zu investieren (Investieren deutsche Unternehmen genügend in Ihre IT-Security?, 2024). Ohne die Sicherheit ist es nicht möglich, die Systeme hochverfügbar zu betreiben. Dafür soll von der Planung, Entwicklung und Veröffentlichung überall von Anfang die Sicherheit mit in den Prozessen eingebracht werden.

Hier greift wieder der DevOps-Leitsatz, möglichst viel zu automatisieren. So sollten bereits vor der Veröffentlichung automatisch in der Auslieferung Sicherheitsmängel ausfindig gemacht werden. Das ist zum Beispiel durch das Prüfen auf bekannte Schwachstellen in der Lieferkette möglich, als auch durch weitere Sicherheitstools. Es gibt beispielsweise Werkzeuge, die in Infrastruktur-Applikationen (Infrastructure as Code, kurz: IaC) zu lasch eingestellte Firewall-Einstellungen finden und melden.

Die Kombination dieser Hilfsmittel erlaubt es, bereits alleine durch Automationen schon die Sicherheit zu steigern. Weitere Expertise erlaubt beim Entwickeln der Software und in der Testphase weitergehend auf kritische Fehler in der Sicherheit zu prüfen. Dennoch sollte in Betracht gezogen werden, regelmäßig auch externe Prüfungen zu veranstalten.

Genau wie DevOps steht DevSecOps mehr für die Prozesse, als ein gewisses Tooling:

"DevOps and DevSecOps are more about processes than the tools used to implement those processes. Without the cultural fit and changes to process, the tooling used in DevSecOps often gets in the way of progress and sometimes slows development down.", (Suehring, 2024)

Bei DevSecOps müssen alle an einem Strang ziehen. Es hilft nicht, wenn bei den ersten kleinen Problemen doch wieder in getrennten Wegen gedacht wird. Die Arbeit der DevSecOps-Komponenten gehört zusammen, um die Probleme eines integrierten und sicheren Software-Deployments zu ermöglichen und die Vorteile dieser Methodik in Anspruch zu nehmen.

Best Practices

Im Bereich der DevOps und DevSecOps gibt es einige Best Practices. Diese sollen die Arbeit erleichtern und die Zeit der Systemverfügbarkeit erhöhen. Sie bilden wichtige Prozesse in der Kultur der Methodik ab und sorgen für einen funktionierenden Ablauf der Software-Entwicklung, als auch der sicheren Bereitstellung.

Automation

Sowohl in DevOps, als auch in DevSecOps ist Automatisierung das A und O. Automationen erlauben es, nervige Aufgaben einfach von Maschinen übernehmen zu lassen, fehleranfällige Prozesse durch die Reduzierung menschlicher Interaktionen abzusichern und die (vielleicht sogar plötzliche) Skalierung der Systeme zu ermöglichen. Wenn es machbar ist, etwas zu automatisieren, was als regelmäßige Aufgabe wiederkehrt, dann sollte dies getan werden. Ansonsten verschwendet man die eigene Zeit damit, etwas zu machen, was längst nicht mehr nötig wäre. Ein Beispiel dafür ist eine Story aus der Literatur "Python for DevOps":

"'You will script yourself out of a job, kid!' The boss’s boss was also unhappy. He had advocated to management for months to get a maintenance team approved, and then I wrote a script that eliminated much of what our department did. He also yelled at me profusely.
[...]
So, yes, you can script yourself out of a job and right into a better one!", (Gift et al., 2020)

Monitoring

Automationen können immer schieflaufen. Fehler gibt es in Systemen immer. Es gibt allerdings einige Möglichkeiten, Probleme direkt bei ihrem Auftritt zu erkennen, zu warnen und diese mithilfe dieser Möglichkeiten schneller zu beheben. Dazu benötigt es Monitoring. Das bezeichnet verschiedene Vorgehensweisen, die eigenen Systeme zu beobachten. Etwa, wenn die Leistung der Server unerwartet ansteigt, Netzwerkverbindungen plötzlich abbrechen, die Speichernutzung sich unvorhergesehen ändert und vieles Weitere. Dazu werden unter anderem Metrik-Server genutzt, die Metriken verschiedener Systeme entgegennehmen und zusammenführen können. Durch das Beobachten der eigenen Systeme können auch bereits beim Deployment Probleme identifiziert werden und die Veröffentlichung für die Öffentlichkeit abbrechen. Ebenfalls ist Monitoring ein fundamentaler Bestandteil für die Security eines Systems, um Cyberangriffe überhaupt erst erkennen zu können.

Alerts

Fällt im Monitoring etwas Besonderes auf (fehlende Netzwerkverbindungen, angestiegener Leistungsabruf, …), kann ab gewissen Schwellwerten ein Alarm an handlungsfähige Personen abgegeben werden. Es sollte allerdings strengstens darauf geachtet werden, diese Alarme wirklich nur in echten Fehlerfällen auszusenden. Niemand möchte unbegründet um 2 Uhr nachts geweckt werden. Denn Netzwerkabbrüche können schon einmal vorkommen, Alarme sollten nicht direkt bei einem einzigen Paketverlust abgegeben werden. Im Weiteren ist es möglich, über Machine Learning normale Nutzungsweisen im Monitoring zu erkennen und erst bei Abweichungen von diesen zu alarmieren.

Logging

In der Annahme, dass durch das Monitoring Probleme auffallen, ist es nötig, diese auch identifizieren zu können. Das Monitoring kann dabei helfen, die Fehlerkomponente festzustellen. Was der Fehler dieser Komponente ist, muss durch Logging ermittelt werden. Deshalb sind eindeutige Fehlermeldungen und ein eindeutiges Logging in Systemen nötig. Sie sollten herausstellen können, an welchem Punkt der Fehler unter welchen Bedingungen (Parametern) auftritt. Mehrere Logging-Level ermöglichen es, auf unterschiedlichen Ebenen Fehler zu untersuchen und überflüssige Informationen bei zu großem Speicherbedarf zu unterdrücken. Logs sollten an einer zentralen Stelle zusammengeführt werden, um automatisches Monitoring mittels dessen durchführen zu können und Problemen auf die Spur zu rücken.

Testing

Automatische Tests spielen sowohl in DevOps, als auch in DevSecOps eine wichtige Rolle. Um es noch einmal klarer auszudrücken:

"Infrastructure code without automated tests is broken.", (Brikman, 2022)

Das gilt nicht nur für automatisierte Infrastruktur, sondern für den gesamten DevSecOps-Prozess. Ist die Software nicht getestet, könnte diese enorme Probleme verursachen. Ist die Infrastructure as Code-Komponente nicht getestet, könnte dies fatale Folgen haben, wie versehentlich gelöschte Datenbanken in der Cloud. Auch in der Security sind jede Menge automatische Tests möglich, die die Grundlage für eine vertrauenswürdige Anwendung bieten.

Immutability

Systeme sollten so entwickelt werden, dass diese dynamisch skalieren können. Eine gewisse Optimierung für die Cloud (u.U. auch die Private Cloud intern) ist in diesem Fall wichtig. Software sollte so gebaut werden, dass diese (in den meisten Fällen) containerisiert ausführbar ist und in diesem Container nichts persistent speichert. Für die persistente Speicherung sind hochverfügbare Datenbanken und Object Storages (z.B. S3, MinIO, ...) verantwortlich. Das ermöglicht es, Container nach Nachfragebedarf hoch- und herunterfahren zu können.

Kommunikation

Die Kommunikation zwischen Entwickler:innen und dem Ops-Team ist entscheidend. Das auch bereits während der Planung. Fehler sollten von allen Seiten aus offen angesprochen werden können. Auch der Austausch mit Security-Expert:innen ist wichtig.

Isolation

Es sollte aufgefallen sein, dass Systeme immer fehlerhaft sein können (und es auch sind). Deshalb sollten Systeme möglichst nicht zu stark mit anderen Systemen gekoppelt sein. Sie sollten eine möglichst lose Bindung aufweisen. Einzelne Punkte, von denen die ganze Funktionsweise abhängt, sind Single Points of Failures. Diese sollten vermieden und möglichst ganz umgangen werden. Dazu gibt es Möglichkeiten, Systeme in der Cloud etwa in unterschiedliche virtuelle Netzwerke und Projekte zu verstauen. Test-, Produktions- und Staging-Umgebungen sollten hart voneinander getrennt sein. Für wirklich große Systeme mit vielen Nutzer:innen kann sich auch das Veröffentlichen in unterschiedlichen Data Centers lohnen. Verteilt werden die Nutzer:innen auf diese dann via Load Balancers.

Unterschiedliche Deployment-Infrastruktur sollte jedoch möglichst gleich gehalten werden. Eine Multi-Cloud-Infrastruktur ist oft sehr umständlich und häufig nicht empfehlenswert. Die Hürden, die durch die unterschiedliche Infrastruktur entstehen, können die ganze Entwicklung wieder ausbremsen.

Backups

Backups sind in der IT mitunter der wichtigste Bestandteil. Sie sollten häufig, regelmäßig, automatisch und sicher getätigt werden. Werden sie etwa nicht automatisch getätigt, so fällt diese wichtige Aufgabe meist unter den Tisch. Läuft jedoch eine Automation einmal erheblich schief oder es gibt Probleme in der Cloud, so könnte dies zu einem katastrophalen Datenverlust führen. Dementsprechend sollten Backups (auch) außerhalb der Cloud gespeichert werden. Tests für diese sind ebenfalls unabdinglich. Im besten Fall werden Backups automatisch von externen Systemen gezogen (gepullt). Sollte es einmal zu einem Cyberangriff mit einer Daten-Verschlüsselung (Ransomware) kommen, so sollten die eingenommenen Systeme keinen Zugriff auf die Backups erhalten.

Feature Toggling

Um neue Funktionen auszuspielen, kann das sogenannte Feature Toggling hilfreich sein. Das ist eine Möglichkeit, Funktionalitäten dynamisch ein- und auszuschalten. Das ist für verschiedene Nutzer:innen separat wählbar. So können etwa neue Funktionalitäten vorerst nur an kleine Gruppen ausgespielt werden, bevor Millionen an Nutzer:innen auf ein defektes System treffen. Zwar ist es auch möglich, Softwareupdates ohne Feature Toggling im Nachhinein rückgängig zu machen, arbeiten jedoch viele Leute an mehreren Funktionalitäten gleichzeitig, die nacheinander ausgespielt wurden, so würden die nachfolgend ausgespielten Änderungen (und möglicherweise neuere Fehlerbehebungen) auch rückgängig gemacht werden.

Dokumentation

Gerade bei jeglichen Automationen lässt sich schnell der Überblick verlieren. Es sollte somit festgehalten werden, welche Automationen es wo gibt, warum und was diese leisten sollen. Über die Dauer der Systeme hinweg ändert sich häufig das Umfeld drumherum. Läuft das System in zehn Jahren noch, so sollten die entsprechenden Verantwortlichen (neue Leute?) weiterhin wissen, wie die Technik um sie herum funktioniert.

Version Control System

Automationen, die auf Servern laufen, aber nicht über Versionierungssysteme (wie GitHub, GitLab, etc.) verewigt wurden, gehen irgendwann kaputt. Problematisch ist dann, dass sich niemand mehr mit dem System auskennt, weil zum einen, keine Dokumentation vorhanden ist. Zum anderen ist diese Automation praktisch nur noch als ein Geist der Zeit existent, der irgendwann im Laufe seines Spukes Schaden anrichten wird, der für unschöne Überraschungen sorgt.

Zusammenfassung

DevSecOps ist die logische Weiterbildung der DevOps-Entwicklung. Software muss sicher sein, damit die Bestrebungen von DevOps ermöglicht werden. Die IT-Sicherheit wird immer relevanter, dementsprechend sollte sie von Grund auf mit in den gesamten Software-Deployment-Prozess aufgenommen werden.

Literatur

Brikman, Y. (2022). Terraform: Up & running: writing infrastructure as code (Third Edition). O’REILLY.
Gift, N., Behrman, K., Deza, A., & Gheorghiu, G. (2020). Python for DevOps (Second Edition). O’REILLY.
Investieren deutsche Unternehmen genügend in Ihre IT-Security? (2024, Juli 9). https://www.demandsoftware.de/news/174-investieren-deutsche-unternehmen-genuegend-in-ihre-it-security#
Suehring, S. (2024). Learning DevSecOps (First Edition). O’REILLY.