Jeder weiß, dass Kubernetes den Containerkrieg gewonnen hat. Außer dass Kubernetes den Container- Runtime- Krieg gewonnen hat. Sie sehen, Docker hat den Container-Image-Krieg gewonnen. Dies lässt sich an der Statistik erkennen, dass laut dem State of Open Source Security Report 2019 alle zwei Wochen mehr als 1 Milliarde Docker-Container heruntergeladen werden. Docker Hub ist für Unternehmen das geworden, was Apples AppStore und Google Play für Verbraucher sind.
Container-Images decken die gesamte Bandbreite von Basisbetriebssystemen bis hin zu App-Stacks, von Datenbanken über Middleware bis hin zu App-Engines ab, die Node.js, Python und Go unterstützen. Sie umfassen sogar Ökosystemintegrationen für Anwendungsdienste .
Wenn Sie zu den meisten Organisationen gehören, die Container bereitstellen, stellen Sie wahrscheinlich Docker-Images in einer Kubernetes-Umgebung bereit.
Und wenn Sie das tun, stellen Sie wahrscheinlich auch anfällige Container-Images bereit. Die oben erwähnte Untersuchung von Snyk ergab, dass „jedes der zehn beliebtesten Standard-Docker-Images mindestens 30 anfällige Systembibliotheken enthält.“ Es sei üblich, heißt es in dem Bericht weiter, „dass in vielen Docker-Images Systembibliotheken verfügbar sind, da diese auf einem übergeordneten Image basieren, das üblicherweise eine Linux-Distribution als Basis verwendet.“
Es gibt also eine ganze Menge anfälliger Bilder, die ständig von Organisationen heruntergeladen werden. Laut Snyk nimmt die Zahl der Schwachstellen in allen drei großen Linux-Distributionen stetig zu.
Daher überrascht es nicht, dass Tripwires „State of Container Security 2019“ ergab, dass erstaunliche 60 % der Befragten in den letzten zwölf Monaten einen Container-Sicherheitsvorfall erlebt hatten. Bei fast jedem Fünften (17 %) liegt der Grund dafür wahrscheinlich darin, dass die Organisation sich der Schwachstellen bewusst war, sie aber trotzdem ausgenutzt hat. Und das, obwohl Snyk herausgefunden hat, dass für 44 % der Docker-Images, die bekannte Schwachstellen aufwiesen, neuere und sicherere Basis-Images verfügbar waren. Mit anderen Worten, das bloße Abrufen eines aktuellen Images hätte das Risiko gemindert. Bei weiteren 22 % der Images mit Sicherheitslücken hätte das Problem durch eine einfache Neuerstellung des Images behoben werden können.
Wirklich. So etwas kann ich mir nicht ausdenken.
Bei der „Verlagerung der Sicherheit nach links“ geht es vor allem um die Bereitstellung geeigneter Sicherheitsanwendungsdienste (BOT-Abwehr, Web Application Firewalls, Identitäts- und Zugriffskontrolle) und um die Einbindung sicherer Verfahren in den Entwicklungs- und Bereitstellungszyklus. Zu diesen Vorgehensweisen gehört das Scannen von Code und Containern auf bekannte Schwachstellen und deren anschließende Behebung .
Dieser Schwerpunkt galt für die 17 % von Ihnen, die von den Schwachstellen in einem Container-Image wussten, es jedoch ohne Behebung bereitgestellt haben.
Das können wir besser. Ja, Geschwindigkeit ist wichtig, aber Geschwindigkeit ohne Sicherheit ist gefährlich – nicht nur für das Unternehmen, sondern auch für die Kunden, die letztendlich die Apps verwenden, die Sie schnell auf den Markt bringen.
Wenn Sie die sichere Containerisierung noch nicht praktizieren, sollten Sie die folgenden Schritte in die Praxis umsetzen: