Eine Frau deutet am Whiteboard auf das Wort Leadership

DevSecOps in der Unternehmensstrategie

DevSecOps: Sicherheit integrieren und dennoch effizient Projekte managen

DevSecOps in der Unternehmensstrategie

In meinen letzten Blogartikeln vom 11. und 13. August 2020 habe ich in das Vorgehensmodel DevOps eingeführt. In diesem Beitrag möchte ich nun auf DevSecOps zu sprechen kommen. Darüber hinaus werde ich mich mit der Thematik Planbarkeit von Projekten, Risikobewertung und Kostenüberblick in DevSecOps Projekten beschäftigen, denn die beste Methodik für Projekte bringt wenig, wenn man - aus Sicht der Unternehmensführung - im Blindflug unterwegs ist und am Ende eine Überraschung bezüglich Kosten und Zeit erlebt. Also gilt es ein DevSecOps Projekt vorher zu bewerten und während der Zeit zu monitoren.

DevSecOps – Überblick

Relativ schnell hat man bei der Nutzung von DevOps erkannt, dass ein Element im Vorgehensmodell fehlt: die Sicherheit. Da bei DevOps die Entwicklungszyklen sehr kurz sind (teilweise mehrere Releases pro Tag) ist es für Security Operations unmöglich, immer nach den Entwicklungen eine Endabnahme zu machen. Als logische Schlussfolgerung muss man Security mit in das Model integrieren und nicht am Ende der Entwicklung anhängen.

So entstand das Vorgehensmodel DevSecOps:

Grafik, die eine liegende 8 zeigt, auf der die Worte plan, code, build, test, release, deploy, operate, monitor zu lesen sind © https://www.synopsys.com/glossary/what-is-devsecops.html

Erst so war es möglich sicherheitskritische Applikationen mit dem DevOps Model zu entwickeln. Das Modell wurde zunehmend interessant für folgende Wirtschaftsbereiche:

  • Automobilbau  
  • Gesundheitswesen       
  • Finanzwesen
  • e-Commerce
  • IoT-Geräte
  • Embedded-Software
  • Netzwerkentwicklung

usw.

Die Vorteile

Der wohl größte und wichtigste Vorteil gegenüber DevOps ist die schnelle Entwicklung sicherer Applikationen, inklusive der schnellen Veröffentlichung. So kann die Applikation sehr schnell auf die Bedürfnisse der Nutzer reagieren. Change-Management und Neuplanung bei Änderungen fallen damit aus. Das senkt auch die Kosten. Trotz dieser schnellen und agilen Vorgehensweise ist die Sicherheit nicht gefährdet, da alle Security-Aspekte jederzeit getestet und berücksichtigt werden.

Ein Vorteil von DevSecOps gegenüber klassischen Projektmanagementmethoden besteht darin dass es sich um ein kleineres Team handelt und Übergabeprozesse ausgelassen werden können. Da Administration und Security direkt beim Entwickeln miteingebunden sind kann man so (neben der Projektleitung) weitere Ressourcen sparen, die für die Betriebsübergabe notwendig wären.

Die Herausforderungen

Geht man Entwicklungsprojekte nach DevSecOps an sind über den gesamten Entwicklungszeitraum mehr Ressourcen gebunden, als es beim klassischem Vorgehensmodell der Fall wäre. Weiterhin bleibt, bedingt durch die Geschwindigkeit bei der Entwicklung, das Problem der Dokumentation. Entwickler‘innen, Administrator‘innen oder Sicherheitsbeauftragte haben große Mühe, den Einstieg in ein Projekt zu finden, welches schon ein paar Monate oder gar Jahre Projektlaufzeit besitzt.

Entwickler‘innen können eine rudimentäre Form der Dokumentation noch im Quellcode hinterlassen, die Architektur einer Software und die Intention einer Vorgehensweise wird hier jedoch nicht dokumentiert. Administrator‘innen und Security Operations haben keine Möglichkeit zur schnellen Dokumentation. Hier wird die Dokumentation (wie auch allzu oft im klassischen Vorgehen) wohl gänzlich ausfallen.

Planbarkeit im Unternehmen

Die meisten Unternehmensführungen sind primär an folgenden Dingen interessiert:

1.     Kosten einer Entwicklung
Die Führungsebene will die Kosten planbar und strategisch im Blick haben, um auf Veränderungen am Markt schnell reagieren zu können.

2.      Ressourcenaufwand einer Entwicklung
Die Unternehmensführung will wissen, welche Ressourcen für andere Aufgaben zur Verfügung stehen.

3.     Integration der Neuentwicklung in die Unternehmensstrategie
Der Lebenszyklus einer Neuentwicklung soll möglichst lang sein, daher muss sie im Einklang mit den Fernzielen des Unternehmens stehen.

Das DevSecOps Vorgehensmodel sieht allerding keine Planungsphase mit Kosten- und Aufwandsschätzung vor. Ganz im Gegenteil ist es gerade ein Vorteil, wenn man schnell und flexibel agieren möchte. Diese höhere Flexibilität bei der Entwicklung kann allerdings zum Problem werden. Schnell geht die Entwicklung in eine Richtung, die gar nicht gewünscht ist, weil sie Strategiezielen zuwiderläuft. Diese langfristen Strategieziele hat jedoch eventuell weder die Person, die die Entwicklung beauftragt noch das Entwicklerteam im Blick.

Zudem ist es für eine Unternehmensleitung extrem schwierig ein Projekt freizugeben, bei denen die Kosten nicht kalkuliert und geplant werden können. In diesem Zusammenhang erscheint das Problem der Ressourcenbindung fast schon vernachlässigbar klein, wenngleich nach wie vor vorhanden.

Aus Unternehmenssicht ist das Vorgehensmodel also eher ein Albtraum, als ein Segen, auch wenn am Ende vielleicht ein Produkt schneller und/oder günstiger entwickelt wird. Das „vielleicht“ in dem Satz ist das Kickoff-Argument gegen das Vorgehensmodel. Für Unternehmensleitungen scheint es fast, als ließe man mit DevSecOps Entwicklung, Administration und Security sozusagen „von der Leine“ und hoffe einzig darauf, dass am Ende etwas Großartiges daraus entsteht. Das ist wohl der Grund, warum das Model sich noch nicht stärker durchgesetzt hat.

Ein möglicher Lösungsansatz ist hier ein eine Zusammenarbeit mit Projektleiter’innen (PL)/-managern. PLs sind in Planung, Risikomanagement, Monitoring und Reporting geschult und Profis. Sie könnten die ganze Politik im Unternehmen übernehmen und somit das DevSecOps Team vor störenden Einflüssen schützen, ähnlich dem SCRUM Master in der agilen SCRUM Entwicklung. Als PL hat man damit keine Entscheidungsgewalt im Projekt, eher ein Mitspracherecht. Man ist nicht der „Leiter‘in“, sondern begleitet die Entwicklung und steuert die Administration des Projekts.

Die Planung

Im klassischen Projektmanagement haben Projektleitungen gelernt, Risiken zu sehen und zu bewerten (auch monetär), Zeiten zu schätzen (mit dem gesamten Team) und somit auch Kostenabschätzungen vornehmen zu können. Dass diese Prognosen nicht immer zu 100% zutreffen, ist jedem klar, auch der Unternehmensführung. Aber durch gute Prognosen hat die Führungsebene einen Wert, mit dem sie arbeiten kann.

Gerade der Bereich Risikomanagement ist ein nicht zu unterschätzender Faktor, der im DevSecOps-Modell fast gänzlich vernachlässigt wird. Die meisten großen Projekte, die aus dem Ruder gelaufen sind, haben genau in diesem Bereich nicht gut gearbeitet. Daher sehe ich es problematisch, im Projekt jetzt auf Risikomanagement komplett zu verzichten. Meiner Ansicht nach bedarf es hier höherer Aufmerksamkeit, damit mehr Projekte erfolgreich abgeschlossen werden, nicht weniger.

In der Kosten- und Aufwandsschätzung ist es also essenziell, ein sehr gutes und vollständiges Bild aller Risiken im Projekt zu haben. Die Schätzung aller Kosten und Aufwände, wenn alles gut geht ist einfach und unkompliziert. Die möglichen Zusatzkosten zu erkennen und zu bewerten, das ist der eigentlich wichtige Job bei der Aufwandsschätzung.

Genau dieses Risikomanagement ist in DevSecOps nicht mehr vorgesehen. Ich halte es für gefährlich, denn eine Kostenschätzung ist für die Entwicklung kaum möglich (keiner weiß, wo die Reise hingeht) und für damit verbundene Risiken nicht mal angedacht. Die Gefahr, im Endeffekt sämtliche Kostenrahmen zu sprengen, ist meiner Ansicht nach immens. Abhilfe kann da nur eine zusätzliche Rolle im Projekt schaffen, deren Kernbereich es ist, genau diese Dinge zu betrachten und auf schwache Signale für Risiken zu achten. Ein‘e PL ist hierfür die beste Wahl.

Monitoring und Reporting der Projekte

Diese‘r PL könnte die tatsächlich aufgelaufenen Kosten monitoren und gegen die noch zu erledigenden Aufgaben stellen (ähnlich einer „earned-value-Analyse). Wer diese Aufgabe im DevSecOps Modell übernimmt ist nicht geregelt. Hier sehe ich im Modell noch ein Problem. Die Geschäftsführung ist nämlich, gerade bei mittleren und großen Projekten, an genau diesem Fortschritt interessiert. Das war auch bei anderen agilen Vorgehensmethoden schon immer ein Problem. Bei SCRUM zum Beispiel kommen im Laufe eines Projektes immer neue User-Stories hinzu, die alten Stories sogar zuwiderlaufen. Es werden also Features entwickelt und später wieder aus dem Produkt genommen. Für Endbenutzer‘innen ist das ein gute Entwicklung, für die Führungsetage eher ein unschön, wenn etwas entwickelt wird und dann doch wieder gelöscht wird. Diese Features kann man nicht vermeiden, aber vielleicht kann man deren Notwendigkeit besser im Lenkungsausschuss vorbringen, um ein Verständnis in der Führungsetage zu erzeugen und somit weiter ein positives Bild vom Projekt zu behalten.

Eine zusätzliche Person in Gestalt von PL könnte das Projekt begleiten und die Ergebnisse im Lenkungsausschuss vorstellen, quasi als Bindeglied zwischen Führung und Team

Fazit

Ich bin der Überzeugung, dass ein‘e PL (mit anderem Namen und oben beschriebenen Aufgaben) in DevSecOps sehr wohl seine Daseinsberechtigung hat. Das hat man im SCRUM-Modell schon erkannt und die Funktion des SCRUM Master etabliert.

Auch bei DevSecOps wird sich eine solche Rolle finden müssen, damit dieses Vorgehensmodel die Akzeptanz in Unternehmensführungen erhält. Das erfordert allerdings ein Umdenken bei klassischen PLs und eine auch eine Verschiebung in deren Aufgaben. Sie werden nicht mehr unangefochtene Führungspersonen im Projekt sein, sondern eher als gleichwertige Partnerinnen dem Team helfen, sich nicht in Unternehmenspolitik zu verstricken, Kosten zu überwachen und Risiken zu erkennen.

Ich halte diese Rolle für eine sehr spannende Rolle und glaube an deren Zukunft und damit die Zukunft für DevSecOps.

Florian Hieber, Senior Projektmanager

+49 151 4311 9966
fhieber@spirit21.com

Florian kennt sich im klassischen Projektmanagement und mit agilen Methoden aus und bringt langjährige Erfahrung in der Entwicklung, bei Netzwerk-Topologien und Microsoft-Technologien mit.

Wir nutzen sogenannte Cookies, um Daten darüber zu bekommen, wie und mit welchen Endgeräten unsere Seiten besucht werden. Das hilft uns sehr dabei, die Seiten noch interessanter und bedienungsfreundlicher zu machen. Dabei berücksichtigen wir natürlich Ihre Präferenzen und schalten das SPIRIT/21-Analytics nur dann scharf, wenn Sie durch einen Klick auf „Cookies akzeptieren“ Ihr Einverständnis geben. Sie können Ihre Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen. Weitere Informationen finden Sie unter Cookie Einstellungen und in unserer