Schwachstellen kennen ist nur die halbe Miete

(openPR) Lori MacVittie, Principal Technical Evangelist, und Ralf Sydekum, Technical Manager DACH bei F5 Networks erklären, warum Unternehmen bekannte Sicherheitslücken häufig nicht beheben

München, 20. November 2019 – Zumindest nach außen hin sagen viele Unternehmen, dass der Schwerpunkt ihrer Software-Entwicklung und -Bereitstellung auf dem Thema Sicherheit liegt. Und das sollte auch so sein. Denn täglich werden neue Schwachstellen entdeckt und die Patch-Lücke scheint nicht kleiner zu werden.

Eine der häufig vorgeschlagenen Lösungen für mehr Sicherheit ist das Scannen von Quellcode. Statische und dynamische Sicherheitsscans sind zu einem wichtigen Bestandteil kontinuierlicher IT-Bereitstellungsprozesse geworden. So lässt sich jederzeit mit einem Blick auf ein Dashboard ermitteln, was diese Scans finden.

Sicherheitslücken werden häufig ignoriert
Aber zu wissen, dass es im Quellcode Schwachstellen gibt, ist nur die halbe Miete. Die andere Hälfte besteht darin, etwas gegen diese Sicherheitslücken zu unternehmen. Leider wird dies in der Realität nicht immer umgesetzt.

So geben in einer Umfrage von Tripwire (2019 State of Container Security) 17 Prozent der Teilnehmer zu, gefährdete Container einzusetzen, obwohl sie dies wissen. Laut einer Studie von Arxan/IBM aus dem Jahr 2017 verwenden zwar 53 Prozent der Befragten statische Sicherheitstests und 51 Prozent dynamische Sicherheitstests für mobile Anwendungen. Doch trotz erheblicher Bedenken in Bezug auf Security-Vorfälle unternimmt fast die Hälfte (44 Prozent) keine Schritte, um diese zu verhindern.

Zeitdruck wichtiger als Security
Dass bekannte Schwachstellen nicht behoben oder einfach ignoriert werden, liegt fast immer am Zeitdruck. Fast die Hälfte (48 Prozent) der Entwickler haben nicht genügend Zeit für Sicherheitsaufgaben, so der 2018 DevSecOps Community Survey. Andere Umfragen bestätigen das: Entwickler stehen unter enormem Druck, Code schneller und häufiger zu erstellen. Dies geht häufig zulasten der Sicherheit, die nach wie vor vernachlässigt wird, wenn die Geschwindigkeit im Vordergrund steht.

Das ist auch kein Wunder: Schließlich werden Entwickler in der Regel an einer schnellen Markteinführung gemessen. Entsprechend arbeiten sie auch darauf hin – selbst wenn es bedeutet, Prozesse zu überspringen und damit die Sicherheit zu beeinträchtigen. Wenn Unternehmen also sichere Anwendungen für den Markt bereitstellen wollen, müssen sie sich einem kulturellen Wandel unterziehen. Sie dürfen nicht nur messen, wie schnell Produkte auf den Markt kommen, sondern müssen auch bewerten, wie sicher sie sind.

Individuelle Ansätze finden
Dazu gibt es jedoch keine Standardlösung. Natürlich könnte man für jede Teilaufgabe ein Security-Konzept entwickeln, doch dies ist recht realitätsfern. Zudem stehen nicht nur die Entwickler unter Druck, sondern auch die Fachabteilungen und somit das gesamte Unternehmen. Die entscheidende Frage lautet daher, mit wieviel Aufwand welches Security-Niveau erreicht werden soll. Häufig steht der Aufwand nicht im Verhältnis zum Sicherheitsgewinn, so dass ein genau kalkuliertes Restrisiko im Einzelfall sinnvoll sein kann.

Ein hoher Grundschutz lässt sich aber schon mit bewährten Praktiken und Sicherheitsmaßnahmen erreichen. So löst sich der scheinbare Widerspruch zwischen Agilität und Sicherheit auf, wenn sowohl die Prinzipien des Secure Coding eingehalten als auch im gesamten CI/CD-Prozess der Applikationsentwicklung und -bereitstellung Security-Richtlinien in die Automatisierungsprozesse integriert werden. Damit lässt sich mit vergleichsweise wenig Aufwand ein ausreichendes Sicherheitsniveau gewährleisten.