Das ist zwar ein guter Anfang, aber Sie sollten nicht vergessen, dass Sicherheit ein fortlaufender Prozess ist und kein einmaliges Ereignis. Diese Scans, die in den Entwicklungspipelines bestanden wurden, bedeuten nur, dass Ihre Anwendungen zum Zeitpunkt der Bereitstellung gesichert waren. Was ist mit einem Tag, Monat oder Jahr später?

In der Realität wird nicht jede Anwendung täglich erstellt und bereitgestellt, und das kann bedeuten, dass Ihr absolut sicherer Kubernetes-Cluster tatsächlich voller Fehlkonfigurationen und CVEs ist. Aus diesem Grund ist es wichtig, ein robustes Sicherheitsniveau zu etablieren, das auch laufende Schwachstellenanalysen umfasst.

Sehen Sie, wie Ihre Basis-Images heute abschneiden

Sicherung jeder Ebene Ihrer Kubernetes-Infrastruktur

Wir bei Mondoo wissen, dass die Sicherung jeder Ebene Ihrer Kubernetes-Infrastruktur, einschließlich der Anwendungs-Images, für einen umfassenden Sicherheitsansatz unerlässlich ist. Aus diesem Grund haben wir einen umfassenden Sicherheitsansatz entwickelt, der Ihnen hilft, Ihre Infrastruktur von der Entwicklung bis zur Außerbetriebnahme zu schützen.

Unser Policy-as-Code-Sicherheitsansatz und unsere sofort einsatzbereiten Sicherheitsrichtlinien machen es einfach, sicherzustellen, dass Ihre Infrastruktur in jeder Entwicklungsphase sicher ist. Wir bieten Ihnen auch die Möglichkeit, Images lokal oder in Ihrer CI/CD-Pipeline zu scannen, um häufige Fehlkonfigurationen und veraltete Pakete mit CVEs zu identifizieren. Auf diese Weise können Sie Probleme beheben, bevor sie überhaupt in die Produktion gelangen.

Aber wir hören hier nicht auf. Sobald die Workloads bereitgestellt wurden, scannt unser Kubernetes-Operator die Images kontinuierlich, während neue CVE-Daten veröffentlicht werden. Auf diese Weise können Sie neue CVEs in zuvor bereitgestellten Anwendungen identifizieren und Container neu erstellen, um kritische Sicherheitslücken zu beheben.

Die alarmierende Realität der Akkumulation von CVEs in Container-Bildern

Was passiert mit der Sicherheit der Anwendungscontainer, die in der Produktion laufen, wenn Teams wöchentlich, monatlich oder sogar nur einmal im Jahr bereitstellen? Bei Mondoo waren auch wir neugierig auf diese Frage, also haben wir unser Sicherheitsforschungsteam beauftragt, das Problem zu untersuchen.

Ihre Ergebnisse waren alarmierend. Bei Container-Images sammelt sich im Laufe der Zeit eine überraschend große Anzahl von CVEs an, die je nach Art des verwendeten Basisimages stark variiert. Traditionelle Linux-Distributionen wie Debian und Ubuntu häufen innerhalb kurzer Zeit eine große Anzahl von CVEs an, während containeroptimierte Betriebssysteme wie Alpine deutlich weniger CVEs verzeichnen (aber nach nur wenigen Monaten immer noch kritische CVEs). Selbst Container-Images für Programmiersprachen wie Ruby oder Python, die auf Debian basieren, weisen im Laufe der Zeit eine große Anzahl von CVEs auf.

Diese Ergebnisse unterstreichen die Bedeutung eines kontinuierlichen Schwachstellenmanagements für Kubernetes-Cluster. Durch die kontinuierliche Überwachung von Container-Images und die Behebung von Sicherheitslücken können Sie die Risiken mindern, die mit veralteten oder anfälligen Images verbunden sind.

CVEs im Laufe der Zeit verfolgen: Ein tiefer Einblick in das Scannen von Container-Images auf Docker Hub

Bei Mondoo wollten wir ein besseres Gefühl dafür bekommen, wie viele CVEs sich im Laufe der Zeit in Container-Images ansammelten. Deshalb haben wir Container-Image-Tags für einige der beliebtesten Basis-Images auf Docker Hub gezogen. Wir haben jedes dieser Container-Image-Tags gescannt und die Ergebnisse aufgezeichnet und sie bereinigt, um Testversionen und einmalige Tags zu entfernen.

Bei der API von Docker Hub sind wir jedoch auf eine Hürde gestoßen. Sobald ein Tag überschrieben wurde, können wir nicht mehr jedes Bild abfragen, das für dieses Tag veröffentlicht wurde. Dadurch ist es unmöglich, die Sicherheit gängiger Tags wie „aktuell“ oder „stabil“ nachzuverfolgen. Um dieses Problem zu umgehen, verwenden wir im Laufe der Zeit Versions-Tags für Projekte. Zum Glück werden die meisten Projekte relativ regelmäßig veröffentlicht, was uns einen guten Einblick in die Sicherheit des Containers gibt.

Minderung von CVE-Risiken in Container-Images

Wie lange dauert es nach der Bereitstellung, bis ein CVE zu einem Problem wird? Die Antwort ist nicht einfach und hängt von mehreren Faktoren ab. Unsere Recherchen ergaben, dass viele der beliebten Docker-Hub-Images in ihren aktuellen Versionen mehrere CVEs enthielten, während andere nur CVEs in älteren Versionen enthielten, die mehrere Wochen alt waren. Als Benutzer können Sie die Anzahl der CVEs in Ihren Anwendungs-Images im Laufe der Zeit reduzieren, indem Sie diese Basis-Images ändern. Schauen wir uns die wichtigsten Erkenntnisse aus unserer Forschung genauer an und untersuchen, wie Sie CVE-Risiken mindern können.

Die Wichtigkeit, das richtige Container-Image auszuwählen

Einer der wichtigsten Faktoren, der die Anzahl der CVEs bestimmt, die im Laufe der Zeit in Container-Images entstehen, ist die Art des verwendeten Container-Images. Traditionelle Betriebssystem-Images wie Debian, Amazonlinux oder Ubuntu enthalten aufgrund der Anzahl der darin enthaltenen Pakete tendenziell mehr CVEs in kürzerer Zeit. Im Gegensatz dazu haben kleinere, containeroptimierte Images wie Alpine deutlich weniger CVEs, wobei nach 3 Monaten nur 38% davon in Debian, 23% in Ubuntu und nur 8% in Amazonlinux zu finden sind. Wenn Sie sich für containeroptimierte Images entscheiden, können Sie die Notwendigkeit reduzieren, Anwendungen ständig neu zu erstellen und erneut bereitzustellen, um CVEs von Ihrer Produktionsinfrastruktur fernzuhalten. Dies ist ein einfacher und effektiver Sicherheitsgewinn.

Containeroptimierte Anwendungsvarianten

Neben der Verwendung containeroptimierter Images für Ihre eigenen Anwendungen ist es auch wichtig, diese Images für Open-Source-Projekte auszuwählen, die in Ihrer Infrastruktur ausgeführt werden. Projekte wie Nginx und Ruby liefern verschiedene Varianten ihrer Anwendungscontainer aus, und die Bereitstellung der containeroptimierten Varianten ist eine hervorragende Möglichkeit, die Anzahl der Sicherheitslücken in diesen Drittanbieteranwendungen zu reduzieren.

Die Unterschiede zwischen den Ruby-Varianten waren vielleicht das schockierendste Ergebnis. Ein Standard-Ruby 2.6.6-Container aus dem Jahr 2021 hat satte 401 CVEs, während die alpine Variante desselben Containers nur 23 CVEs hat.

Auswahl schlanker Container-Images für ältere oder kommerzielle Anwendungen

In Situationen, in denen die Umstellung auf vollständig reduzierte, containeroptimierte Images nicht möglich ist, wird empfohlen, schlanke Container-Images als Basis für Ihre Container zu verwenden. Slim-Images sind Standard-Images von Linux-Distributionen wie Debian oder Ubuntu, allerdings mit weniger zusätzlichen Paketen, die potenzielle Sicherheitslücken mit sich bringen können. Diese Container-Images erfordern zwar mehr Aufwand, um fehlende Pakete für die Neuinstallation zu testen und zu finden, aber sie führen zu sichereren Anwendungen, die nicht so oft neu erstellt werden müssen. Dies ist besonders nützlich für kommerzielle Anwendungen oder ältere Apps, die nie für die Containerisierung vorgesehen waren.

Basis-Images aktualisieren: mehr als nur die neuesten abrufen

Leider werden CVEs in Ihren Anwendungscontainern nicht immer aufgelöst, wenn Sie sich ausschließlich auf das neueste Basis-Image verlassen. Viele beliebte Basis-Images, wie Debian und Alpine, werden ständig neu erstellt und neu markiert, wenn neue CVEs herauskommen, während andere wie Oraclelinux nur neu erstellt werden, wenn ein neues Betriebssystem veröffentlicht wird. Infolgedessen können Anwendungen, die mit dem neuesten Oracle Linux-Basiscontainer erstellt wurden, Dutzende von CVEs enthalten, einschließlich Sicherheitslücken in kritischen Bibliotheken wie OpenSSL. Auch wenn Sie diese Container nicht direkt verwenden, verwenden Sie möglicherweise Sprachcontainer wie Openjdk oder Python, die mit diesen ungepatchten Basis-Images erstellt wurden. Um dieses Problem zu beheben, ist es wichtig, zu Basis-Images zu wechseln, die kontinuierlich aktualisiert werden, wie Debian oder Alpine, und die Basis-Betriebssystempakete immer als Teil Ihres Container-Build-Prozesses zu aktualisieren. Ein einfaches `yum upgrade -y` oder `apt-get update; apt-get upgrade -y` in Ihrer Container-Image-Pipeline trägt wesentlich zur Sicherung Ihrer Umgebung bei.

Dieses MySQL-Image enthält Debian- oder Oracle-basierte Images. Die neuesten Debian-Images haben 1 CVE, während die Oracle-basierten Images standardmäßig 25 CVEs haben.

Nutzen Sie das Potenzial des CVE-Scannings für die Containersicherheit

Nach umfangreichen Recherchen haben wir festgestellt, dass die Einführung von CVE-Scans in den Phasen des Container-Lebenszyklus von entscheidender Bedeutung ist. Ebenso wichtig ist es, sicherzustellen, dass nur sichere Container in die Produktion aufgenommen werden und dass diese Images sicher bleiben, indem laufende Container-Images in Kubernetes-Clustern gescannt werden. Durch richtiges Scannen von Bildern und Warnmeldungen können Teams sicherstellen, dass die Workloads, die sie täglich bereitstellen, sicher sind.

Wenn Sie nach einer umfassenden Lösung zum Scannen Ihrer Container suchen, registrieren Sie sich noch heute für ein kostenloses Mondoo-Konto. Unsere Plattform ermöglicht es Ihnen, Docker-Images, private Registries, laufende Container oder Images in Kubernetes-Clustern zu scannen. Mit Mondoo können Sie Images mit kritischen CVEs finden, Sicherheitslücken, die Angreifer hineinlassen, neu aufbauen und beheben.