DevSecOps - Prof. Dr. Norbert Pohlmann

DevSecOps

Inhaltsverzeichnis

Was ist unter DevSecOps zu verstehen?

DevSecOps ist ein Ansatz, IT-Sicherheit stärker in die frühe Software-Entwicklung einzubinden. Wie bei dem verwandten DevOps-Ansatz sollen die sonst zeitlich und organisatorisch entzerrten Stufen der Entwicklung und des Betriebs von Software in einen direkteren Zusammenhang gebracht werden. Während in klassischen Entwicklungsmodellen die Sicherheit der Software oft nur nachgelagert und untergeordnet betrachtet wurde, stellt sie bei der Umsetzung von DevSecOps einen integralen Bestandteil des Entwicklungszyklus dar.

Abgrenzung zu klassischer Entwicklung

In klassischen Software-Projekten wird häufig eine starke Trennung zwischen den Teams für die Entwicklung der Software sowie deren Betrieb vorgenommen. Sobald eine neue Version der Lösung fertiggestellt wurde, wird es aus dem Entwicklungsteam an das nächste Team übergeben. Hierbei handelt es sich oft um die Qualitätssicherung, die sich um das Testen der Software kümmert und eine Freigabe erteilt oder Feedback an die Entwicklung gibt, welche Fehlerbehebungen oder Anpassungen am Produkt vorgenommen werden müssen. Nach einer Freigabe des Produktes wird dieses oft an ein weiteres Team übergeben, das die Software in Betrieb nimmt und überwacht.

Sicherheitsüberprüfungen finden in diesem Ansatz meist während der Qualitätskontrolle sowie in einer Vorstufe des Betriebs, beispielsweise in Form von Penetration-Tests in Staging-Umgebungen, statt. Sicherheitsvorfälle werden über einen vergleichbaren Prozess an Entwicklung oder Betrieb zurückgegeben. Sie werden als Events erfasst, analysiert und in Tickets überführt, die anschließend durch Bugfixes oder angepasste Konfigurationen und Richtlinien behoben oder eingedämmt werden.

DevOps

DevOps bezeichnet einen Ansatz, in dem Entwicklung und Betrieb von Software stärker miteinander verbunden werden. Anstatt mehrere Teams zu verwenden, die sich um reine Entwicklungstätigkeiten oder den Betrieb – gegebenenfalls von mehreren Produkten – kümmern, ist oft ein einzelnes Team für Entwicklung (Development) und Betrieb (Operations) eines einzelnen Produktes zuständig.

In der Regel wird in DevOps-Teams ein hoher Automatisierungsgrad angestrebt, der durch kontinuierliche Integration und fortlaufende Bereitstellung (Continuous Integration, Continuous Delivery, CI/CD) dafür sorgt, dass Release-Zyklen im Vergleich zu klassischen Software-Produkt-Lieferungen deutlich schneller und häufiger passieren. Häufig wird jede Nacht der aktuelle Entwicklungsstand der Software automatisch erstellt und bei Bedarf in Betrieb genommen (sogenannte Nightly Builds).

Der starke Fokus auf automatisierte Abläufe ermöglicht die häufige Inbetriebnahme der Software, ohne starken negativen Einfluss auf die Produktivität der Teams. Neben der schnelleren Bereitstellung von neuen Funktionalitäten wirkt sich auch das häufige Durchführen von Tests positiv aus. So können Probleme schon während der Entwicklung und bei jedem Feature aufgedeckt werden und nicht erst, wenn eine neue Version mit mehreren Features fertiggestellt wurde.

Kommt es trotzdem zu Problemen im Betrieb der Software, dauert es meist weniger lange, bis diese in das Entwicklungsteam kommuniziert werden. Somit können sowohl Patches schneller entwickelt als auch bereitgestellt werden.

DevSecOps – Erweiterung des DevOps-Ansatzes um stärker fokussierte IT-Sicherheitsaspekte

IT-Sicherheit wird in vielen Bereichen der Software-Entwicklung leider noch immer als ein untergeordneter Punkt missverstanden. Mangelndes Fachwissen, aber auch Termindruck bei der Einhaltung von klassischen Release-Zyklen können dazu führen, dass Schwachstellen in Software unnötig lange enthalten sind. Die kontinuierliche Entwicklung und Bereitstellung, die durch den DevOps-Ansatz verfolgt wird, kann an diesen Punkten deutliche Vorteile für die Sicherheit von Software mit sich bringen.

Der DevSecOps-Ansatz geht hierbei noch einen Schritt weiter und legt einen besonderen Fokus auf die IT-Sicherheit. Neben Unit-, Integration- und anderen funktionsbasierten Tests werden auch explizit Sicherheitstests durchgeführt.

Oft wird dabei auf Automatisierung in Form von Pipelines aufgebaut, die schon bei jedem Commit in ein Code-Repository ausgelöst wird. So werden teilweise schon bevor eine Funktionalität fertig implementiert wurde, verschiedene Qualitätssicherungsmaßnahmen wie eine statische Code-Analyse (Static Application Security Testing, SAST) durchgeführt, in der beispielsweise versehentlich im Quellcode hinterlassene sensitive Informationen wie Passwörter gesucht oder potenzielle Schwachstellen wie für Pufferüberläufe anfällige Code-Bereiche ermittelt werden. Zusätzlich können die Abhängigkeiten der Software auf bekannte Schwachstellen geprüft und damit Probleme aufgedeckt werden, die nicht durch den eigenen Code verursacht werden.

An bestimmten Punkten, beispielsweise wenn ein fertiggestelltes neues Feature in den aktuellen (Haupt-)Entwicklungsstand der Software eingebracht wird oder wenn eine neue Version veröffentlicht werden soll, kann zudem eine aufwändigere dynamische Code-Analyse durchgeführt werden. Hierbei wird die Software in einer dedizierten Umgebung ausgeführt und zur Laufzeit untersucht, um beispielsweise Speicherprobleme und andere klassische Schwachstellen aufzudecken. Eingesetzt werden hier auch oft Werkzeuge und Methoden, die auch von Angreifern verwendet werden, unter anderem SQL-Injections, Cross-Site-Scripting oder die dynamische Änderung von Daten während ihrer Verwendung.

Ein frühes Feedback über die potenziellen oder sogar schon bestehenden sicherheitsrelevanten Probleme schafft ein erhöhtes Sicherheitsbewusstsein und hilft den Entwicklungsteams die Sicherheit von Software von Anfang an zu berücksichtigen.

Vorteile

Sicherheit von Anfang an im selben Team
Um erfolgreich Sicherheitstests durchzuführen, müssen diese umgesetzt werden. Da das beim DevSecOps-Ansatz in der Regel schon in den Entwicklungs-Pipelines umgesetzt wird, ist das gleiche Team für Entwicklung, Sicherheitstests und Betrieb verantwortlich. Sicherheitsvorfälle und potenzielle Probleme können somit einfacher analysiert und behoben werden.
Kontinuierliche Sicherheitsüberprüfung
Viele Sicherheitstests werden kontinuierlich und automatisiert durchgeführt, sodass potenzielle Probleme frühzeitig erkannt werden könnnen, ohne dass diese erst bei der Abgabe der Software durch ein anderes Team aufgedeckt werden.
Security by Design
Die Einbindung von sicherheitsspezifischen Überprüfungen führt zu einem direkten Feedback für die Software-Entwicklung. Um der Überprüfung stand zu halten, sind Sicherheitsaspekte schon von Anfang an mitzuberücksichtigen. Die häufige Analyse auf Schwachstellen sorgt zudem für einen verstärkenden Effekt, sodass die IT-Sicherheit bei jeder Erweiterung der Software mitgedacht werden muss.
Awareness und Schulung von Entwicklern
Frühzeitiges Feedback, insbesondere durch fehlschlagende Tests, sowie der explizite Charakter von DevSecOps führt zu einer stärkeren Awareness von Entwicklern. Sicherheit ist nicht mehr nur ein Teil der Qualitätskontrolle, der nach der Lieferung der Software an das QA-Team beachtet wird, sondern besitzt schon vor dem Abschluss der Entwicklung von Features eine erhebliche Relevanz. Zusätzlich kann sich ein Schulungs-Effekt einstellen, beispielsweise wenn Entwickler Informationen über von ihnen eingeführte Schwachstellen erhalten und diese beheben müssen. Damit wird die IT-Sicherheits-Kompetenz insgesamt gesteigert.
Potenziell langfristig Einsparung von Kosten
Ausgenutzte Schwachstellen können zu erheblichen Schäden führen, insbesondere im finanziellen Bereich. Durch frühzeitige Erkennung und Behebung von Schwachstellen kann das Risiko dafür reduziert werden. Aber auch im Bereich der Prozessoptimierung kann ein DevSecOps-Ansatz für eine langfristige Einsparung von Kosten sorgen. So wird beispielsweise potenziell die Anzahl von Beauftragung von internen oder externen Penetrationstestern reduziert.

Nachteile

Initialer Aufwand
Bevor automatisierte Tests und Inbetriebnahmen genutzt werden können, müssen die entsprechenden Pipelines zunächst entwickelt werden. Im Vergleich zu einer klassischen Entwicklungsumgebung ist hierfür meist ein erheblich höherer Initialaufwand notwendig. Auch wenn langfristig die Kosten potenziell stark reduziert werden können, müssen für die Einrichtung entsprechende Ressourcen, beispielsweise in Form von Zeit und Geld, bereitgestellt werden. Daher sollte bei der Projektplanung mitberücksichtigt werden, ob die jeweiligen Gegebenheiten für diesen Ansatz sprechen.
Kompetenzen müssen entwickelt werden
Dev(Sec)Ops anzuwenden ist mit entsprechendem Know-How verbunden. Gerade in Unternehmen, die bisher nur klassische Software-Entwicklung betrieben haben, sind die notwendigen Kompetenzen unter Umständen nicht vorhanden. Daher muss bei einem Umstieg darauf geachtet werden, dass eventuell Fachpersonal eingestellt oder ausgebildet werden muss.
Potenziell höhere Ressourcenkosten
Der langfristigen potenziellen Kostenreduktion durch einen Dev(Sec)Ops-Ansatz stehen nicht nur die initialen Kosten entgegen. Die Ausführung von Pipelines ist mit zusätzlichen Ressourcen verbunden, beispielsweise in Form von CPU-Zeit bei Kompilation und Tests sowie Netzwerk-Traffic beim Übertragen der Software und der Inbetriebnahme. Hierfür müssen die entsprechenden Bedingungen geschaffen werden. Insbesondere bei größeren Software-Projekten können hierbei häufig ganze Cloud-Infrastrukturen aufgebaut und wieder entfernt werden.