Was sich hinter Sicherheit im DevOps-Prozess verbirgt DevSecOps und DevOpsSec im Vergleich

Anbieter zum Thema

OutSystems

Qualys GmbH

Vergleicht man DevSecOps oder DevOpsSec, sind die Namen nicht nur Schall und Rauch. Hinter den Abkürzungen verbergen sich zwei grundlegend verschiedene Ansätze, DevOps und Sicherheit miteinander zu verzahnen. Doch welche Unterschiede gibt es genau?

William Shakespeare schrieb in Romeo und Julia: „Was ist ein Name? Was uns Rose heißt, wie es auch hieße, würde lieblich duften“. Die Realität sieht jedoch anders aus, die richtige Bezeichnung für ein Produkt, ein Team oder eine Initiative kann wesentlich über Erfolg oder Misserfolg entscheiden.

Dies geht so weit, dass der falsche Ansatz für die Markenbildung auch große finanzielle Auswirkungen haben kann. Kraft Heinz hat im Februar 2019 eine Abschreibung in Höhe von 15 Milliarden US-Dollar auf den Wert seiner bekanntesten Marken angegeben. Dies deutet darauf hin, dass die Vermarkter auf kurzfristige Aktivierung auf Kosten der langfristigen Markenbildung setzen.

Aber warum ist dies für IT-Sicherheitsteams von Bedeutung? Warum sollten sie sich darum kümmern, wie die Dinge genannt werden? Weil es die Einstellung dazu verändert, wie und wo die IT-Sicherheit gehandhabt wird und schlussendlich zum Erfolg beiträgt.

Sicherheit – Teil von DevOps oder Controlling-Funktion?

DevOps konzentriert sich darauf, wie Änderungen an einer Anwendung optimiert und schneller in die Produktion gebracht werden können. Dabei ist es von wesentlicher Bedeutung, dass die IT-Sicherheit in diesen Prozess einbezogen wird. Es ist leicht, Sicherheitsaspekte im Nachhinein anzusprechen, doch ist es dann nicht bereits zu spät?

Für Entwickler steht die IT-Sicherheit nicht im Vordergrund, wenn es darum geht, Anwendungen zu erstellen oder zu ergänzen. Laut dem Global Developer Report von GitLab bewerteten nur 25 Prozent der Entwickler die Sicherheit in ihrer Organisation als „gut“. Im Gegensatz dazu stimmten 50 Prozent zu, dass Sicherheitsschwachstellen meist vom Sicherheitsteam nach dem Zusammenführen von Code in einer Testumgebung entdeckt werden. Das kostet Zeit und Geld.

Sicherheitsteams sind nicht die Schuldigen

Die Security-Experten müssen in den Software-Development-Prozess eingebunden werden, um den Entwicklern zu helfen, sicheren Code zu produzieren. An erster Stelle steht das Verhindern von Schwachstellen, welche bereits in der Produktion entstehen können. Wird dies bereits in die Planung mit aufgenommen, so lassen sich Fehler vermeiden.

An dieser Stelle wird die Namensgebung entscheidend, denn es gibt mehrere Begriffe dafür, wie Sicherheit in DevOps eingebettet wird. DevSecOps und DevOpsSec klingen dabei zwar ähnlich, sind jedoch nicht ohne Weiteres austauschbar.

DevSecOps positioniert die Sicherheitsfunktion als Teil der gesamten Software-Pipeline. Dabei ist Sicherheit Teil des Wertschöpfungsprozesses von der Software-Entwicklung bis in die Produktion, also eine Station auf dem Weg zum Ziel. Auf der anderen Seite positioniert DevOpsSec die Sicherheitsfunktion als verantwortlich für die Sicherheit im gesamten Prozess, von Anfang bis Ende. Beide Ansätze haben ihre Vor- und Nachteile.

DevSecOps ist schneller zu implementieren, da es sich direkt in den Entwicklungsprozess einbinden lässt. Es kann die Implementierung von Sicherheit während der Entwicklung erleichtern, da es wie ein zusätzliches Modul funktioniert. Es kann zusätzlich den Zugang zu neuen „Builds“ beschleunigen und deren Sicherheit vor der Produktion prüfen.

Langfristig gesehen kann DevSecOps jedoch einschränkend wirken: Das Sicherheitsteam kann zwar schnell eingreifen, ist aber auf eine bestimmte Zeit und Rolle im Prozess festgelegt und nicht während des gesamten Entwicklungsprozesses involviert. Wenn sich ein Problem manifestiert, sobald das Software-Projekt in die Produktion übergeht, kann es schwieriger sein, dessen Herr zu werden.

Umgekehrt beinhaltet DevOpsSec die Betrachtung des gesamten Prozesses – und wie Sicherheit in allen Phasen der Softwareentwicklung und -bereitstellung umgesetzt werden kann. Anstatt auf einen bestimmten Zeitpunkt eingeschränkt zu sein, arbeiten die Sicherheitsteams daran, Sicherheit verfügbar zu machen und von den Entwicklern als Teil ihrer Arbeitsabläufe zu nutzen. Dazu gehört die Integration aller Werkzeuge, die sich mit Schwachstellen, Sicherheitsscans oder Infrastruktur befassen, in die Arbeitsweise der Entwickler.

Entwicklungsteams müssen dazu einige ihrer Arbeitspraktiken ändern, was zu Unmut führen könnte. Es macht es jedoch einfacher, die Sicherheit im Laufe der Zeit zu gewährleisten, da es sich um einen kontinuierlichen Prozess handelt und nicht um ein Stadium, das die Software durchläuft. Dies macht die Sicherheit zu einem Teil der Aufgabe des Entwicklers, anstatt ein Hindernis zu sein, das es zu überwinden gilt. Es fördert auch die Zusammenarbeit im Laufe der Zeit, um die Software-Praktiken zwischen allen beteiligten Teams zu verbessern. Auf lange Sicht ist dies der effizientere Ansatz.

Langfristiges Denken über DevOps und Sicherheit

Für Sicherheitsexperten ist es unerlässlich, sich in die Denkweise der Benutzer hineinzuversetzen. Besonders für Entwickler ist es nützlich, einen Blick für Sicherheitsimplementierung im Arbeitsablauf zu schulen. Indem es den Entwicklern erleichtert wird, Probleme zu erkennen und zu beheben, bevor sie auf die Betriebsseite des DevOps-Hauses gelangen, können die Sicherheitsteams einen größeren Nutzen für das gesamte IT-Team erbringen.

Dieser Ansatz beinhaltet, dass während des gesamten Prozesses Informationen in die Hände der Entwickler gelangen. Es ist zwar mehr Aufwand nötig, um richtig zu arbeiten, aber es bringt den Entwicklern und dem Unternehmen als Ganzes einen enormen Mehrwert. Wenn sich mit einem DevOps-Sicherheitsansatz statt mit DevSecOps befasst wird, können Sicherheitsteams ihren Einfluss und ihre Erfahrung zu ihrem Vorteil nutzen.

* Marco Rottigni ist Chief Technical Security Officer EMEA bei Qualys.

(ID:46367726)