Fehlkonfigurationen, bekannte ungepatchte Schwachstellen und Cloud-Native-Application-Security

Vor zwei Wochen haben wir unseren jährlichen Bericht State of Cloud Native Application Security veröffentlicht. Falls Sie ihn noch nicht kennen, kommt hier die Kurzfassung: Wir haben fast 600 Entwickler und Sicherheitsexperten befragt, um herauszufinden, wie der Wandel hin zu Cloud Native (digitale Transformation) ihre Sicherheitslage verändert hat. Anschließend haben wir die Ergebnisse ausgewertet, wertvolle Erkenntnisse gewonnen und auf einer interaktiven Webseite aufbereitet.

Aus den Ergebnissen konnten wir viele wichtige Erkenntnisse gewinnen. Einige davon passen meiner Meinung nach besonders gut zusammen:

1. Fast alle Befragten waren sich einig, dass Sicherheit von Anfang an zum Standard gehören muss, wenn die Nutzung von Cloud Native zunimmt.

2. Befragte mit stark automatisierten Pipelines integrierten mit doppelt so hoher Wahrscheinlichkeit Sicherheitstests in den gesamten Entwicklungslebenszyklus.

3. Entwickler sehen sich als festen Bestandteil der Sicherheit.

Diese Punkte weisen klar in Richtung DevSecOps: Der Erfolg von Sicherheit hängt von der Einbindung der Entwickler und der Prozessautomatisierung ab. Ein Hinweis darauf, dass viele Unternehmen noch nicht so weit sind, ist jedoch ein Nachsatz zu Punkt 1: Obwohl Einigkeit darüber herrschte, dass Sicherheit zum Standard gehören muss, waren mehr als die Hälfte der Befragten von einer Fehlkonfiguration oder bekannten ungepatchten Schwachstellen in ihren Cloud-Native-Anwendungen betroffen.

Betrachtet man die Zahlen genauer, waren die beiden häufigsten Vorfallarten mit deutlichem Abstand Fehlkonfigurationen (45 %) und bekannte ungepatchte Schwachstellen (38 %). Zusammengenommen erlebten 56 % der Befragten einen Vorfall mit einer Fehlkonfiguration oder einer bekannten ungepatchten Schwachstelle in ihren Cloud-Native-Anwendungen. Die tatsächliche Zahl liegt jedoch noch höher, denn 18 % der Befragten beantworteten diese Frage aufgrund ihrer Sensibilität nicht. Berücksichtigt man die Rücklaufquote von 82 % für diese Frage, hatten 69 % eine Fehlkonfiguration oder eine bekannte ungepatchte Schwachstelle in ihren Cloud-Native-Anwendungen.

Angesichts dieser bedeutenden Erkenntnisse zeigt sich: Entwickler übernehmen zwar mehr Aufgaben in den Bereichen Sicherheit und Betrieb, können jedoch ihre zunehmend infrastrukturbasierten Verantwortlichkeiten nicht angemessen bewältigen. Das heißt nicht, dass Entwickler dazu nicht in der Lage wären. Vielmehr ist ihre Arbeitslast gestiegen und die erforderlichen Kenntnisse sind breiter gefächert. Es ist an der Zeit, die neue Landschaft für Cloud-Native-Entwickler neu zu bewerten.

„Da Fehlkonfigurationen und bekannte Schwachstellen die größten Sorgen bereiten und Vorfälle verursachen, müssen wir überdenken, wie Entwicklungsteams Sicherheitsaufgaben priorisieren sollten. Wenn Entwickler für die Sicherheit der gesamten cloudnativen Anwendung verantwortlich sind, ist es oft wichtiger, dass sie sich um diese grundlegenden Sicherheitsprobleme kümmern als um Schwachstellen im individuell entwickelten Code der Anwendung, mit denen die meisten Sicherheitsprogramme beginnen.“

Besser hätte ich es nicht sagen können, Guy. Glücklicherweise lassen sich beide Probleme mit sicherheitsorientierten Entwickler-Tools lösen, die 1) Sicherheitslücken über alle Phasen des Entwicklungslebenszyklus hinweg ganzheitlich erkennen und 2) Kontext und Priorisierung für die Schwachstellen bereitstellen.

Schwachstellen lassen sich nicht isoliert betrachten – und erst recht nicht anhand ihres jeweiligen Bereichs priorisieren. Fehlkonfigurationen in der Infrastruktur können eine Anwendung für Angriffe weit öffnen, selbst wenn ihr Code gut abgesichert ist. Entwickler brauchen Tools, die sämtliche Schwachstellen und Fehlkonfigurationen in Code, Abhängigkeiten, Containern und Infrastruktur finden und anschließend eine umfassende, priorisierte Liste bereitstellen.

Bei der Priorisierung müssen der Schweregrad der Schwachstelle, der Reifegrad möglicher Angriffe und die Sichtbarkeit für Angreifer berücksichtigt werden. Ist eine Schwachstelle potenziell schwerwiegend, aber nur erreichbar, wenn Angreifer mehrere andere Sicherheitsebenen überwinden, sollte sie niedriger priorisiert werden. Lassen sich 100 Schwachstellen mit einem einzigen Update des Basis-Images beheben, sollte die Priorität steigen. Entwickler können unmöglich jede Schwachstelle beheben. Deshalb müssen sie wissen, worauf sie sich konzentrieren sollten.

Sicherheitstools müssen diesen umfassenden Kontext bereitstellen können, denn wir können nicht erwarten, dass jeder Entwickler ein Sicherheitsexperte ist – das wäre schlicht unrealistisch. Stattdessen sollten sicherheitsorientierte Entwickler-Tools als vertrauenswürdige Sicherheitsexperten fungieren, die stets im Werkzeugkasten der Entwickler bereitstehen. Die Hürden für mehr Sicherheit müssen so weit wie möglich gesenkt werden, damit Cloud-Anwendungen und -Infrastruktur geschützt sind.

Jedenfalls führt das schon ziemlich tief in ein einzelnes Thema aus dem Bericht State of Cloud Native Application Security. Wenn Sie bereits Cloud Native nutzen oder über einen Wechsel nachdenken, empfehle ich Ihnen dringend, den Bericht zu lesen. Sie können sich auch eine aktuelle Folge des Podcasts The Secure Developer anhören, in der Guy und ich den Bericht besprechen. Wenn Sie den Bericht gelesen (oder den Podcast angehört) haben und Ihre Cloud-Native-Application-Security mit Kontext versehen und priorisieren möchten, melden Sie sich kostenlos bei Snyk an.