Coloures-pic - Fotolia
DevOps-Revolution: Warum DevSecOps ein falscher Begriff ist
Security sollte bei der Softwareentwicklung kein getrenntes Element sein und hinzugefügt werden, sondern ein integraler Bestandteil von allem sein, was DevOps bedeutet.
Das vergangene Jahrzehnt hat den Weg für eine DevOps-Revolution geebnet, weil die Entwicklungszyklen von Programmen stetig kürzer werden. Neue Software- und Anwendungsveröffentlichungen sind zu einem fortlaufenden Prozess geworden, während dessen kontinuierlich neuer Code geschrieben wird. Aus diesem Grund haben sich DevOps-Teams von dem traditionellen, Silo-artigen Ansatz gelöst und einen großen Teil der Entwicklung von Anwendungen selbst in die Hand genommen, einschließlich der Qualitäts-Sicherung, Integration und Bereitstellung (CI/CD-Modell).
Ein wichtiger Bereich bleibt jedoch bislang außen vor und DevOps-Gruppen übernehmen dafür keine Verantwortung – die Sicherheit. Jedoch entwickelte sich mit der neuen DevSecOps-Idee sowohl ein falscher Begriff als auch eine falsche Vorstellung davon, wie die Sicherheit künftig eingebunden sein sollte.
Überkommene Denkmuster ablegen
In der alten Welt der App-Entwicklung waren die Entwickler lediglich dafür verantwortlich, neuen Code zu schreiben, um eine bestimmte Funktion ausführen zu können. Die Qualität des Produkts stand nicht in ihrem Fokus, denn dies lag in der Verantwortung der Qualitätsprüfer. Da diese Arbeitsweise jedoch nicht mehr aufrecht zu erhalten war, wegen der schnelleren Entwicklungszyklen von Anwendungen, entstand das DevOps-Modell. Wegen der Fortschritte bei der Cloud-Umgebung, der Container-Nutzung und der Microservices müssen Anwendungen nicht mehr ständig an andere Abteilungen übergeben werden, sondern können von ein und demselben Team erstellt und abgesegnet werden. Dies überträgt DevOps-Gruppen die Verantwortung für das Produkt in Bezug auf Benutzererfahrung, Geschwindigkeit und Ausfallsicherheit.
Die geistige Haltung zur Sicherheit ist jedoch noch in der „alten Welt“ stecken geblieben. Obwohl DevOps nun Verantwortlichkeiten übernommen hat, die zuvor anderen Abteilungen unterlagen, um den fortlaufenden Zyklus von Programmveröffentlichungen effizienter zu gestalten, herrscht nach wie vor der Glaube, dass die Sicherheitsabteilung allein für den Schutz der neuen DevOps-Produkte zuständig ist. Dies mag in einer angewöhnten Struktur innerhalb des Unternehmens begründet sein, jedoch wird die DevOps-Revolution erst dann abgeschlossen sein, wenn die Sicherheit vollständig in die Entwicklung neuer Programme und Produkte integriert ist.
„DevOps muss die Sicherheit als Kern der Software-Qualität und -Leistung anerkennen.“
Christine Schönig, Check Point Software Technologies GmbH
Eigentlich sollte das in vielerlei Hinsicht selbstverständlich sein: Da DevOps sich nun um die Produktqualität kümmert und dafür verantwortlich ist, dass die Anwendungsleistung optimal ist, dann sollte die Mannschaft auch sicherstellen, dass der Code keine bekannten Bugs oder Hintertüren enthält, welche die Sicherheit beeinträchtigen würden, denn: Ein Produkt ist nicht für seinen Zweck geeignet, wenn es die von ihm erwartete Funktion unsicher erfüllt. Das Gleiche gilt für eine Website, die einfach von Hackern geknackt werden kann, weil vor der Veröffentlichung nicht genug zu ihrem Schutz getan wurde.
Sicherheit ist keine Last, sondern ein Qualitätssiegel
Oft verfügt die Sicherheitsabteilung zwar über eine große Präsenz im Unternehmen und deshalb hat sich die DevOps-Gruppe bislang gerne in Bezug auf diesen Aspekt im Stuhl zurückgelehnt. Doch die Sicherheit ist ein wesentlicher Bestandteil der Produktqualität und gehört daher nun zu ihrem Aufgabenfeld. Wenn die Internetseite oder die Anwendung, die ein Mitarbeiter oder Kunde aufruft oder startet, von Hackern infiziert wurde, wird häufig DevOps verantwortlich gemacht, nicht die Sicherheitsabteilung. Daher gilt: Zu behaupten, dass DevOps sich nicht darum kümmern müsse, wie sicher ihr Code ist, weil eine andere Gruppe sich schon des Problems annehmen wird, klingt so, als würde ein Planungsstab die Kosten eines Projekts vernachlässigen, weil es eine Finanzabteilung gibt.
Es ist daher wichtig, die Sicherheit nicht mehr als eine zusätzliche Last der Software-Entwicklung zu sehen, sondern DevOps sollte dies als eine Gelegenheit betrachten, die eigene Autorität und Reichweite innerhalb des Konzerns auszubauen. So müssen die DevOps-Teams nicht mehr auf andere Abteilungen warten, sondern können von Anfang an in ihrem eigenen zeitlichen Rahmen sicheren Code schreiben, konfigurieren und bereitstellen. Schließlich sind diese Fachleute am besten in der Lage, um zu verstehen, welche Werkzeuge in den frühen Phasen der Programmierung am nützlichsten sind. Genau besehen holen sich die Entwickler über diesen Ansatz mehr Selbstständigkeit an Bord.
Engere Zusammenarbeit zwischen Sicherheitsabteilung und Entwicklern nötig
In der Vergangenheit kam es oft vor, dass Sicherheitsfunktionen den Entwicklern und dem gesamten Unternehmen schlecht präsentiert wurden. Gleichzeitig haben sich das Risiko und die Bedrohungen des Unternehmens und seiner Online-Präsenz exponentiell vervielfacht und die Unternehmen schienen gezwungen zu sein, mit immer komplexeren Sicherheitslösungen zu reagieren, wodurch die IT-Sicherheit zu einer eigenen Disziplin und sogar einer eigenen Branche wurde. Das wiederum führte dazu, dass andere IT-Beteiligte, wie die Entwickler, oft das Gefühl hatten, dass die Sicherheit zu weit außerhalb ihrer Zuständigkeit tätig war.
Angesichts des bekannten Mantras aber, dass Vorbeugung besser ist als Abhilfe, und der Tatsache, dass die Sicherheit mehr Shift-Leftd-Praktiken annehmen muss, um wirklich effektiv zu sein, könnten DevOps überrascht sein, wie empfänglich die hauseigene Sicherheitsabteilung dafür wäre, die Verantwortung zu teilen und enger zusammenzuarbeiten. Die Sicherheitsleute können zwar weiterhin wichtige Teile des DevOps-Prozesses überwachen und Einfluss darauf nehmen, müssen aber nicht mehr mit Code konfrontiert werden, der bereits unter Berücksichtigung der Sicherheit geschrieben wurde.
Fazit
Schlussendlich bedeutet dies: DevOps muss die Sicherheit als Kern der Software-Qualität und -Leistung anerkennen. Es gibt schon deutliche Anzeichen einer Bewegung in diese Richtung, insbesondere mit dem Aufkommen der sogenannten DevSecOps-Idee. Jedoch ist dies genau betrachtet ein falscher Begriff, denn Sicherheit sollte kein separates Element sein, das der Entwicklung als weiterer Schritt hinzugefügt und innerhalb des DevOps-Prozesses hervorgehoben wird – sie sollte vielmehr ein integraler Bestandteil von allem sein, was DevOps bedeutet und täglich tut. Solange dies nicht der Fall ist, wird die DevOps-Revolution stagnieren und unvollständig sein.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
