Die besten Image-Hardening-Tools im Jahr 2026

Standardmäßige Container-Image-Vorlagen sind mit ungenutzter Software überladen, was die Angriffsfläche vergrößert und potenziell CVEs und Schwachstellen mit sich bringt. Forscher, die 7.380 Debian-basierte Docker-Images untersuchten, fanden kein einziges, das frei von bekannten Schwachstellen war. Image Hardening ist der Prozess, bei dem Container-Images auf kleinere, sichere Versionen reduziert werden, um Einstiegspunkte für Angreifer zu minimieren und regulatorische Standards zu erfüllen.

Aber Image Hardening hat sich weiterentwickelt und kann im Jahr 2026 unterschiedliche Dinge bedeuten. Einige Tools erstellen CVE-freie Images auf ihren eigenen Distributionen neu. Das bedeutet jedoch, dass Sie jeden Service auf deren Basis migrieren und erneut auf Fehler testen müssen, und Sie sind an die Distribution und den Release-Zyklus dieses Anbieters gebunden. Ein anderer Ansatz besteht darin, das bereits verwendete Image zu patchen, sodass Sie auf derselben Distro und Hauptversion bleiben und die Migration vermeiden.

Dieser Beitrag vergleicht die Top-Tools für Image Hardening im Jahr 2026 hinsichtlich ihrer Härtungsmethode, des Migrations- und Breaking-Change-Risikos, der Behebungsgeschwindigkeit und der Integration in Ihren restlichen Security-Workflow. Wir vergleichen:

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

TL;DR

Aikido Security ist unsere Top-Empfehlung. Anstatt Sie zu zwingen, auf eine neue Distribution zu wechseln, patcht das Tool das Basis-Image, das Sie bereits verwenden – ganz ohne Migration und ohne Breaking Changes. Patches werden über einen Autowhatever-Pull-Request eingespielt, den Sie prüfen und mit einem Klick mergen. Danach baut Aikido das Image kontinuierlich neu auf, sobald neue Schwachstellen gepatcht werden, und benachrichtigt Sie, wenn ein neuerer Build verfügbar ist. Aikido patcht Versionen auch nach deren End-of-Life weiter, sodass Sie auf einer älteren Basis bleiben können, ohne deren bekannte kritische und hohe CVEs in Kauf nehmen zu müssen. Aikido Intel erweitert die Abdeckung über die öffentlichen Datenbanken hinaus und markiert Schwachstellen, die upstream still und leise gepatcht, aber nie mit einer CVE versehen wurden. Jedes Image ist ein Drop-in-Ersatz mit SBOM, VEX und SLSA-Herkunft und deckt OS-Ebene-CVEs im Rahmen einer definierten Patch-Erstellungs-SLA ab – alles Teil einer Plattform, die zudem SAST, DAST, SCA, Secrets detection und Cloud-Posture abdeckt.

{{cta}}

Was ist Container-Image-Hardening?

Ein Container-Base-Image ist die grundlegende Startschicht für einen Container. Ein standardmäßiges öffentliches Image enthält in der Regel Paketmanager, Shells, Compiler und Debugging-Tools, damit es universell einsetzbar ist – Ihre Anwendung benötigt davon jedoch wahrscheinlich das Meiste nicht. 

Hardening bedeutet, Software zu entfernen, die die Workload niemals verwendet (wodurch ganze Klassen von Schwachstellen zusammen mit den Paketen gelöscht werden) und den verbleibenden Rest durch gepatchte Versionen, sichere Standardeinstellungen, Ausführung ohne Root-Rechte und CIS/STIG-konforme Konfigurationen abzusichern.

Das Resultat ist ein kleineres, schlankeres Image, das sicher startet und auch so bleibt, während Upstream-Schwundstellen (Vulnerabilities) gefunden und gepatcht werden. Gehärtete Images liefern zudem Nachweise für die Compliance wie signierte SBOMs, Build-Provenienz, VEX-Erklärungen und Compliance-Signaturen.

Häufige Einschränkungen von Tools zum Härten von Images

Die meisten Tools zum Härten von Images zwingen Sie dazu, Ihre bisherige Basis zu verlassen, deren Katalog zu nutzen und sich so lange an deren Rebuild-Takt zu binden, wie Sie das Tool verwenden. Das hat seinen Preis: Die Einführung bedeutet eine Migration, und alles, was der Anbieter entfernt hat und worauf Ihre App stillschweigend angewiesen war, kann kaputtgehen. Um gepatcht zu bleiben, müssen Sie jedes neue Digest einspielen – das bedeutet, dass jeder Fix ein neues Image darstellt, das getestet und im Rahmen der Änderungskontrolle (Change Control) neu freigegeben werden muss. Wenn Sie ein Digest für mehr Stabilität fixieren, halten Sie genau die Patches zurück, wegen denen Sie das Tool überhaupt erst eingeführt haben. 

Für gehärtete Images im Allgemeinen gelten ebenfalls einige Einschränkungen. Das Entfernen von Paketen, die eine Workload niemals nutzt, beseitigt zwar die Schwachstellen, aber ein CVE in einem Paket, das Sie tatsächlich benötigen, erfordert nach wie vor einen echten Patch. Zudem kann jeder Rebuild das Verhalten verändern, von dem Ihr Build abhing, weshalb ein Image-Wechsel immer umfangreiche Tests nach sich zieht.

Die Alternative besteht darin, die bereits verwendete Basis zu patchen. Dabei bleiben Ihre Distribution und Hauptversion (Major Version) erhalten und der Open-Source-Code unterhalb Ihrer Anwendung unberührt. Es muss weder zu einem Anbieterkatalog migriert noch ein Re-Plattforming durchgeführt werden. 

Worauf Sie bei einem Tool zum Härten von Images achten sollten

Nicht jedes Tool, das „Image-Härtung“ anbietet, leistet dasselbe. Bevor Sie eine Entscheidung treffen, sollten Sie auf folgende Punkte achten.

• Ein großer, fertiger Katalog: Für wie viele der von Ihnen tatsächlich genutzten Basen bietet das Tool gehärtete Versionen an? Achten Sie auf echte Vielfalt bei Distributionen wie Debian, Ubuntu und Alpine, Unterstützung für sowohl amd64 als arm64 sowie einen aktiv gepflegten Katalog.
• Verifizierbare Provenienz: Dies umfasst eine signierte SBOM (Software-Stückliste, die vollständige Inventarliste der Inhalte des Images), ein VEX-Dokument (Vulnerability Exploitability Exchange, das CVEs dokumentiert, die Sie tatsächlich nicht betreffen) sowie SLSA-Provenienz (ein Standard, der besagt, wie und wo das Image erstellt wurde), die jedem Pull beigefügt sind. 
• Sicherheit über das End-of-Life hinaus: Achten Sie auf fortlaufende Patches, auch nachdem die Upstream-Distribution bereits abgelöst wurde. So können Sie auf einer älteren Basis bleiben, ohne deren bekannte kritische und hohe Schwachstellen in Kauf nehmen zu müssen.
• Remediation Intelligence: Findet das Tool nur Schwachstellen, denen eine CVE zugewiesen wurde? Da das NIST seine NVD im Jahr 2026 auf ein risikobasiertes Modell umstellt, wird ein wachsender Teil realer Schwachstellen keine zeitnahe CVE erhalten – einige sogar überhaupt keine. Jedes Tool, das starr mit öffentlichen CVE-Feeds verbunden ist, erbt diese blinden Flecken. 
• Erfüllt Compliance-Standards: Diese setzen minimierte Images und dokumentierte Provenienz voraus. Überprüfen Sie, ob das Tool diese Nachweise automatisch generiert.

Top-Tools für das Härten von Images 2026

Aikido Security

Aikido Images patcht das Basis-Image, das Sie bereits verwenden, anstatt Sie zur Migration auf ein neues zu zwingen – das bedeutet keine Breaking Changes. Aikido Images ist eine Registry mit über 2.000 Drop-in-Ersatz-Images, bei denen die bekannten KRITISCHEN/HOHEN Schwachstellen in der Basis bereits gepatcht wurden. Diese Images werden während des Builds neu erstellt, gepatcht, minimiert und gehärtet. Sie erhalten somit die volle Behandlung, eine kleinere Angriffsfläche und abgesicherte Standardwerte auf der Basis, die Sie ohnehin bereits betreiben.

Für Beispiel, debian:bookworm liefert einen gepatchten glib2.0 für CVE-2025-4373, den Debian in Trixie/Sid, aber nicht in Bookworm behoben hat. Die Aikido Images-Variante von debian:bookworm enthält eine gepatchte Version von glib2.0 , die diese Schwachstelle behebt. 

Da es sich bei dem Tausch um ein Drop-in handelt, das AutoFix als Pull Request vorschlägt, greift der Fix ab dem Moment des Mergens – ganz ohne langwierige Test- und Migrationszyklen. Zudem kommt jeder Pull von docker.aikido.io mit einer SBOM, VEX und SLSA-Provenienz. Aikido patcht Versionen auch dann weiter, wenn der Upstream-Anbieter den Support bereits eingestellt hat (selbst nach dem End-of-Life). So können Sie auf einer älteren Basis bleiben, ohne deren bekannte Sicherheitslücken mitzuschleppen oder zu einer neueren Version gedrängt zu werden, um geschützt zu bleiben.

Aikido baut seine Images zudem auf Basis von Standard-Open-Source auf – denselben Upstream-Paketen, die auch von der Distribution ausgeliefert werden –, während viele andere Tools alles komplett aus eigener Quelle oder einer proprietären Distribution neu erstellen.

Ein wachsender Anteil echter Fixes erhält überhaupt keine CVE. Aikido unterstützt sein fortlaufendes Monitoring unter anderem durch Aikido Intel, das Upstream-Changelogs und Commit-Historien auswertet, um Schwachstellen aufzuspüren, die unbemerkt und ohne CVE gepatcht wurden. Und während die meisten dieser Tools eine CVE durch ein Upgrade des betroffenen Pakets auf eine neuere Version beheben, setzt Aikido verstärkt auf Backported Patches: Der Fix aus der neueren Version wird dabei auf die von Ihnen bereits verwendete Version angewendet. Das hält die Änderung gering, sodass sich das Image voraussichtlich so verhält, wie es Ihre App erwartet – und es entsteht weniger Upgrade-Schuld, die sich sonst bei einem erzwungenen Wechsel auf neuere Versionen anhäuft. 

Wenn ein sauberer Backport nicht möglich ist, aktualisiert oder baut Aikido stattdessen die Komponente neu. Aikido ordnet außerdem jeden Container der jeweiligen Basis zu und zeigt Ihnen direkt den Tausch an, der unternehmensweit das meiste Risiko beseitigt. Täglich werden über 100 Patches erforscht und getestet, und die Abdeckung auf Betriebssystemebene erfolgt im Rahmen einer definierten Patch-Creation-SLA.

Paketvollzugriff auf Anwendungsebene über Ökosysteme wie npm, PyPI, Maven und Go wird direkt vor Ort durch Aikido Libraries gepatcht. Das Ganze ist eingebettet in eine ausgereifte Software-Security-Plattform, die auch SAST, DAST, SCA, Secrets detection, Cloud-Sicherheitsstatus und Container-Image-Scan abdeckt, sodass ein gefundenes Image direkt im Kontext von Code und Cloud angezeigt wird.

Das Team hinter diesen Images stieß im Zuge der Übernahme von Root zu Aikido – dem Unternehmen hinter SlimToolkit (früher DockerSlim), einem der am häufigsten genutzten Open-Source-Tools zur Image-Härtung mit über 23.000 GitHub-Sternen und der nachgewiesenen Fähigkeit, Images um das bis zu 30-Fache zu verkleinern. Das Erstellen und Härten von Container-Images war der Ursprung dieses Teams, und das Tool ist nach wie vor für jedermann frei und als Open Source nutzbar.

‍Am besten geeignet für: Enterprise-Teams, die kritische und hohe Schwachstellen in den von ihnen bereits verwendeten Basis-Images und Abhängigkeiten beheben möchten, ohne auf eine neue Distribution zu migrieren oder einem rollierenden Upgrade hinterherzulaufen.

{{walkthrough}}

Chainguard

Chainguard reduziert ein Image auf das Wesentliche und baut es aus Wolfi, seiner eigenen Linux-Distribution, neu auf. Die gehärteten Images werden mit SBOMs und Sigstore-Signaturen ausgeliefert, von Upstream aus neu aufgebaut und beinhalten ein veröffentlichtes Remediation-SLA von 7 Tagen für kritische CVEs und 14 Tagen für alle übrigen. Chainguard bietet Angebote für die föderale Compliance mit FIPS-validierten Varianten, NIST-validierten kryptografischen Modulen und DISA-STIG-Härtung.

Die Kosten bestehen aus Migration und Lock-in. Die Einführung von Chainguard bedeutet, dass Sie Ihre Dienste auf dessen Katalog und die Wolfi-Distribution umziehen müssen; wenn Ihre Anwendung von etwas abhängt, das Chainguard entfernt hat, führt dies zu Fehlern. Das Modell hält Sie zudem auf einem rollierenden Upgrade, sodass jeder Patch ein neues Image darstellt, das erneut getestet werden muss. Das Festlegen auf einen Digest für die Reproduzierbarkeit verhindert jedoch, dass die Patches Sie überhaupt erreichen, was den Grund für die Einführung zunichte macht. 

Chainguard lässt ältere Versionen zudem recht schnell auslaufen. Nicht-neueste Paketversionen werden für etwa 12 Monate vorgehalten, und die End-of-Life-Abdeckung ist auf sechs Monate beschränkt – zudem nur für die Abhängigkeitspakete unterhalb eines Images und nicht für die primäre Komponente. Dies erzeugt einen ständigen Druck, auf neuere Versionen zu wechseln, was für Teams, die eine Version lieber stabil halten würden, zusätzlichen Aufwand bedeutet.

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

Docker Hardened Images

Der Katalog gehärteter Images von Docker wurde im Mai 2025 eingeführt und im Dezember 2025 unter Apache 2.0 kostenlos sowie Open Source veröffentlicht. DHI ist für Teams einen Blick wert, die bereits Docker Hub nutzen. Ziel sind Basis-Images mit nahezu null CVEs, die auf Standard-Fundamenten von Alpine und Debian basieren, und die Auslieferung erfolgt mit signierten SBOMs, SLSA-Build-Level-3-Provenienz und VEX-Attestierungen. DHI Select fügt ein 7-Tage-SLA für kritische CVEs sowie FIPS- und STIG-Varianten hinzu. DHI Enterprise erweitert dies um Anpassungsmöglichkeiten, wobei ELS als kostenpflichtiges Add-on für bis zu fünf Jahre nach dem Upstream-End-of-Life verfügbar ist.

DHI ist ein jüngerer Marktteilnehmer, daher ist die Erfolgsbilanz bei stark regulierten Workloads kürzer. Der Katalog ist weniger tief als bei anderen Einträgen auf dieser Liste und erstreckt sich nicht über Container-Images hinaus.

Am besten geeignet für: Teams, die gehärtete Images lieber 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 kleiner ist als bei anderen Tools hier.

Rapidfort

RapidFort bietet einen Katalog gehärteter Images, die auf Standard-LTS-Distributionen wie Alpine, Debian, Ubuntu und Red Hat basieren, anstatt auf einer proprietären Container-Distro. Das Angebot ist stark auf Bundes- und Verteidigungsworkloads ausgerichtet, einschließlich FedRAMP, FISMA und CMMC. 

Über den Katalog hinaus bietet RapidFort Laufzeit-Profiling, um Images weiter zu optimieren. Der Profiler beobachtet, welche Pakete und Binärdateien in der Produktion tatsächlich ausgeführt werden, generiert eine Runtime Bill of Materials (RBOM) und entfernt alles, dessen Ausführung nicht beobachtet wurde. Zwar kann dies ein Image verkleinern, aber die Technik ist anfällig, da der Profiler nur das behält, was er beobachtet – alles, was während des Profilings nicht verwendet wird, wird entfernt. Jedes neue Feature, jede neue Abhängigkeit oder Konfigurationsänderung erfordert ein erneutes Profiling und Testen vor dem Release.

Am besten geeignet für: Bundesbehörden-Auftragnehmer, Verteidigungszulieferer und regulierte Teams, die sich bereits der FIPS- und STIG-Compliance verschrieben haben. Teams, die auf die tiefere Laufzeit-Profiling-Optimierung zurückgreifen möchten, sollten jedoch wissen, dass diese anfällig ist und bei jeder Änderung der Anwendung ein neues Profiling erfordert.

Echo

Echo ist ein neuerer Anbieter, dessen Konzept eine KI-gestützte Image-Factory ist, die Container-Images aus Quellcode kompiliert und dabei nur die Komponenten enthält, die eine Anwendung tatsächlich benötigt. Seine Agenten überwachen Schwachstellen-Feeds und generieren Images neu, sobald neue CVEs Upstream eintreffen. Die resultierenden Images zielen auf null CVEs ab und werden als direkter Ersatz für Standard-Docker-Basis-Images ausgeliefert. Sie sind FIPS-validiert und STIG-konform für Teams, die dies benötigen, und positionieren sich als direkte Alternative zu Chainguard und Docker Hardened Images im Bereich der neu aufgebauten Basis-Images. 

Am wenigsten bewährt hat sich bei Echo die operative Erfolgsbilanz der KI-gestützten Neuerstellungs- und Patching-Pipeline bei regulierten Workloads im Produktionsmaßstab. 

Am besten geeignet für: Teams, die eine Strategie mit neu aufgebauten Basis-Images wünschen. Teams müssen jedoch bereit sein, einen Serie-A-Anbieter mit einem kleineren Katalog und einer kürzeren operativen Historie zu evaluieren.

Minimus

Minimus wurde im Oktober 2022 von Mitgründern ins Leben gerufen, die zuvor Twistlock aufgebaut hatten (2019 von Palo Alto Networks übernommen). Das Produkt selbst wurde im April 2025 auf der RSAC öffentlich gestartet, sodass seine Erfolgsbilanz noch recht frisch ist. Minimus-Images werden aus dem Upstream-Quellcode mit nur der Software erstellt, die zum Ausführen einer Anwendung erforderlich ist. Ihre Pipeline überwacht Open-Source-Projekte, baut Pakete neu, wenn Betreuer neue Releases veröffentlichen, und stellt nach automatisierten Tests und Signaturen frische Images bereit. Ihr veröffentlichter Katalog umfasst über 1.200 gehärtete Images, und sie unterstützen Compliance-Baselines wie FIPS, CIS, NIST und STIG.

Die Einführung von Minimus bedeutet, dass Sie Ihre Dienste auf dessen Images umziehen müssen. Da das Modell jedoch von Upstream neu auf baut und neue Releases ausliefert, anstatt Fixes in die von Ihnen festgeschriebene Version zu backporten, bedeutet das Beibehalten des aktuellen Stands das Weiterschalten auf jeden neuen Digest. Jeder Fix stellt ein neues Image dar, das getestet und freigegeben werden muss, und das Festlegen auf Stabilität hält die Patches zurück. Auch die Erfolgsbilanz ist kurz, da das Produkt erst seit April 2025 öffentlich ist, und genau wie die anderen hier hört es beim Basis-Images auf und reicht nicht in den Rest Ihres Stacks hinein.

Am besten geeignet für: Teams, die aus Quellcode erstellte Images wünschen und eine Pipeline für Neuerstellung und erneute Bereitstellung betreiben können, die mit neuen Digests Schritt hält. Nicht geeignet für Teams, die eine Version festgeschrieben lassen und dennoch den Sicherheitsfix erhalten müssen, ohne bei jedem Patch ein Roll-Forward und einen Neutest durchzuführen.

Wiz

Wiz härtet über WizOS, seinen eigenen Katalog minimaler Basis-Images, die aus Quellcode erstellt, mit einer sehr geringen Anzahl bekannter CVEs gehalten, mit SBOMs und verifizierbarer Provenienz ausgeliefert werden und ein Remediation-SLA von 7 Tagen für kritische und 14 Tagen für hohe sowie mittlere Schwachstellen aufweisen. Für regulierte Workloads stehen FIPS- und STIG-gehärtete Varianten zur Verfügung. WizOS ist in die Wiz Cloud-Sicherheit-Plattform integriert, sodass ein anfälliges Basis-Image zusammen mit den umgebenden Cloud-, Code- und Laufzeitsignalen angezeigt wird – inklusive Empfehlungen für den Wechsel zu einem WizOS-Äquivalent, Durchsetzung per Admission Controller und Ein-Klick-Upgrades in der IDE.

Die Kompromisse betreffen den Umfang und das Modell. Ähnlich wie Chainguard zwingt WizOS Sie dazu, Dienste auf die Images von Wiz zu migrieren, anstatt Fixes in die von Ihnen bereits verwendete Version zu backporten, sodass jeder Fix ein neues Image zum Testen und Freigeben darstellt. Der Katalog ist zudem neuer und schmaler als der von Spezialisten, da er mit Go-fokussierten Images begann und von dort aus gewachsen ist, sodass ein gehärtetes Äquivalent für Ihre exakte Basis nicht garantiert ist. 

Am besten geeignet für: Teams, die bereits Wiz nutzen und möchten, dass gehärtete Basis-Images in derselben Plattform angezeigt und durchgesetzt werden, die sie auch für die Cloud- und Laufzeitsicherheit verwenden. Nicht geeignet für Teams, deren Basis-Images außerhalb des nach wie vor wachsenden Katalogs von WizOS liegen.