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 Beteiligten die sonst zeitlich und organisatorisch entzerrten Stufen der Entwicklung und des Betriebs von Software enger miteinander verbinden. DevSecOps integriert die Sicherheit in den gesamten Entwicklungszyklus. Bei klassischen Entwicklungsmodellen wird die Sicherheit der Software oft nur nachgelagert und untergeordnet behandelt.

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 ist, übergibt das Entwicklungsteam die Software an das nächste Team. Dabei 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 übergibt das Team die Software häufig an ein weiteres Team, 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.

DevOps-Teams streben in der Regel ein hohen Automatisierungsgrad an. Durch kontinuierliche Integration und fortlaufende Bereitstellung (Continuous Integration, Continuous Delivery, CI/CD) verkürzen sie die Release-Zyklen im Vergleich zu klassischen Software-Produkt-Lieferungen deutlich. Häufig erstellt das Team jede Nacht automatisch den aktuelle Entwicklungsstand der Software und nimmt ihn bei Bedarf in Betrieb (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 sie Probleme schon während der Entwicklung und bei jedem Feature aufdecken und müssen nicht erst warten, bis eine neue Version mit mehreren Features fertiggestellt ist.

Wenn trotzdem Problemen im Betrieb der Software auftreten, informiert das Team das Entwicklungsteam meist schnell darüber. Somit können die Entwickler sowohl Patches schneller entwickeln als auch bereitstellen.

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 bauen die Teams dafür automatisierte Pipelines auf, die schon bei jedem Commit in ein Code-Repository ausgelöst werden. So führen sie teilweise schon bevor eine Funktionalität fertig implementiert wurde, verschiedene Qualitätssicherungsmaßnahmen wie eine statische Code-Analyse (Static Application Security Testing, SAST) durch, in der sie beispielsweise versehentlich im Quellcode hinterlassene sensitive Informationen wie Passwörter suchen oder potenzielle Schwachstellen wie für Pufferüberläufe anfällige Code-Bereiche ermitteln. 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 eingeflossen ist oder wenn eine neue Version veröffentlicht werden soll, führen die Teams eine aufwändigere dynamische Code-Analyse durch. 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
Die Teams führen viele Sicherheitstests kontinuierlich und automatisiert durch, sodass sie potenzielle Probleme frühzeitig erkennen können, ohne dass ein anderes Team diese erst bei der Abgabe der Software entdeckt.
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 betrachten die Entwickler nicht mehr nur als ein Teil der Qualitätskontrolle, die das QA-Team nach der Lieferung der Software beachtet, 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 steigern sie die IT-Sicherheits-Kompetenz insgesamt.
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 könen Unternehmen das Risiko reduzieren. 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 Teams automatisierte Tests und Inbetriebnahmen nutzen können, müssen sie zunächst die entsprechenden Pipelines entwickeln. Im Vergleich zu einer klassischen Entwicklungsumgebung ist hierfür meist ein erheblich höherer Initialaufwand notwendig. Auch wenn die Teams langfristig die Kosten potenziell stark reduzieren können, müssen sie für die Einrichtung entsprechende Ressourcen, beispielsweise in Form von Zeit und Geld, bereitstellen. 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.