Container-Images ohne CVEs: BellSofts neuer Buildpacks-Builder

Ein neuer Standard für sichere Container-Images

Das Unternehmen BellSoft hat einen signifikanten Schritt zur Verbesserung der Sicherheit in Cloud-nativen Umgebungen unternommen. Mit der Einführung eines neuen, gehärteten Builders für Paketo Buildpacks bietet der Hersteller eine Lösung an, die es Entwicklerteams ermöglicht, Container-Images zu erstellen, die weitgehend frei von bekannten Sicherheitslücken (CVEs) sind. Das Besondere an diesem Ansatz ist der Verzicht auf die manuelle Pflege von Dockerfiles. Stattdessen nutzt BellSoft sein eigenes, schlankes Linux-Betriebssystem Alpaquita als Basis. Diese Neuerung richtet sich primär an Enterprise-Teams, die unter hohem Druck stehen, komplexe Sicherheits- und Compliance-Anforderungen zu erfüllen, ohne dabei die Agilität ihrer Entwicklungsprozesse zu gefährden. Durch die Automatisierung der Image-Erstellung und die Integration gehärteter Basis-Images sollen Unternehmen in die Lage versetzt werden, ihre Software-Lieferkette effizienter und sicherer zu gestalten. Die Ankündigung unterstreicht den wachsenden Bedarf an automatisierten Sicherheitslösungen in der modernen Softwareentwicklung, bei der die manuelle Konfiguration von Containern zunehmend als Sicherheitsrisiko und Effizienzbremse wahrgenommen wird.

Technische Details und die Rolle von Alpaquita

Der Kern des neuen Builders bildet das Alpaquita-Betriebssystem von BellSoft. Dieses Linux-Derivat wurde gezielt für den Einsatz in Container-Umgebungen entwickelt und zeichnet sich durch eine gehärtete Standardkonfiguration aus. Zu den wesentlichen Sicherheitsmerkmalen gehören der konsequente Non-Root-Betrieb, eine stark reduzierte Paketbasis sowie die Verwendung unveränderlicher Komponenten. Wenn eine Anwendung mit dem neuen Builder erstellt wird, erbt sie automatisch diese Sicherheits- und Compliance-Eigenschaften. BellSoft ersetzt dabei sowohl den Build-Stack als auch den Run-Stack der Paketo Buildpacks durch seine Alpaquita-basierten Hardened Images. Das bedeutet, dass jede Anwendung, die durch den Prozess läuft, unmittelbar auf dem gehärteten Betriebssystem aufsetzt. Unterstützt werden dabei die Architekturen x86-64 und ARM64, wobei die Images sowohl für musl als auch für glibc als C-Standardbibliothek zur Verfügung stehen. Diese technische Tiefe stellt sicher, dass Unternehmen nicht nur eine theoretische Sicherheit erhalten, sondern eine praktisch anwendbare Basis für ihre produktiven Workloads.

Unterstützung von Programmiersprachen und Versionen

Ein wesentlicher Aspekt des Builders ist seine breite Unterstützung für verschiedene Programmiersprachen und Laufzeitumgebungen. BellSoft hat den Builder so konzipiert, dass er eine Vielzahl von modernen Sprachen abdeckt, darunter Python, Go, Node.js und Ruby. Für Python wird beispielsweise die Version 3.14 unterstützt, während für Go die Version 1.26 und für Node.js die Version 24 bereitstehen. Ein besonderer Fokus liegt auf Java: Hier greift der Builder auf das Liberica JDK Lite zurück, das speziell für Cloud-Workloads optimiert wurde. Dies ermöglicht nicht nur eine hohe Kompatibilität, sondern reduziert laut Herstellerangaben die finale Image-Größe von Java-Containern um mindestens 30 Prozent im Vergleich zu Standard-OpenJDK-Images. Die Abdeckung umfasst dabei die LTS-Versionen 8, 11, 17 und 25 sowie jeweils die aktuellste JDK-Version. Auch das Liberica Native Image Kit (Liberica NIK) in den Versionen 22 und 23 ist Teil des Portfolios, was den Builder für eine breite Palette von Anwendungen attraktiv macht.

Hintergrund und die Philosophie der Paketo Buildpacks

Die Entscheidung von BellSoft, auf Paketo Buildpacks zu setzen, ist kein Zufall. Paketo Buildpacks ist ein Open-Source-Projekt der Cloud Native Computing Foundation (CNCF), das darauf abzielt, die Erstellung von OCI-konformen Images zu standardisieren und zu vereinfachen. Die Grundidee besteht darin, aus dem Quellcode automatisiert produktionsfertige Images zu generieren, ohne dass ein Entwickler ein komplexes Dockerfile schreiben, pflegen oder aktualisieren muss. Ein Buildpack erkennt dabei automatisch die verwendete Sprache und die notwendigen Abhängigkeiten, führt bei Bedarf die Kompilierung durch und produziert in einem einzigen Schritt ein minimales, reproduzierbares Image. Ein wichtiger Bestandteil dieses Prozesses ist die Erstellung einer Software Bill of Materials (SBOM), die für die Transparenz der enthaltenen Komponenten sorgt. Durch die Kapselung dieser Funktionalität in den neuen BellSoft-Builder profitieren Unternehmen von einem einheitlichen Prozess, der den Wartungsaufwand massiv reduziert, da statt Hunderter individueller Dockerfiles nur noch ein zentraler Build-Prozess verwaltet werden muss.

Compliance und regulatorische Anforderungen

In der heutigen Enterprise-IT sind Sicherheitszertifizierungen und Compliance-Nachweise unverzichtbar. BellSoft adressiert dies durch ein umfassendes Vulnerability-Management, das über die bloße Bereitstellung von Images hinausgeht. Zum Release-Zeitpunkt versprechen die Hardened Images niedrige bis keine bekannten CVEs. Darüber hinaus bietet der Anbieter ein SLA-gestütztes Management an, bei dem nach der Offenlegung einer kritischen Schwachstelle innerhalb von etwa 24 Stunden ein gepatchtes Image zur Verfügung gestellt wird. Jede veröffentlichte Version wird mit einer vollständigen SBOM und einer verifizierbaren Herkunft ausgeliefert. Dies ist entscheidend, um Audits und regulatorische Anforderungen zu erfüllen, wie sie beispielsweise durch FedRAMP, DISA STIG, den EU Cyber Resilience Act (CRA) oder den Digital Operational Resilience Act (DORA) vorgegeben werden. Einzuordnen ist dies als strategische Unterstützung für Unternehmen, die ihre digitale Souveränität stärken wollen und eine verlässliche Basis für ihre Cloud-Infrastruktur benötigen, um den wachsenden Anforderungen an die Cyber-Resilienz gerecht zu werden.

Die Perspektive für Anwender und Migration

Für Teams, die bereits den bisherigen BellSoft-Builder im Einsatz haben, gestaltet sich der Umstieg laut Hersteller sehr komfortabel. Ein einfacher Rebuild in Verbindung mit der Option `--pull-policy always` reicht aus, um auf den neuen Builder und die aktuellsten Buildpacks zu migrieren. Für Unternehmen, die bisher auf klassische Dockerfiles setzen, empfiehlt BellSoft jedoch ein vorsichtiges Vorgehen. Es wird geraten, die Migration zunächst an einem nicht-kritischen Service zu testen, um die Kompatibilität der Anwendung mit der neuen, gehärteten Umgebung sicherzustellen. Dieser stufenweise Ansatz soll sicherstellen, dass die Vorteile der Automatisierung und Sicherheit genutzt werden können, ohne die Stabilität bestehender Dienste zu gefährden. Die Bereitstellung der Images über Docker Hub erleichtert zudem die Integration in bestehende CI/CD-Pipelines, da die Infrastruktur bereits auf gängige Container-Registries ausgelegt ist.

Offene Fragen und technologische Lücken

Obwohl BellSoft mit dem neuen Builder eine robuste Lösung präsentiert, bleiben einige Aspekte im Quelltext unbeantwortet. So wird beispielsweise nicht detailliert erläutert, wie sich die Integration in hochspezialisierte CI/CD-Pipelines gestaltet, die über Standard-Build-Prozesse hinausgehen. Auch die Frage, wie genau die Performance-Auswirkungen bei sehr großen, monolithischen Anwendungen aussehen, die auf das neue, schlanke Alpaquita-Linux migriert werden, wird nicht explizit adressiert. Ebenso bleibt offen, wie die langfristige Unterstützung für Nischen-Sprachen aussieht, die nicht explizit in der aktuellen Liste der unterstützten Technologien aufgeführt sind. Es ist zudem unklar, inwieweit die Automatisierung bei sehr komplexen Abhängigkeitsbäumen, die über die Standard-Buildpacks hinausgehen, an ihre Grenzen stößt. Diese Lücken zeigen, dass trotz der hohen Automatisierung eine individuelle Prüfung durch die jeweiligen Architektur-Teams weiterhin notwendig bleibt, um die volle Funktionalität in der spezifischen Unternehmensumgebung zu gewährleisten.

Ausblick auf die Weiterentwicklung der Container-Sicherheit

Die Entwicklung bei BellSoft fügt sich in einen größeren Trend ein, bei dem die Sicherheit von Container-Images zunehmend durch spezialisierte Anbieter und automatisierte Prozesse gewährleistet wird. Mit dem Fokus auf die CLC-Konferenz 2026, die sich mit Themen wie Agentic AI und digitaler Souveränität befasst, wird deutlich, dass die Branche stark in Richtung einer stärkeren Automatisierung und Absicherung der Software-Lieferkette steuert. Die Verfügbarkeit von gehärteten, CVE-freien Basis-Images ist dabei ein entscheidender Baustein. Zukünftige Schritte werden vermutlich darin bestehen, die Integration von SBOMs noch tiefer in die Sicherheits-Dashboards der Unternehmen zu verankern und die Reaktionszeiten auf neue Schwachstellen durch noch engere Kopplungen zwischen Security-Scannern und Build-Systemen weiter zu verkürzen. Für Unternehmen bedeutet dies, dass die Wartung von Containern in Zukunft weniger manuelle Eingriffe erfordert, während gleichzeitig das Sicherheitsniveau durch standardisierte, gehärtete Komponenten auf einem konstant hohen Niveau gehalten werden kann.