Skip to main content

31 % erfassen keine Anwendungsabhängigkeiten, 38 % nur direkte Abhängigkeiten

Artikel von
DevSecOps Assets blog feature

28. Januar 2020

0 Min. Lesezeit

Kürzlich haben wir eine Studie zur Einführung von DevOps und DevSecOps durchgeführt. In diesem Artikel betrachten wir, wie gut Unternehmen auf die Einführung von DevSecOps vorbereitet sind und wie sich der DevOps-Reifegrad auf die Integration von Sicherheit auswirkt. Außerdem gehen wir auf die Erkenntnisse zur Sicherheitslage der Teams ein, die DevOps eingeführt haben.

PDF herunterladen: DevSecOps Insights 2020


Wie gut Unternehmen auf die Einführung von DevSecOps vorbereitet sind

Bei der Untersuchung, wie Entwicklerteams ihre Codebasen überprüfen, zeigt sich laut dem Snyk-Bericht „State of Open Source Security 2019“ eine starke Nutzung automatisierter Sicherheitstools: 65 % der Befragten bestätigen dies. Wichtig ist auch: Selbst wenn automatisierte Sicherheitstools zum Einsatz kommen, nutzen 79 % der Befragten weiterhin Sicherheits-Code-Reviews.

Balkendiagramm mit dem Titel „Wie prüfen Sie Ihren Code?“: Manuelle Prüfung 79 %, automatisierte Sicherheitstests 65 % und andere Methoden.

Mit der Einführung automatisierter Sicherheitstools erkennen Teams auch, dass deren Integration in eine CI-Pipeline die Build-Zeit verlängert. Das verschlechtert die Entwicklererfahrung und die Feedbackschleife.

Wir haben festgestellt, dass 57 % der Befragten ihre Open-Source-Abhängigkeiten auf bekannte Sicherheitslücken prüfen, während ein deutlich geringerer Anteil statische Anwendungssicherheitstests (SAST) durchführt.

Balkendiagramm zur Frage, ob automatisierte Sicherheitstests in Continuous-Integration-Pipelines enthalten sind; die Ergebnisse reichen von 14 % bis 57 %.

Das liegt häufig daran, dass diese Art von Sicherheitstests lange Laufzeiten hat und zudem einen hohen Anteil falsch positiver Ergebnisse liefert, die anschließend manuell überprüft werden müssen.

Etwas mehr als die Hälfte der Befragten bestätigte, bekannte Sicherheitslücken in den Open-Source-Abhängigkeiten ihrer Anwendungen zu prüfen. Doch nur 14 % führen eine ähnliche Prüfung von Container-Images innerhalb einer CI-Pipeline durch. Wissen die Befragten möglicherweise nicht, welche Sicherheitstools verfügbar sind, um diese Lücke zu schließen? Eine weitere Möglichkeit: Bei den meisten Sicherheitstools erhalten Sie lediglich einen Bericht über die im Container-Image vorhandenen Sicherheitslücken. Die tatsächliche Behebung des Problems bleibt jedoch Ihnen überlassen.

Docker-Image-Sicherheitsdashboard mit Empfehlungen zum Upgrade des Basis-Images, Schwachstellenzahlen und Schweregraden

Zum Vergleich: Snyk Container gibt konkrete Empfehlungen in Form alternativer Container-Images. Mit ihnen lässt sich die Zahl der Sicherheitslücken verringern und die allgemeine Sicherheitsgefährdung minimieren.

Das Basis-Image eines Docker-Containers auszutauschen, ist eine einfach umzusetzende Maßnahme mit hohem Sicherheitsnutzen. Scans von Snyk-Nutzern zeigen: Laut dem Snyk-Bericht „State of Open Source Security“ enthielten 44 % der Docker-Image-Scans bekannte Sicherheitslücken, obwohl neuere und sicherere Basis-Images verfügbar waren.

Container-Sicherheit umfasst mehr als nur Docker-Container-Images. Auch Kubernetes ist betroffen, etwa durch Sicherheitsprobleme in Form von Sicherheitslücken in Helm-Charts. Der Snyk-Bericht von 2019 Uncharted territories: the untold tale of Helm Chart security deckte mehrere Risiken in diesem Bereich auf:

  • 68 % der stabilen Helm-Charts enthalten ein Image mit einer Sicherheitslücke hohen Schweregrads.

  • Bei 64 % der stabilen Helm-Charts lässt sich die Zahl der Sicherheitslücken durch ein Update auf die neuesten veröffentlichten Images verringern.

  • 6 Images (von insgesamt 416) sind für die Hälfte aller Sicherheitslücken verantwortlich.

Wenn die Anwendung selbst oder ihr Trägermedium – beispielsweise Container-Images, die zum Bereitstellen der Anwendung dienen – im Mittelpunkt der Sicherheit stehen, tragen Entwickler eine zentrale Verantwortung für die Sicherheit ihrer Anwendung. Wie sieht es mit der Verantwortung für die Sicherheit der Infrastruktur aus? Überraschenderweise tragen in einer DevSecOps-Umgebung alle beteiligten Parteien nahezu gleichermaßen Verantwortung für die Infrastruktursicherheit.

Lesen Sie unseren neuen Open Source Security Report 2020. Dieser Bericht beleuchtet die Herausforderungen rund um Open-Source-Sicherheit im Jahr 2020 sowie Trends bei Sicherheitslücken in Paketen und Container-Images.


Lesen Sie weitere Ergebnisse aus unserer Studie DevSecOps Insights 2020:

PDF herunterladen: DevSecOps Insights 2020