Die besten Werkzeuge zur Bildhärtung im Jahr 2026

Standard- container -Image-Vorlagen sind mit unnötiger Software überladen, was die Angriffsfläche vergrößert und potenziell zu CVEs und Sicherheitslücken führen kann. Forscher, die 7.380 Debian-basierte Docker-Images untersuchten, stellten fest, dass kein einziges frei von bekannten Sicherheitslücken war. Unter „Image Hardening“ versteht man den Prozess, bei dem container -Images auf kleinere, sichere Versionen reduziert werden, um Angriffspunkte für Angreifer zu verringern und gesetzliche Standards zu erfüllen.

Die Image-Härtung hat sich jedoch weiterentwickelt und kann im Jahr 2026 unterschiedliche Bedeutungen haben. Einige Tools erstellen CVE-freie Images auf der Grundlage ihrer eigenen Distributionen neu. Das bedeutet jedoch, dass Sie jeden Dienst auf deren Basis migrieren und erneut auf Fehler prüfen müssen, und dass Sie an die Distribution und den Release-Rhythmus dieses Anbieters gebunden sind. Ein anderer Ansatz besteht darin, das bereits von Ihnen verwendete Image zu patchen, sodass Sie bei derselben Distribution und Hauptversion bleiben und die Migration vermeiden können.

In diesem Beitrag werden die führenden Tools zur Bildhärtung im Jahr 2026 hinsichtlich ihrer jeweiligen Funktionsweise, der Migrations- und Kompatibilitätsrisiken, der Geschwindigkeit der Fehlerbehebung sowie ihrer Einbindung in Ihren übrigen Sicherheits-Workflow verglichen. Wir vergleichen:

• Aikido Security
• Chainguard
• Docker Hardened Images
• Rapidfort
• Echo
• Minimus
• Wiz

TL;DR

Aikido Sicherheit steht bei uns an erster Stelle. Anstatt Sie zu zwingen, auf eine neue Distribution umzusteigen, werden Patches auf das Basis-Image angewendet, das Sie bereits nutzen – so entfallen Migration und grundlegende Änderungen. Die Patches werden über einen „Autofix“-Pull-Request angewendet, den Sie einmalig prüfen und zusammenführen. Danach erstellt Aikido das Image immer wieder neu, sobald neue Sicherheitslücken behoben werden, und benachrichtigt Sie, sobald ein neuer Build verfügbar ist. Aikido patcht Versionen auch noch nach Ablauf ihrer Lebensdauer weiter, sodass Sie auf einer älteren Basis bleiben können, ohne deren bekannte kritische und hochriskante CVEs mit sich zu tragen. Aikido Intel erweitert die Abdeckung über die öffentlichen Datenbanken hinaus und kennzeichnet Schwachstellen, die upstream stillschweigend gepatcht, aber nie mit einer CVE versehen wurden. Jedes Image ist ein direkter Ersatz mit einer Herkunftsangabe gemäß „ SBOM “, VEX und SLSA, der CVEs auf Betriebssystemebene im Rahmen eines definierten SLA für die Patch-Erstellung abdeckt – alles Teil einer Plattform, die auch SAST, DAST, SCA, die Erkennung von „ secrets “ sowie die Cloud-Sicherheitslage abdeckt.

{{cta}}

Was versteht man unter „ container -Image-Hardening“?

Ein Basis-Image von „ container “ bildet die grundlegende Ausgangsebene für ein „ container “. Ein öffentliches Standard-Image enthält in der Regel Paketmanager, Shells, Compiler und Debugging-Tools, damit es für alle Nutzer funktioniert, doch Ihre App benötigt den Großteil davon wahrscheinlich nicht. 

Unter „Hardening“ versteht man das Entfernen von Software, die von der Workload nie genutzt wird (wodurch ganze Kategorien von Schwachstellen zusammen mit den entsprechenden Paketen beseitigt werden), sowie die Absicherung der verbleibenden Komponenten durch gepatchte Versionen, sichere Standardeinstellungen, Ausführung ohne Root-Rechte und eine an CIS/STIG angepasste Konfiguration.

Das Ergebnis ist ein kleineres, saubereres Image, das von Anfang an sicher ist und dies auch bleibt, wenn Schwachstellen in den vorgelagerten Komponenten entdeckt und behoben werden. Abgehärtete Images generieren zudem Prüfnachweise wie signierte SBOMs, Build-Herkunftsnachweise, VEX-Erklärungen und Signaturen der „ compliance “.

Häufige Einschränkungen von Tools zur Bildhärtung

Bei den meisten Tools zur Bildhärtung müssen Sie die derzeit verwendete Basisversion aufgeben und deren Katalog übernehmen; anschließend sind Sie so lange an deren Aktualisierungsrhythmus gebunden, wie Sie das Tool nutzen. Dieses Konzept ist mit Kosten verbunden. Die Umstellung bedeutet eine Migration, und alles, was der Anbieter entfernt hat, worauf sich Ihre Anwendung stillschweigend verlassen hat, kann zu Fehlern führen. Um auf dem neuesten Stand zu bleiben, muss man auf jeden neuen Digest aktualisieren, sodass jeder Fix ein neues Image bedeutet, das getestet und im Rahmen der Änderungskontrolle erneut genehmigt werden muss. Wenn man einen Digest aus Stabilitätsgründen festlegt, hält man genau jene Patches zurück, für deren Einbindung man das Tool ursprünglich eingeführt hat. 

Auch für gehärtete Images gelten generell einige Einschränkungen. Das Entfernen von Paketen, die eine Workload niemals nutzt, beseitigt zwar die Schwachstellen, doch ein CVE in einem Paket, das Sie tatsächlich benötigen, erfordert nach wie vor einen echten Patch zur Behebung. Und jeder Neuaufbau kann das Verhalten verändern, auf das Ihr Build angewiesen war – weshalb ein Wechsel des Images immer eine Testrunde nach sich zieht.

Die Alternative besteht darin, die bereits von Ihnen genutzte Basis zu patchen, wobei Ihre Distribution und die Hauptversion unverändert bleiben und die Open-Source-Komponenten Ihrer Anwendung offen bleiben. Es gibt keinen Herstellerkatalog, auf den Sie migrieren müssten, und es ist keine Umstellung auf eine andere Plattform erforderlich. 

Worauf Sie bei einem Tool zur Bildhärtung achten sollten

Nicht jedes Tool, das „Image Hardening“ anbietet, erfüllt denselben Zweck. Bevor Sie eine Entscheidung treffen, sollten Sie auf folgende Aspekte achten.

• Ein umfangreicher Katalog mit vorgefertigten Images: Für wie viele der von Ihnen tatsächlich genutzten Basissysteme bietet er optimierte Versionen an? Achten Sie auf eine echte Breite über verschiedene Distributionen wie Debian, Ubuntu und Alpine hinweg, auf Unterstützung sowohl für amd64 als auch für arm64 sowie auf einen Katalog, der aktiv gepflegt wird.
• Nachweisbare Herkunft: Das bedeutet, dass jedem Pull ein signiertes „ SBOM “ (Software-Stückliste, die vollständige Auflistung aller im Image enthaltenen Komponenten), ein VEX-Dokument (Vulnerability Exploitability Exchange, das die CVEs erfasst, die für Sie keine Auswirkungen haben) sowie ein SLSA-Herkunftsnachweis (ein Standard, der bescheinigt, wie und wo das Image erstellt wurde) beigefügt sind. 
• Sicherheit nach Ablauf der Lebensdauer: Achten Sie auf Patches, die auch dann noch bereitgestellt werden, wenn die übergeordnete Distribution bereits weiterentwickelt wurde, damit Sie auf einer älteren Basis bleiben können, ohne die bekannten kritischen und hohen Sicherheitslücken in Kauf nehmen zu müssen.
• Informationen zur Behebung: Findet das Tool nur Schwachstellen, denen eine CVE-Nummer zugewiesen wurde? Da das NIST die NVD im Jahr 2026 auf ein risikobasiertes Modell umstellen wird, wird ein wachsender Anteil der tatsächlichen Schwachstellen keine zeitnahe CVE-Nummer erhalten, und manche werden gar keine bekommen. Jedes Tool, das ausschließlich auf öffentliche CVE-Feeds angewiesen ist, weist diese blinden Flecken auf. 
• Erfüllt die „ compliance “-Standards: Diese verlangen minimierte Bilder und eine dokumentierte Herkunft. Überprüfen Sie, ob das Tool diese Nachweise automatisch erstellt.

Die besten Werkzeuge zur Oberflächenhärtung 2026

Aikido Security

Aikido Images patcht das von Ihnen bereits verwendete Basis-Image, anstatt Sie zu einer Migration auf ein neues zu zwingen – das bedeutet: keine kompatibilitätsbrechenden Änderungen. Aikido Images ist ein Verzeichnis mit über 2.000 sofort einsatzbereiten Ersatz-Images, bei denen die bekannten CRITICAL-/HIGH-Schwachstellen im Basis-Image bereits behoben wurden. Diese Images werden während des Build-Vorgangs neu erstellt, gepatcht, minimiert und gehärtet, sodass Sie auf der Basis, die Sie bereits nutzen, den vollen Schutz, eine kleinere Angriffsfläche und streng gesicherte Standardeinstellungen erhalten.

Für Beispiel, debian:bookworm liefert eine gepatchte glib2.0 für CVE-2025-4373, das Debian in Trixie/Sid, jedoch nicht in Bookworm behoben hat. Die Variante „ Aikido -Images“ von debian:bookworm enthält eine gepatchte Version von glib2.0 das diese Sicherheitslücke behebt. 

Da es sich bei dem Swap um einen „Drop-in“ handelt, den AutoFix als Pull-Request vorschlägt, wird die Korrektur sofort beim Merge übernommen und nicht erst am Ende eines Test- und Migrationszyklus. Außerdem enthält jeder Pull von docker.aikido.io eine Herkunftsangabe mit SBOM, VEX und SLSA. Aikido sorgt auch dann noch für Patches, wenn der Upstream-Entwickler die Unterstützung eingestellt hat – selbst für Versionen, deren Lebensdauer abgelaufen ist. So können Sie auf einer älteren Basis bleiben, ohne deren bekannte Sicherheitslücken in Kauf nehmen zu müssen, und ohne zu einer neueren Version gedrängt zu werden, um weiterhin geschützt zu sein.

Aikido erstellt seine Images ebenfalls aus Standard-Open-Source-Software, also denselben Upstream-Paketen, die auch die Distribution liefert, während einige dieser Tools alles aus ihren eigenen Quellcodes oder einer proprietären Distribution neu kompilieren.

Ein wachsender Anteil echter Fehlerbehebungen erhält überhaupt keine CVE-Nummer. Die laufende Überwachung von Aikido wird zum Teil von Aikido Intel unterstützt, das die Changelogs und Commit-Verläufe der Upstream-Projekte auswertet, um Sicherheitslücken aufzuspüren, die stillschweigend und ohne CVE-Nummer behoben wurden. Und während die meisten dieser Tools eine CVE durch ein Upgrade des betroffenen Pakets auf eine neuere Version beheben, nutzt Aikido vor allem zurückportierte Patches: Dabei wird der Fix aus der neueren Version übernommen und auf die Version angewendet, die Sie bereits ausführen. Dadurch bleibt die Änderung gering, sodass das Image sich mit größerer Wahrscheinlichkeit so verhält, wie es Ihre Anwendung erwartet, und es entsteht weniger Upgrade-Schulden, die sich ansammeln, wenn Sie zu neuen Versionen gedrängt werden. 

Wenn ein sauberes Backport nicht möglich ist, führt „ Aikido “ stattdessen ein Upgrade oder einen Neuaufbau der Komponente durch. „ Aikido “ ordnet zudem jede „ container “ der Basis zu, von der sie abgeleitet ist, und zeigt Ihnen den Austausch auf, der das geringste Risiko für die gesamte Organisation mit sich bringt – mit täglich über 100 recherchierten und getesteten Patches sowie einer Abdeckung auf Betriebssystemebene im Rahmen eines definierten SLAs für die Patch-Erstellung.

Sicherheitslücken auf Anwendungsebene in Paketen verschiedener Ökosysteme wie npm, PyPI, Maven und Go werden direkt über „Aikido -Bibliotheken“ behoben. All dies ist Teil einer ausgereiften Software-Sicherheitsplattform, die zudem die Erkennung von SAST, DAST, SCA und secrets sowie die Cloud-Sicherheitslage und das Scannen von Images unter container abdeckt, sodass bei der Identifizierung eines Images der zugehörige Code und der Cloud-Kontext angezeigt werden.

Das Team hinter diesen Images kam durch die Übernahme von Root hinzu, dem Unternehmen hinter SlimToolkit (ehemals DockerSlim), einem der am häufigsten genutzten Open-Source-Tools zur Image-Absicherung mit über 23.000 GitHub-Stars und der nachgewiesenen Fähigkeit, Images um das bis zu 30-Fache zu verkleinern. Mit der Erstellung und Absicherung von Images unter Container hat dieses Team seine Arbeit begonnen, und das Tool ist nach wie vor kostenlos und für jedermann frei zugänglich.

‍Am besten geeignet für: Unternehmensteams, die kritische und hochgradige Sicherheitslücken aus den von ihnen bereits verwendeten Basis-Images und Abhängigkeiten beseitigen möchten, ohne auf eine neue Distribution umzusteigen oder ein rollierendes Upgrade durchzuführen.

{{walkthrough}}

Chainguard

Chainguard zerlegt ein Image und baut es auf Basis von „Wolfi“, seiner eigenen Linux-Distribution, neu auf. Die gehärteten Images werden mit SBOMs und Sigstore-Signaturen ausgeliefert, werden aus dem Upstream-Code neu erstellt und verfügen über ein veröffentlichtes SLA zur Behebung von Sicherheitslücken von 7 Tagen für kritische CVEs und 14 Tagen für alle anderen. Chainguard bietet Lösungen für den Bundesbereich compliance an, mit FIPS-validierten Varianten, NIST-validierten kryptografischen Modulen und DISA-STIG-Härtung.

Die Kosten bestehen in der Migration und der Bindung an das System. Die Umstellung auf „ Chainguard “ bedeutet, dass Sie Ihre Dienste auf dessen Katalog und die „Wolfi“-Distribution verlagern müssen. Wenn Ihre Anwendung jedoch von einer Komponente abhängt, die „ Chainguard “ entfernt hat, funktioniert sie nicht mehr. Das Modell zwingt Sie zudem zu fortlaufenden Upgrades, sodass jeder Patch ein neues Image bedeutet, das erneut getestet werden muss. Die Fixierung auf einen Digest zur Gewährleistung der Reproduzierbarkeit verhindert, dass die Patches Sie überhaupt erreichen – was den Grund für die Umstellung zunichte macht. 

Chainguard Außerdem werden ältere Versionen relativ schnell ausgemustert. Nicht aktuelle Paketversionen werden etwa 12 Monate lang beibehalten, und die End-of-Life-Unterstützung ist auf sechs Monate begrenzt – und zwar nur für die Abhängigkeitspakete, die einem Image zugrunde liegen, nicht für die Hauptkomponente. Dies führt zu einem stetigen Druck, auf neuere Versionen umzusteigen, was für Teams, die eine Version lieber beibehalten würden, eine ständige Umstellung bedeutet.

Am besten geeignet für: Teams, die sich auf den Verteilungs- und Release-Rhythmus eines einzelnen Anbieters festlegen können. Nicht geeignet für Teams, die ihre Basis-Images und -Versionen beibehalten oder eine Version ohne ständige erneute Tests stabil halten müssen.

Docker Hardened Images

Der Katalog mit gehärteten Images von Docker wurde im Mai 2025 eingeführt und ist seit Dezember 2025 unter der Apache-2.0-Lizenz kostenlos und als Open Source verfügbar. DHI ist für Teams, die bereits Docker Hub nutzen, eine Überlegung wert. Das Ziel ist es, Basis-Images mit nahezu null CVEs bereitzustellen, die auf den Standard-Grundlagen von Alpine und Debian aufbauen und mit signierten SBOMs, einer Herkunftsnachweis nach SLSA Build Level 3 sowie VEX-Bescheinigungen ausgeliefert werden. DHI Select bietet zusätzlich eine 7-Tage-SLA für kritische CVEs sowie FIPS- und STIG-Varianten. DHI Enterprise ermöglicht weitere Anpassungen, wobei ELS als kostenpflichtiges Add-on für bis zu fünf Jahre nach Ablauf der Upstream-Supportdauer verfügbar ist.

DHI ist ein relativ neuer Anbieter, weshalb die Erfolgsbilanz bei stark regulierten Arbeitslasten noch nicht so umfangreich ist. Das Angebot ist weniger umfangreich als das anderer Anbieter auf dieser Liste und erstreckt sich nicht über „ container “-Bilder hinaus.

Am besten geeignet für: Teams, die lieber gehärtete Images in ihren bestehenden Docker-Workflow integrieren möchten, jedoch nicht für Teams, deren Basis-Images außerhalb des Docker-Katalogs liegen, der nach wie vor weniger umfangreich ist als der anderer hier vorgestellter Tools.

Rapidfort

RapidFort bietet einen Katalog mit gehärteten Images, die auf Standard-LTS-Distributionen wie Alpine, Debian, Ubuntu und Red Hat basieren und nicht auf einer proprietären „ container “-Distribution. Das Angebot ist stark auf Anwendungsfälle im Bundes- und Verteidigungsbereich ausgerichtet, darunter FedRAMP, FISMA und CMMC. 

Über den Katalog hinaus bietet RapidFort Laufzeit-Profiling an, um Images weiter zu verkleinern. Der Profiler beobachtet, welche Pakete und Binärdateien in der Produktion tatsächlich ausgeführt werden, erstellt eine Runtime Bill of Materials (RBOM) und entfernt alles, was nicht ausgeführt wurde. Damit lässt sich ein Image verkleinern, doch die Technik ist anfällig, da der Profiler nur das beibehält, was er beobachtet – alles, was während des Profiling nicht genutzt wurde, kommt für eine Entfernung in Frage. Jede neue Funktion, Abhängigkeit oder Konfigurationsänderung erfordert eine erneute Profilierung und erneute Tests, bevor das Image ausgeliefert wird.

Am besten geeignet für: Auftragnehmer der US-Bundesregierung , Verteidigungszulieferer und regulierte Teams, die sich bereits an FIPS und STIG halten compliance; Teams, die eine tiefgreifendere Optimierung durch Laufzeit-Profiling anstreben, sollten jedoch wissen, dass diese Methode anfällig ist und bei jeder Änderung der Anwendung ein neues Profiling erfordert.

Echo

Echo ist ein relativ neuer Anbieter, dessen Alleinstellungsmerkmal eine KI-gesteuerte „Image-Fabrik“ ist, die „ container “-Images aus Quellcode erstellt und dabei ausschließlich die Komponenten einbezieht, die eine Anwendung tatsächlich benötigt. Die Agenten des Unternehmens überwachen Feeds zu Sicherheitslücken und generieren neue Images, sobald neue CVEs im Upstream-Bereich bekannt werden. Die daraus resultierenden Images zielen auf null CVEs ab und werden als direkte Ersatzlösungen für Standard-Docker-Basis-Images bereitgestellt. Die Images sind FIPS-validiert und STIG-konform für Teams, die dies benötigen, und Echo positioniert sich als direkte Alternative zu „ Chainguard “ und „Docker Hardened Images“ im Bereich der neu erstellten Basis-Images. 

Am wenigsten bewährt hat sich Echo hinsichtlich der operativen Erfolgsbilanz der KI-gesteuerten Pipeline für den Wiederaufbau und das Patchen unter regulierten Arbeitslasten im Produktionsmaßstab. 

Am besten geeignet für: Teams, die eine neu ausgerichtete Strategie für Basis-Images verfolgen möchten. Allerdings müssen diese Teams bereit sein, einen Anbieter der Serie A mit einem kleineren Produktportfolio und einer kürzeren Unternehmensgeschichte zu bewerten.

Minimus

Minimus wurde im Oktober 2022 von den Mitbegründern ins Leben gerufen, die zuvor Twistlock aufgebaut hatten (das 2019 von Palo Alto Networks übernommen wurde). Das Produkt selbst wurde im April 2025 auf der RSAC der Öffentlichkeit vorgestellt, seine Erfolgsbilanz ist also noch recht jung. Minimus-Images werden aus dem Upstream-Quellcode erstellt und enthalten ausschließlich die Software, die zum Ausführen einer Anwendung erforderlich ist. Die Pipeline des Unternehmens überwacht Open-Source-Projekte, erstellt Pakete neu, sobald die Betreuer neue Versionen veröffentlichen, und stellt nach automatisierten Tests und der Signierung aktuelle Images bereit. Der veröffentlichte Katalog umfasst über 1.200 gehärtete Images, und das Unternehmen unterstützt die FIPS-, CIS-, NIST- und STIG- compliance -Baselines.

Die Einführung von Minimus bedeutet, dass Sie Ihre Dienste auf dessen Images umstellen. Da das Modell aus dem Upstream neu erstellt wird und neue Releases bereitstellt, anstatt Korrekturen in die von Ihnen festgelegte Version zurückzuportieren, müssen Sie auf jeden neuen Digest aktualisieren, um auf dem neuesten Stand zu bleiben. Jeder Fix ist ein neues Image, das getestet und freigegeben werden muss, und das Fixieren auf eine bestimmte Version aus Stabilitätsgründen hält die Patches zurück. Die Erfolgsbilanz ist zudem noch kurz, da das Produkt erst seit April 2025 öffentlich verfügbar ist, und wie die anderen hier genannten Lösungen beschränkt es sich auf das Basis-Image und erstreckt sich nicht auf den Rest Ihres Stacks.

Am besten geeignet für: Teams , die aus dem Quellcode erstellte Images wünschen und eine Pipeline für die Neuerstellung und erneute Bereitstellung betreiben können, die mit neuen Digests Schritt hält. Nicht jedoch für Teams, die eine bestimmte Version festhalten müssen und dennoch Sicherheitskorrekturen erhalten möchten, ohne bei jedem Patch ein Rollforward und erneute Tests durchführen zu müssen.

Wiz

Wiz WizOS sorgt für zusätzliche Sicherheit durch seinen eigenen Katalog minimalistischer Basis-Images, die aus dem Quellcode erstellt und auf eine sehr geringe Anzahl bekannter CVEs beschränkt werden. Sie werden mit SBOMs und nachverfolgbarer Herkunft ausgeliefert und verfügen über ein SLA zur Behebung von Sicherheitslücken von 7 Tagen für kritische sowie 14 Tagen für hohe und mittlere Schweregrade. Für regulierte Workloads stehen FIPS- und STIG-abgehärtete Varianten zur Verfügung. WizOS ist in die Plattform „ Wiz “ (Cloud-Sicherheit ) integriert, sodass ein anfälliges Basis-Image zusammen mit den zugehörigen Cloud-, Code- und Laufzeit-Signalen angezeigt wird – einschließlich Empfehlungen zum Wechsel zu einem entsprechenden WizOS-Äquivalent, der Durchsetzung durch den Admission-Controller sowie Ein-Klick-Upgrades in der IDE.

Die Kompromisse liegen im Umfang und im Modell. Ähnlich wie bei Chainguard zwingt WizOS Sie dazu, Dienste auf die Images von Wiz zu migrieren, anstatt Korrekturen in die von Ihnen bereits verwendete Version zurückzuportieren. Daher ist jede Korrektur ein neues Image, das getestet und freigegeben werden muss. Der Katalog ist zudem neuer und enger gefasst als der der Spezialisten, da er mit Go-spezifischen Images begann und sich von dort aus erweitert hat. Daher ist ein gehärtetes Äquivalent für genau Ihre Basis nicht garantiert. 

Am besten geeignet für: Teams, die bereits Wiz nutzen und „ gehärtete Basis-Images “ innerhalb derselben Plattform, die sie für Cloud- und Laufzeit-Sicherheit verwenden, anzeigen und durchsetzen möchten. Nicht geeignet für Teams, deren Basis außerhalb des noch wachsenden Katalogs von WizOS liegt.