Auf dem Weg zu einer sicheren agilen Softwareentwicklung setzen Organisationen immer häufiger auf Application Security Plattformen. Fehlen jedoch die nötigen Grundlagen auf Ebene von Kultur und Prozessen, laufen die teuren Tools ins Leere oder erzeugen sogar Ablehnung in den Teams. Wir zeigen deshalb fünf typische Fehler bei der DevSecOps-Einführung – und wie sie zu vermeiden sind.
Shift Left – Sicherheit rückt in Richtung Entwicklung
DevSecOps ist auf dem Vormarsch. Laut einer aktuellen Umfrage sagen 85% der CISOs, dass Application- und DevOps-Teams mehr Verantwortung für das Management von Sicherheitslücken übernehmen sollten, um eine effektive Applikationssicherheit zu gewährleisten [Dynatrace, 2021]. Security soll also immer mehr in Richtung Entwicklungsprozess wandern. Erleben wir also gerade einen flächendeckenden Paradigmenwechsel hin zu einer sicheren agilen Softwareentwicklung?
Bedingt. Denn in der Praxis besteht dieser sog. Shift Left meist lediglich in der Einführung von Tools, die kontinuierliche Sicherheits-Tests und -Scans entlang des gesamten Entwicklungsprozesses ermöglichen.
Culture eats Tooling for Breakfast
Dabei wird oft übersehen, dass DevSecOps in erster Linie eine Frage der Kultur ist, die nicht nur die passenden Tools, sondern vor allem neue Zusammenarbeitsmodelle und ein neues Mindset erfordert. Anders ausgedrückt: Setzen neue Tools auf alten Prozessen auf, können sie ihr Potenzial nicht heben, sondern erzeugen im schlimmsten Fall Widerstände und Ablehnung auf Seiten der Anwender*innen.
Deshalb sollten Organisationen bei der Einführung von DevSecOps darauf achten, die notwendigen Voraussetzungen auf kultureller, prozessualer und personeller Ebene zu schaffen. Aus der Erfahrung in der Zusammenarbeit mit verschiedenen Typen von Organisationen haben wir fünf typische Fehler identifiziert, die Unternehmen bei der DevSecOps Einführung machen – und zeigen, wie sie sich verhindern lassen:
- Fehler 1: Fehlendes Security-Knowhow
Moderne Security Scanning- und Testing-Tools identifizieren zuverlässig Schwachstellen im Code und geben den Entwicklerteams Rückmeldung zu möglichen Sicherheitslücken. Fehlt diesen jedoch das notwendige Security-Knowhow, um die identifizierten Issues selbständig einordnen, bewerten oder gar beheben zu können, sorgt das für zusätzliche Schleifen und Verzögerungen im Entwicklungsprozess oder führt sogar dazu, dass solche Meldungen fortan ignoriert werden.
Bevor entsprechende Security-Tools eingeführt werden, sollten daher zunächst die Mitarbeiter*innen in den DevOps Teams umfassend befähigt werden – und zwar nicht nur im Umgang mit den Tool selbst, sondern v.a. in Bezug auf die Behebung dieser Sicherheitsrisiken. Grundlagentrainings zu den wichtigsten Security-Bedrohungen, wie z.B. OWASP Top 10 liefern hierfür eine gute Grundlage. - Fehler 2: Gegenseitige Verantwortungszuweisung
DevSecOps verschiebt Security weiter in Richtung des Entwicklungsprozesses und erzeugt dadurch in vielen Fällen Fragen nach der Zuständigkeit für Applikationssicherheit zwischen Dev-, Sec- und Ops-Team. Laut einer aktuellen Umfragen geben rund 12% der Teilnehmer*innen an, nicht zu wissen, wer überhaupt für Sicherheit zuständig ist [Snyk 2020]. In anderen Umfragen verorten rund zwei Drittel der Befragten die Verantwortung für Security in einem der drei Teams [GitLab, 2021]. Tatsächlich muss DevSecOps jedoch in der gemeinsamen Verantwortung aller am Secure Software Development Cycle (SDLC) beteiligten Personen liegen. Ansonsten werden Security-Issues nicht dort bearbeitet, wo sie auftreten, sondern wegdelegiert, wodurch neue Silos und Verzögerungen entstehen. Deshalb müssen Unternehmen frühzeitig dafür sorgen, dass ein solches Verständnis für Security als geteilte Verantwortung entsteht. Dies kann beispielsweise durch die Einführung cross-funktionaler Teams oder Security Communities unterstützt werden. - Fehler 3: Überholte Prozesse
Security war in der Vergangenheit oft gekennzeichnet durch wenig direkte Kommunikation zwischen den am Entwicklungsprozess beteiligten Gruppen, zentral verwaltete Richtlinien und lineare Arbeitsabläufe. Setzt man nun Werkzeuge zum Continuous Application Security Testing ein, ohne die dahinterliegenden Prozesse anzupassen, laufen diese zwangsläufig ins Leere, etwa wenn Issues nicht zu dem Zeitpunkt bearbeitet werden können, zu dem sie gefunden werden.
Stattdessen müssen Organisationen ihre bestehenden Security-Wokflows teamübergreifend ersetzen und stattdessen Prozesse etablieren, die alle am Entwicklungsprozess beteiligten Personen befähigen, aktiv an der Applikationssicherheit mitzuwirken.
Holen Sie sich jetzt den kostenfreien DevSecOps Leitfaden und nutzen Sie unsere 10 Praxistipps, um DevSecOps erfolgreich in Ihrem Unternehmen zu implementieren.
Mehr DevSecOps Tipps gefällig?
- Fehler 4: Fehlende Unterstützung aus dem Management
DevSecOps hat zwar v.a. direkten Auswirkungen auf die operative Zusammenarbeit zwischen Entwicklern, Operations und Security Team. Fehlt jedoch ein Bewusstsein für die Relevanz von Applikationssicherheit auf Ebene des Managements, sind DevSecOps Initiativen zum Scheitern verurteilt, weil bei der ersten Gelegenheit, Sicherheit zugunsten von Kosteneffizienz und Geschwindigkeit geopfert werden.
Deshalb sollte die DevSecOps-Einführung niemals abgekoppelt von einer Awareness-Bildung bis hinauf zum C-Level erfolgen. Entsprechende Workshops und Vorträge zur Sensibilisierung der internen Stakeholder sind daher ein elementarer Erfolgsbaustein. - Fehler 5: Zu schnelle Einführung & überzogene Erwartungen
Die Versprechungen von Tool-Anbietern hinsichtlich einfacher Implementierung und Automatisierungsgrad verleiten Organisationen dazu, überzogene Erwartungen an die Security-Lösungen zu stellen. Das ist in doppelter Hinsicht gefährlich: Zum einen droht eine Überforderung der Mitarbeiter*innen in den DevSecOps Teams, wenn Tools zu schnell ausgerollt werden und entsprechende Schulungs- und Weiterbildungsmaßnahmen fehlen. Zum anderen sorgen überzogene Erwartungen dafür, dass Organisationen sich aufgrund wenig aussagekräftiger Kennzahlen, wie z.B. Test-Coverage, in falscher Sicherheit wiegen. Um das zu verhindern, ist ein umfassender Change Management Prozess, der alle betroffenen Mitarbeiter*innen mitnimmt, unerlässlich.
Fazit: Teure Tools alleine bringen keine Sicherheit
Die Annahme, Application Security Plattformen bzw. Software Composition Analysis (SCA) Tools sorgten automatisch für eine höhere Applikationssicherheit, ist ein Trugschluss. Vielmehr müssen Organisationen die nötigen Voraussetzungen auf personeller, kultureller und prozessualer Ebene schaffen. Fehlt diese Basis, drohen gut gemeinte Investitionen im Entwicklungsalltag zu versanden, ohne, dass sie ihre Wirkung entfalten. Oder wie es der ehemalige ehemaligen CEO von Telefónica Deutschland, Thorsten Dirks ausdrückte: „Wenn Sie einen Scheißprozess digitalisieren, dann haben Sie einen scheiß digitalen Prozess.“
Noch Fragen?