Fehlendes Knowhow – eine Gefahr für die Anwendungssicherheit

Der Mangel an IT-Sicherheitsexperten gehört zu den größten Herausforderungen in der Applikationsentwicklung. Laut einer aktuellen Umfrage kommt derzeit auf 500 Entwicklerinnen und Entwickler im Schnitt lediglich ein Security-Experte. Die wachsende Zahl digitaler Produkte und Services sowie immer kürzere Release-Zyklen verstärken zusätzlich den Druck auf Security-Abteilungen. Die möglichen Folgen: längere Feedbackschleifen und weniger häufige Security Tests pro Applikation.

DevSecOps als Lösung für den Fachkräftemangel?

Damit Security vor diesem Hintergrund nicht zum Bottleneck für neue digitale Businessmodelle wird, setzen Unternehmen verstärkt auf DevSecOps anstelle von klassischen Staging-Prozessen. Die Verantwortung für Application Security verlagert sich dadurch von zentral organisierten Security Teams als Gatekeeper in Richtung Entwickler- und Operations-Teams, die Sicherheitslücken bereits während des Entwicklungsprozesses identifizieren und unmittelbar beheben. Soweit die Theorie. Denn in der Praxis scheitert dieser "Security Shift Left" immer noch sehr häufig an fehlenden Kompetenzen und kulturellen Voraussetzungen in den DevOps Teams.

Lesetipp: DevSecOps - So gelingt sichere Softwareentwicklung

Silos existieren in den Köpfen weiter

Das beginnt bereits beim grundsätzlichen Verständnis über die Verantwortung für Applikationssicherheit zwischen den am Secure Software Development Life Cycle (SDLC) beteiligten Teams und Personen. Denn durch die jahrelange, strikte Trennung zwischen Softwareentwicklung bzw. DevOps auf der einen und Security auf der anderen Seite, hat sich eine Kultur der gegenseitigen Verantwortungsweitergabe etabliert. Diese wird im DevSecOps-Kontext aufgelöst zugunsten einer sehr viel direkteren Verantwortung für sicheren Code, direkt dort wo er entsteht.

Um Applikation Security wirkungsvoll im Entwicklungsprozess zu verankern, sollten sich Entwicklungsteams deshalb zunächst bewusst machen, dass sie, mit dem was sie bauen, Risiken für das Unternehmen mittragen und diese entsprechend adressieren müssen.

Vom Entwickler zum Security Experten?

Auch wenn dieses Verständnis für DevSecOps als teamübergreifende Verantwortung langsam in den Organisationen Einzug hält, gelingt die Übersetzung von abstrakten Anforderungen in eine konkrete Security-Praxis dennoch oft nicht. Zum einen führt ein hoher Projektdruck in Feature-orientierten Entwicklungsprozessen oftmals dazu, dass in Entwicklungsteams schlichtweg keine Zeit für ein kontinuierliches Security Testing bleibt, da Sicherheitsaspekte im Zweifelsfalls zugunsten der Time-to-Market vernachlässigt werden.

Lesetipp: Die besten DAST- & SAST-Tools

Zum anderen fehlen in den DevOps-Teams oft notwendige Kompetenzen in der Anwendungssicherheit, etwa im Bereich von CI/CD-Pipelines oder Container-Security. Der Aufbau dieser Fähigkeiten erfordert nicht nur Expertise, sondern vor allem Augenmaß. Denn nicht jeder Entwickler muss bzw. sollte ein Experte in Applikationssicherheit werden. Vielmehr geht es darum zu vermitteln, die Perspektive zu wechseln und bei jedem Feature und jeder Komponente nach den potenziellen Folgen im Hinblick auf die Sicherheit des Produkts bzw. Systems zu fragen. Hierbei können beispielsweise regelmäßig vom Team durchgeführte Bedrohungsanalysen (Threatmodellings) helfen, um Risiken bereits früh im Entwicklungsprozess zu identifizieren.

Security: Vom Gatekeeper zum Coach

Aber nicht nur die entwicklungsnahen Bereiche, auch die Security-Abteilungen selbst muss ihre Rolle im Kontext von DevSecOps neu interpretieren: Weg vom zentralen Sicherheits- und Compliance Gatekeeper hin zum Sparringspartner und Coach, der sein Security Knowhow in die Entwicklungsteams trägt und organisationsweit skaliert.

Für viele etablierte Security-Organisationen stellt diese Transformation eine besondere Herausforderung dar, da ihr Fokus in der Vergangenheit eher im Bereich Compliance und Governance lag. Denn die dort eingesetzten Instrumente in Form von Vorgaben und Richtlinien reichen oft nicht allein aus, um eine effektive Anwendungssicherheit zu gewährleisten.

Stattdessen muss auch die Security-Organisation neue Kompetenzen und Profile aufbauen, die eine stärkere inhaltliche Nähe zur Softwareentwicklung aufweisen und dadurch in der Lage sind, abstrakte Security-Anforderungen in konkrete Handlungsempfehlungen zu übersetzen. So kann eine Security-Abteilung gezielt die Anwendungsentwicklung unterstützen, sei es im Rahmen eines moderierten Prozesses oder als fester Bestandteil des DevOps-Teams.

Applikation Security durch kontinuierlichen Kompetenzaufbau

Über diese punktuelle Unterstützung hinaus sollte die Kernaufgabe des Security-Teams im Hinblick auf Applikationssicherheit langfristig im Knowhow-Transfer liegen. Nur so kann die Abhängigkeit von der Security-Abteilung als zentralem Wissensträger verringert und eine echte Befähigung der Entwicklungsteams im Sinne des DevSecOps-Ansatz stattfinden. Auch hier stellen der hohe Zeitdruck und der Mangel an verfügbaren Security-Experten limitierende Faktoren dar. Deshalb gehen Unternehmen zum Teil dazu über, die Qualifizierung ihrer Mitarbeiterinnen und Mitarbeiter zu outsourcen. Langfristig sollten Organisationen allerdings versuchen, diese wichtigen Kernkompetenzen im eigenen Haus zu etablieren.

Lesetipp: Softwarelieferkette absichern - DevOps-Pipelines in Gefahr!

Qualifizierung als unternehmensweite Aufgabe

Der Aufbau der notwendigen Kompetenzen im Bereich Application Security stellt viele Organisation vor eine große Herausforderung, die nur dann gelingen kann, wenn sie als unternehmensweite Aufgabe verstanden und angenommen wird. Diese sollte sowohl von den DevOps Teams selbst als auch von der Security-Abteilung parallel vorangetrieben werden. Dabei lassen sich typischerweise verschiedene Phasen unterscheiden:

Phase 1: Awareness schaffen
Die Einbettung von Applikationssicherheit im laufenden Softwareentwicklungsprozess bedeutet radikale Veränderungen in Bezug auf die Zusammenarbeit zwischen den Teams, sowie die damit einhergehenden Rollen und Verantwortlichkeiten. Sowohl in Security- als auch DevOps Teams muss daher zunächst ein gemeinsames Verständnis und Bewusstsein für die neuen Rollen und Aufgaben erzeugt werden. Das erfordert ein bewusstes Veränderungsmanagement, um diesen Mindshift zu unterstützen. Dabei helfen etwa Awareness Workshops und Vorträge in den verschiedenen Zielgruppen von Entwicklern bis zum Management.
Lesetipp: Security Awareness Training: So phishen Sie richtig

Phase 2: Knowhow bereitstellen und Ressourcen schaffen
Ist ein gemeinsames Security-Verständnis als Basis für die teamübergreifende Zusammenarbeit hergestellt, gilt es schnell die notwendigen Kompetenzen für eine sichere agile Softwareentwicklung bereitzustellen. Je nach Verfügbarkeit von internen Security-Ressourcen kann das entweder über eine direkte Einbindung des Security-Teams in den Entwicklungsprojekten oder über Trainings und Schulungen erfolgen.

Phase 3: Kontinuierlicher Kompetenzaufbau
Um das Thema Applikationssicherheit langfristig und zuverlässig in der Organisation zu verankern, muss der Auf- und Ausbau von Security-Kompetenzen in den Teams verstetigt werden. Die Security-Abteilung nimmt dabei eine zentrale Rolle als Coach, Ausbilder und Sparringspartner ein und sorgt so für die organisationsweite Skalierbarkeit der Security-Kompetenz in die entwicklungsnahen Bereiche hinein. Hierbei können Train-the-Trainer Konzepte, etwa in Form von Security Champions oder Security-Communities (CoP) dabei helfen, die DevSecOps Prinzipien nachhaltig in den Teams zu etablieren.

DevSecOps - kein Selbstläufer, aber lohnenswert

Angesichts der steigenden Zahl digitaler Services und gleichzeitig zunehmenden Cyberattacken stellt der Mangel an Application-Security-Kompetenzen für etliche Unternehmen mittlerweile ein veritables Business Risiko dar. Die Verlagerung von Anwendungssicherheit Richtung Entwicklung, im Sinne des DevSecOps Ansatzes, ist ein wichtiger Schritt, um Security agiler und effizienter zu gestalten. Allerdings handelt es sich dabei nicht um einen Selbstläufer, der mittels passender Tools implementiert werden kann - sondern einen tiefgreifenden kulturellen Veränderungsprozess, der intensiv begleitet werden sollte, um erfolgreich zu sein. (bw)