DevSecOps-Initiativen erfordern eine sorgfältige Abwägung zwischen Kultur, (Lern-)Prozessen und Geschäftserfordernissen. Dabei kann einiges schiefgehen. [...]
Unternehmen setzen aus verschiedenen Gründen auf DevSecOps: Um Transformationsprojekte voranzutreiben, schneller Mehrwert zu generieren, Wettbewerbsvorteile zu erschließen oder das Security-Niveau zu verbessern.
Dabei verendet so manche DevSecOps-Initiative kläglich – oft, weil sie nicht gut durchdacht ist beziehungsweise überhastet angegangen wird. Die gängigsten Fehler, die dabei gemacht werden, sind jedoch vermeidbar – wie unsere Zusammenstellung zeigt. Diese sieben Wege zum DevSecOps-Fail sollten Sie unter allen Umständen vermeiden.
1. „Welche Lernkultur?“
Einer aktuellen McKinsey-Studie zufolge stellen personalbezogene und unternehmenskulturelle Probleme die größten Hindernisse für technologische Transformationsprozesse dar. Zu diesen Transformationsprozessen zählt auch die DevSecOps-Methode. Deshalb haben diejenigen Unternehmen, die eine Kultur des Experimentierens und des „Continous Learning“ implementieren, mehr Erfolg mit DevSecOps.
In der Praxis lässt sich das durch folgende Maßnahmen erreichen:
- tägliche Lerneinheiten
- regelmäßiges Organizational Learning und Experimentieren
- gezielte Investments in Upskilling-Initativen
- Einbindung von (externen wie internen) Experten
2. „Im Silo ist es windstill“
Nicht wenige Development- und Security-Teams trennen tiefe Gräben. Um Silos einzureißen und die Spannungen zwischen den Abteilungen abzubauen, ist crossfunktionale Weiterbildung obligatorisch.
Die FOSS-Anwenderumfrage 2020 der Linux Foundation kommt zu dem Ergebnis, dass ein Open-Source-Entwickler im Schnitt 2,3 Prozent seiner Arbeitszeit darauf verwendet, seinen Programmcode sicherer zu gestalten. In manchen Developer-Kreisen ist Secure Coding sogar verpönt. Dabei sind es die Softwareentwickler, die maßgeblich dazu beitragen können, Security-Schwachstellen von vornherein zu verhindern. Führungskräfte sollten deshalb alles daransetzen, die Bedeutung von Secure Coding für das gesamte Unternehmen deutlich zu unterstreichen – und eventuell Anreize bieten, diese Richtlinien in der Praxis umzusetzen.
Die Kehrseite der Medaille: Egal ob es um Applikationen, Infrastructure as a Code oder CI/CD Pipelines geht – Programmcode ist überall. IT-Security-Spezialisten müssen keine Starprogrammierer sein, sollten aber gehobene Coding-Aufgaben beherrschen und in der Lage sein, Templates auf gängige Fehlkonfigurationen und Schwachstellen zu überprüfen. Der Kollaboration zwischen Development und Security wäre das ebenfalls zuträglich.
3. „Transformationsprojekt – reicht doch?“
Jedes Vorhaben – auch DevSecOps – sollte auf strategische Geschäftsziele einzahlen. Gerade Transformationsprojekte wie DevSecOps verlangen Engagement und Investitionen von allen maßgeblichen Stakeholdern im Unternehmen.
Den geschäftlichen Mehrwert von DevSecOps zu kommunizieren, ist deshalb erfolgskritisch. Insbesondere die Management-Ebene sollte sich der Vorteile der Methode bewusst sein. Dazu können verschiedene Metriken herangezogen werden, die laut Bill Nichols vom Carnegie Mellons Software Engineering Institute (SEI) „zugänglich, hochverfügbar und auf Geschäftsziele ausgerichtet“ sein sollten.
4. „Wer Fehler macht, der fliegt“
Wie bereits erwähnt spielt die Etablierung einer Lernkultur für den DevSecOps-Erfolg eine tragende Rolle. Das genaue Gegenteil davon ist eine zu stark ausgeprägte Risikoscheu gepaart mit Versagensangst. Fehlschläge sollten als natürliches Nebenprodukt von Lernprozessen begriffen werden.
Wenn Ihre Teams keine Fehler machen dürfen, gibt es auch keinen Raum für Lernprozesse und die Korrektur von Fehlern. Die Chancen für eine erfolgreiche DevSecOps-Adoption sinken so rapide. Stattdessen sollten Sie Ihre Mitarbeiter dazu befähigen, ihre Schwächen erkennen zu können und darauf aufbauend ihre Kompetenzen ausbauen zu können. Möglich ist das allerdings nur in einer Umgebung, die von Transparenz und Vertrauen geprägt ist.
Ein anderes gutes Beispiel für übertriebene Risikoaversion ist, wenn Security zur härtesten Zerreißprobe für die DevSecOps-Implementierung wird. Ein gängiger Einwand gegen DevSecOps ist, dass die Methode angeblich viel zu schwerfällig sei und so Innovation und Delivery ausbremse. Dieser Vorwurf ist leider nicht aus der Luft gegriffen, wenn Security nicht optimal eingebunden wird. Um dem entgegenzuwirken, eignen sich folgende Maßnahmen:
- Integration mit den Entwickler-Workflows
- Etablierung teaminterner Security-Experten und Security-„Champions“
- Durchsetzung einer Security-Kultur im gesamten Unternehmen
5. „Das brauchen wir noch!“
Die fortschreitende digitale Transformation befeuert innerhalb der Cloud-Native-Landschaft ein rasantes Wachstum. Die Zahl der Tools und Applikationen, die Unternehmen dabei unterstützen sollen, DevSecOps zu adaptieren, wächst unaufhörlich. Das führt immer öfter zu hochkomplexen und verteilten IT-Umgebungen in Unternehmen. Wie divers der Cloud-Native-Markt inzwischen aufgestellt ist, veranschaulicht die nachfolgende Übersicht der Cloud Native Computing Foundation (CNCF).
Ein Flickenteppich an Tools und Lösungen wirft Herausforderungen hinsichtlich Visibility und Produktivität auf. Um der Situation beziehungsweise der Ineffizienz Herr zu werden, setzen manche Firmen auf Toolchain Management.
Allerdings sind das keine reinen DevOps-Probleme. Auch die Security ist davon betroffen: Die Ergebnisse der Studie „Cloud-Based Intelligent Ecosystems“ der Cloud Security Alliance (CSA) zeigen, dass die meisten Unternehmen nicht genau wissen, ob ihre Security-Werkzeuge funktionieren oder Mehrwert generieren. Dazu kommt, dass viele Security Teams bereits mit dem Tool-Übermaß in ihrem Bereich überfordert sind.
6. „Damit hab‘ ich nichts zu tun“
Laut der ISC2-Studie „Cybersecurity Workforce 2020“ fehlen weltweit circa 3,12 Millionen Security-Experten. In der Unternehmenspraxis stellen die Sicherheitsprofis deshalb im Regelfall auch die kleinsten Teams – insbesondere im Vergleich mit der Development-Abteilung. Umso wichtiger ist es, dass die Entwickler dabei unterstützen, Sicherheitslücken so früh wie möglich im Entwicklungsprozess zu mitigieren beziehungsweise zu beseitigen.
Zu realisieren, dass Security in die Verantwortung aller fällt, ist der Startpunkt für die Durchsetzung einer Security-Kultur in Unternehmen. Ein weiterer, elementarer Bestandteil: Das Security Team darf nicht als „Office of No“, sondern muss als Kollaborationspartner wahrgenommen werden, der dabei unterstützen kann, die gemeinsamen Ziele zu erreichen und dabei die IT-Sicherheit stets im Blick zu behalten.
7. „Wo gibt es das zu kaufen?“
Nicht wenige Firmen begehen den Fehler, DevSecOps einfach einkaufen zu wollen. Eine beispielhafte Aussage, in denen sich solche Bestrebungen manifestieren: „Wenn wir CI/CD Pipelines implementieren, machen wir DevSecOps“. Das ist falsch.
Bei DevSecOps handelt es sich um eine Methodik, die durch Menschen, Prozesse und Technologie realisiert wird. Dabei kommt dem letztgenannten Punkt allerdings weit weniger Bedeutung zu als den erstgenannten. Ohne eine Unternehmenskultur, die auf agilen Prinzipien fußt, wird auch aus DevSecOps nichts oder zumindest kein Erfolg. Alte Betriebsmodelle mit moderner Technologie „auszukleiden“, ohne dabei etwas an Prozessen zu verändern, führt zu unternehmensweiter Verwirrung, Ineffizienz und Frustration. Ganz besonders präsent ist das bei den Teams, die DevSecOps umsetzen sollen – und den Führungskräften, die Business Outcomes vorweisen müssen.
Eine DevSecOps-Implementierung ist kein Kinderspiel. Eine korrekte Umsetzung erfordert nicht nur Geduld, sondern auch eine Fokussierung auf Kernkompetenzen. Klappt das, können Unternehmen enorm profitieren – und zwar in Form von:
- beschleunigter Delivery,
- verbesserten Reaktionsmöglichkeiten auf Markt- und Kundenanforderungen und
- Wettbewerbsvorteilen.
Darüber hinaus hilft DevSecOps dabei, Sicherheitslücken zuverlässiger, früher und effektiver als mit traditionellen Methoden zu umgehen und zu beheben.
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online.
*Chris Hughes schreibt für unsere US-Schwesterpublikation CSO Online.
**Florian Maier beschäftigt sich für Computerwoche.de mit vielen Themen rund um Technologie und Management. Daneben betätigt er sich auch in sozialen Netzen.
Be the first to comment