Near-Zero-CVE: Sisyphusarbeit oder echte Security?

Zero CVE Image

Scratch

Beginnen wir mit dem Klassiker und dem einzigen Image überhaupt, das den Titel Zero-CVE-Image erhält. Bereits der berühmte Cloud-Native Advocate Kelsey Hightower wusste, dass der sicherste Code kein Code ist („No code is the best way to write secure and reliable applications. Write nothing; deploy nowhere.“). Docker bietet schon seit Jahren die Möglichkeit, statische Binaries mit dem sogenannten Scratch Base Image zu nutzen. Das Scratch Image ist ein komplett leeres Image. Es enthält wirklich nichts, keine Tools, keinen Package Manager, kein OS und ein komplett leeres Filesystem.

Jedoch eignet sich das Scratch Image nur für einige wenige Anwendungsfälle. Die meisten Apps werden ohne zusätzliche Packages und Runtimes nicht lauffähig sein.

Near Zero CVE Images

Wir haben bereits in einem letzten Blogpost gezeigt, wie wir Chainguard Images als Drop-In Replacement für die offiziellen Jenkins- und Dependency Track Images eingesetzt haben. Seit diesem Beitrag ist wieder einiges passiert. Unterdessen gibt es eine Vielzahl an Dienstleistern, welche solche Images anbieten. Wir möchten euch hier ein zwei weitere Alternativen zu Chainguard Images vorstellen:

Docker Hardener Images (Free & Enterprise)

Dies ist das neueste Produkt von Docker. Sie bieten über ihren Katalog eine grosse Auswahl von Applikationen und Base Images an. Die Docker Hardened Images basieren fast alle auf einer minimalen Debian- oder Alpine Distribution, welche anschliessend weiter gehärtet wird. Die Free Version von Docker Hardened Images ist ein guter Einstieg, um die Anzahl von CVEs zu reduzieren. Jedoch bietet das Docker Free Tier keine SLAs betreffend einer zeitnahen Behebung von Critical CVEs. Dies ist explizit der Enterprise Version vorbehalten.

Red Hat Hardened Images (ehemals Projekt Hummingbird)

Red Hat bietet unterdessen auch Hardened Images an. Diese sind basierend auf RHEL Linux und werden ebenfalls gehärtet, indem alle nicht benötigten Pakete aus dem Image entfernt werden. Red Hat Hardened Images sind eine gute Wahl, wenn die bestehenden Container und Builds auf Red Hat UBI Images basieren.

Vergleich der verschiedenen Hersteller

Wir haben hier bewusst auf die Angabe der Kataloggrösse / Anzahl Images verzichtet, da sich dieser Wert sehr schnell ändert. Grundsätzlich unterscheidet sich das Angebot der Images unter den verschiedenen Anbietern nicht gross, oder die jeweiligen Anbieter sind bereit, auf Anfrage neue Images mit in den Katalog aufzunehmen. Der wohl grösste Unterschied zwischen den Anbietern besteht in ihren SLAs, die definieren, wie schnell Lücken geschlossen werden. Dies reicht z.B. bei Critical CVEs von None (DHI Free) bis zu Fixes innerhalb von 7 Tagen (Chainguard).

Migration der Base Images

Um die Vergleichbarkeit zu wahren, haben wir für alle nachfolgenden Szenarien konsequent Multi-Stage-Builds angewendet. Bei diesem Verfahren wird der Build-Prozess in mehrere isolierte Phasen (Stages) unterteilt, sodass Build-Werkzeuge und temporäre Dateien strikt von der Laufzeitumgebung getrennt bleiben. Dabei wurden nur die Runtime-Dependencies in das finale Image übernommen. Der Hauptunterschied liegt somit primär im gewählten Base-Image.

Doch was bedeutet das nun in der Praxis? Besonders auch in Bezug auf die Anzahl CVEs? Um diese Frage zu beantworten, haben wir versucht, mit den verschiedenen Images unser Backstage-Portal neu zu bauen, und anschliessend zu messen, wie gross der Unterschied ausfällt in Bezug der vorhandenen CVEs. Der aktuelle Stack basiert auf einem Debian basierten Container mit Node 22. Da das Projekt über 3’000 verschiedene Node Package Dependencies enthält, eignet es sich als Test besonders gut. Das Image wurde bis jetzt nicht speziell auf wenig CVEs getrimmt und wurde auch schon länger nicht mehr aktualisiert. Dies ist leider ein gängiges Szenario, da neue Features in vielen Projekten oft Vorrang vor regelmäßigen Updates haben.

Wir haben folgende Images verglichen:

• Baseline: Bestehendes Backstage Image (Debian Trixie), seit 6 Monaten nicht aktualisiert.
• Node Official: Vollwertiges Debian Linux 13 mit Node 22.
• Node Slim: Reduziertes Debian Image mit NodeJS.
• Docker Hardened Images NodeJS: Gehärtetes Image von Docker.
• RHI NodeJS: Gehärtetes Red Hat Image auf RHEL-Basis.
• Chainguard NodeJS: Gehärtetes Image auf Wolfi Linux-Basis mit eigenem Package Manager.

Bevor wir mit dem Vergleich starten, werfen wir erstmal ein Blick auf die zu verwendenden Basis Images und deren CVE Anzahl. Für das Erstellen des CVEs Reports verwendeten wir Trivy. Zusätzlich haben wir für unsere Tests bewusst allfällig vorhandene VEX Daten zu ignorieren, damit wir einen absoluten Wert haben.

Aktuell verwenden wir als unser Base Runtime Image das offizielle node:22 Image. Dieses Image basiert auf einem vollwertigen Debian 13 Base Image und weist wie erwartet die meisten CVEs auf. Es ist auch das Image welches am meisten unnötigen Ballast mitführt. Darüber hinaus ist z.B. Debian eine vollwertiges Linux OS inklusive Kernel. Auch wenn dieser für den Container betrieb nicht benutzt wird und mit dem Shared Host Kernel ersetzt wird, führt das Vorhandensein häufig zu False-Positive-Meldungen über Kernel CVEs. Wir können anhand des Diagram sehr schnell erkennen, das bereits der Wechsel zu einem Slim Image enorme Verbesserung hinsichtlich der Anzahl CVEs bringt. Ein solcher Wechsel ist normalerweise mit nur minimalen Änderungen im Dockerfile machbar. Was weiter auffällt, ist, dass das Docker Hardened Image immer noch 9 CVEs enthält, obschon es als 0-CVE Image angeboten wird. Der Grund liegt in den sogenannten VEX Dokumenten welche im Image enthalten sind. VEX Dokumente sind Maschinen lesbare Beglaubigungen, dass eine vorhandene Schwachstelle in diesem Kontext nicht ausgenutzt werden kann, und somit von Security Scanners ignoriert wird.  Technisch gesehen sind die Schwachstellen also noch vorhanden, sollten aber bei sachgemässer Konfiguration im Image nicht nutzbar sein.  Docker selbst stellt diese Informationen auch über die Website zur Verfügung (z.B. das verwendete Node 22 Image, wo detailliert aufgelistet ist, welche CVEs aus welchen Gründen unterdrückt werden)

Ergebnisse

Nach dem Build haben wir die Runtime Images erneut gescannt. Das bisherige Backstage-Image wurde als Referenzwert genommen. Dies Umfasst zum Zeitpunkt des Scans knapp über 3’000 CVEs. Leider sind eine solch hohen Anzahl von CVEs keine Seltenheit. Wir stolpern immer wieder über produktiv verwendete Images, welche einige Tausend CVEs besitzen. Die beiden häufigsten Ursachen sind dabei:

• Dependencies der Applikationen sind nicht mehr aktuell und Updates werden nicht automatisiert eingespielt
• Entwicklungs- und Debugging Tools welche vergessen werden, und schlussendlich in einem Runtime Image mitgeliefert werden.
• Komplettes fehlen von Multi Stage Builds

Wie wir sehen, können wir mit nur kleinem Aufwand die Angriffsfläche enorm reduzieren.

• Aktualisierung der App Dependencies
• Konsequente verwendung von Multi Stage Builds mit dedizierten Runtime Images
• Keine Dev Tools in Runtime Images
• Minimale Images oder Hardened Images

Mit diesen einfachen Schritten konnten wir die Anzahl non-fixable CVEs um 95% reduzieren. Mit der Verwendung von Hardened Images sogar bis zu 99% weniger CVEs im Vergleich zu unserem aktuell produktiv laufenden Container Image.

Direktvergleich

Im Direktvergleich der beiden Runtime Image Varianten mit Debian Trixie und Chainguard, lässt sich gut erkennen, dass durch das Entfernen von nicht benötigten Packages und OS Komponenten viel Platz eingespart werden kann, und gleichzeitig die Angriffsfläche reduziert wird. Im Umkehrschluss lässt sich aber auch darauf schliessen, dass nun die grösste Angriffsfläche noch die Node Module sind, welche rund 90 % des Chainguard Images ausmachen.

Limitationen von Hardened Images in der Supply Chain

VEX-Herausforderung

Wie bereits erwähnt, basieren die meisten DHI auf einem Alpine oder Debian Base Image. Dieses Image wird anschliessend gehärtet, indem nicht benötigte Software Komponenten entfernt werden. Im Gegensatz zu Chainguard Images erlaubt es sich Docker, die Images auch mit bekannten CVEs auszuliefern, wenn diese in dieser spezifischen Konfiguration nicht auszunutzen sind. Diese Ausnahmen werden in sogenannten VEX Statements festgehalten und mit dem Image ausgeliefert. Dies führt aber dazu, dass einige CVE Scanners diese CVEs trotzdem listen.

Die Supply-Chain-Kontrolle

Ein weiterer wichtiger Unterschied der verschiedenen Anbieter ist die grundlegende Kontrolle der Supply-Chain. Eine Firma wie Docker ist primär ein Distributor von Containern. Somit haben sie nur begrenzten Einfluss darauf, was wie gebündelt wird. Die meisten Anbieter von Hardened Images bieten deshalb auch eigene Package Repositories an. Chainguard und Docker z.B. bauen sämtliche über APK/APT angebotene Packages selbst aus dem Source Code der jeweiligen Open Source Repositories.

Folgende Grafik illustriert, dass OS Packages von Docker selbst vom Source Code gebaut werden und so in das Image integriert werden.

Supply Chain Security mit Chainguard

Chainguard verfolgt einen ganzheitlichen Ansatz, indem versucht wird, die ganze Software-Lieferkette mit dem Build-From-Source Prinzip so weit wie möglich abzudecken. Konkret heisst das, dass Chainguard nicht einfach nur Software und Linux Distro als Container Image bündelt, sondern diese auch selbst aktiv aus dem Source Code in der sogenannten Chainguard Factory selbst baut, und diese auch selbst vertreibt. Somit kann vom Container OS (Wolfi), über die System Packages (APKOs) bis hin zu den NodeJS Modules (Chainguard Libraries) alles aus einer vertrauenswürdigen Quelle bezogen werden, welche sicherstellt, dass nur Software ausgeliefert wird, welche dem Source Code im Git Repository entspricht.

Diese Chainguard Libraries gibt es ausserdem auch für Java und Python. Wobei die Mithilfe von Chainguard bei diesen Ökosystemen sogar noch weiter geht. Bei Python contributed Chainguard auch aktiv Code, welcher hilft die Sicherheitslücken schneller zu fixen, und lässt diese wieder in den Upstream einfliessen.

Fazit und Empfehlung

Einer der wichtigsten und nicht zu unterschätzenden Gründe, warum man auf minimale oder hardened Images setzten sollte ist das Baseline Patching. Wir sehen bei unseren Kunden viel zu häufig produktive laufende Container Images welche bis zu  4’000 und mehr CVEs aufweisen. Kaum jemand wird oder kann sich die Zeit nehmen für ein einziges Image, alle 4’000 CVEs einzeln zu prüfen, und diese anschliessend zu triagieren und patchen. Dies gleicht eher eine Sisyphusarbeit. Dabei bietet es sich an, Near-Zero-CVE Images einzusetzen, und damit die Anzahl der CVEs bereits vor der ersten Prüfung massiv zu verringern. Auch langfristig gesehen reduziert dieser Ansatz den Aufwand für das Prüfen von CVEs.

Supply Chain Security ist und bleibt auch zukünftig ein heiss diskutiertes Thema, welches auch ernst genommen werden sollte. Wir empfehlen, wo immer es mit vertretbarem Aufwand möglich ist, die Angriffsfläche so weit wie möglich zu reduzieren. Bereits der Einsatz von Multi-Stage Builds in Zusammenspiel mit Minimal Images kann schon zu einer klaren Verbesserung führen. Gerade bei 3rd Party Software wie z.B. Postgres, Redis bieten praktisch alle Anbieter Drop-In Replacements an.

Werden die Container Images aber als Base Images verwendet, zum Bauen und Vertreiben von eigenen Applikationen, sind Chainguard Images und Libraries die passende Lösung. Doch dazu mehr im nächsten Blogbeitrag.

Wie sicher ist deine Supply Chain?

Das Thema „Minimal Images“ ist nur ein Baustein einer robusten Software-Lieferkette. Wir sehen in der Praxis, dass der Wechsel auf gehärtete Images nicht nur die Sicherheit erhöht, sondern auch den operativen Overhead beim Patch-Management massiv reduziert.

Habt ihr bereits Erfahrungen mit dem Wechsel auf Chainguard oder anderen Hardened-Image-Anbietern gemacht? Oder kämpft ihr noch mit der Komplexität eurer Build-Pipelines? Wir diskutieren das Thema gerne mit euch oder führen auch unseren “Secure Supply Chain Readiness Check” mit euch zusammen durch. Kontaktiert uns oder hinterlasst einen Kommentar – und bleibt dran: Im nächsten Beitrag beleuchten wir, wie man Chainguard Libraries in Java- und Python-Umgebungen effektiv einsetzt.