Das Wissen über Schwachstellen ist nur die halbe Miete
Auf unserem Weg zur kontinuierlichen IT liegt ein großer Schwerpunkt auf der Sicherheit. Und das sollte es auch. Es gibt zahlreiche Verstöße. Täglich werden neue Schwachstellen entdeckt und die Patchlücke scheint nicht kleiner zu werden.
Eine der oft vorgeschlagenen Lösungen für sichereren Code ist das Scannen des Quellcodes. Statische und dynamische Sicherheitsscans sind zu einem festen Bestandteil kontinuierlicher Bereitstellungsprozesse geworden. Unsere eigenen internen Pipelines schließen sie ein, und ich kann jederzeit einen Blick auf ein Dashboard werfen, das mir alles über die Ergebnisse dieser Scans anzeigt.
 |
Aber zu wissen, dass im Quellcode Schwachstellen vorhanden sind – wie G.I. Joe uns in Erinnerung ruft – ist nur die halbe Miete. Es wäre zwar faszinierend, wenn die andere Hälfte tatsächlich aus blauen und roten Lasern bestünde, doch in Wirklichkeit besteht die andere Hälfte der Anwendungssicherheit darin, „etwas gegen diese Schwachstellen zu unternehmen“. Leider sehen wir nicht, dass diese Realität eintreten wird. Sie erinnern sich vielleicht an einen Tripwire-Bericht ( 2019 State of Container Security ), in dem 17 % der Befragten zugaben, über anfällige Container zu verfügen, diese zu kennen und sie trotzdem einzusetzen. Sie erinnern sich vielleicht auch an einen Arxan/IBM-Bericht zur Anwendungssicherheit für Mobilgeräte und das IoT aus dem Jahr 2017 , in dem festgestellt wurde, dass 53 % der Befragten statische Sicherheitstests und 51 % dynamische Sicherheitstests für mobile Apps verwenden. Und trotz erheblicher Besorgnis hinsichtlich eines Verstoßes unternahm fast die Hälfte (44 %) keine Schritte, um diesen zu verhindern. |
Das Problem fehlender Tests und mangelnder Maßnahmen gegen bekannte Schwachstellen ist fast immer mit dem Druck verbunden, die Time-to-Value zu verkürzen. Fast die Hälfte (48 %) der Entwickler gibt an, dass sie nicht genügend Zeit für die Sicherheit haben ( DevSecOps-Community-Umfrage 2018 ). Andere Umfragen bestätigen dies: Auf den Entwicklern lastet ein enormer Druck, immer schneller und häufiger Code auszuspucken. Es zeigt sich, dass die Sicherheit weiterhin das „Ding“ ist, das auf der Strecke bleibt, wenn es um die Geschwindigkeit geht, sei es auf dem Daten- oder dem Übertragungsweg.
Es ist allgemein bekannt, dass Menschen auf das hinarbeiten, woran sie gemessen werden. Und da Entwickler auch Menschen sind, unterliegen auch sie dieser Regel. Wenn für sie eine schnelle Markteinführung im Vordergrund steht, werden sie darauf hinarbeiten – selbst wenn sie dabei Schritte überspringen, die die Sicherheit gefährden. Wenn wir sichere Anwendungen auf den Markt bringen wollen, müssen wir einen kulturellen Wandel vollziehen, der einer sicheren Markteinführung ebenso viel Bedeutung beimisst und Bedeutung beimisst wie einer schnellen Markteinführung .
Bis dahin können wir uns bei der Behebung von Schwachstellen auf rote und blaue Laser genauso verlassen wie auf die Hilfe von Entwicklern.