Connect with us

Entwicklung & Code

Docker Image Security – Teil 2: Minimale und sichere Docker Images


Viele Softwareentwicklungsteams verwenden Container-Images aus offiziellen Registries wie Docker Hub. Diese Images enthalten häufig viele Komponenten. Scanner wie Trivy oder Grype finden dann sehr viele CVEs (siehe Teil 1 dieser Serie), ob zu Recht (True Positives) oder als Fehlalarme (False Positives). Obgleich offizielle Images meist kostenlos sind, kann die Prüfung (Triage) aller gemeldeten CVE darin ein Kostentreiber sein – sofern das Team nicht riskieren will, auf die Suche tatsächlich ausnutzbarer CVEs zu verzichten.


Marius Shekow

Marius Shekow

Dr. Marius Shekow war über 10 Jahre als Forscher und Softwareentwickler bei Fraunhofer tätig. Seit 2022 ist er Lead DevOps- & Cloud-Engineer bei SprintEins in Bonn. Dort baut er für Konzerne und KMUs individuelle Cloud-Umgebungen, inkl. CI/CD-Automatisierung, Observability und Security-Absicherung.

Minimale Container-Images – auch als „distroless“, „gehärtete“ oder „chiseled“ bekannt – bieten eine Lösung für dieses Problem. Unter dem Motto „weniger Komponenten bedeuten weniger Schwachstellen“ verzichten sie auf alle Komponenten (etwa Shells oder Paketmanager), die zur Laufzeit normalerweise nicht gebraucht werden, um die Angriffsfläche zu reduzieren.

Anhand einer Gegenüberstellung der Vor- und Nachteile sowie einer Liste von kostenlosen und kostenpflichtigen minimalen Images für die Anwendungsfälle Basis-Linux, PHP, Python, Java, C#/.NET und Node.js, soll dieser Artikel DevOps-Teams bei der Auswahl geeigneter Container-Images helfen.

Minimale Images enthalten nur die absolut notwendigen Komponenten, um die eigentlichen Basis-Funktionen auszuführen (beim postgres-Image ist etwa der PostgreSQL-Server die Basis-Komponente). Ziel ist, die Angriffsfläche für Hacker so weit wie möglich zu reduzieren (siehe Abbildung 1) und Komponenten auszuschließen, etwa:

  • Distro-spezifische Paketmanager, z.B. apt für Debian/Ubuntu, apk für Alpine oder dnf/yum für Red Hat
  • Verschiedene Linux-Distro-spezifische Pakete, die normalerweise standardmäßig installiert, aber nicht erforderlich sind, um eine Anwendung auszuführen, z.B. Binärdateien und Bibliotheken für perl, grep oder gzip. Lässt man solche Komponenten weg, hat man ein „distroless“ Image ohne Färbung von Distro-Vorlieben.
  • Eine Shell (z.B. /bin/bash oder /bin/sh)
  • Debugging-Werkzeuge, beispielsweise curl zur Diagnose von Verbindungsproblemen

Während Slim Images (z.B. python:3.13-slim) in der Regel kleiner als die regulären Image-Varianten sind (z.B. python:3.13), enthalten sie dennoch eine Shell und einen Paketmanager und erleichtern es daher einem Angreifer, tiefer in ein System einzudringen!


Vergleich minimaler mit nicht-minimalen Images

Vergleich minimaler mit nicht-minimalen Images

Komponenten-Vergleich: minimale vs. nicht-minimale Images (Abb. 1)

Vor- und Nachteile von minimalen Images
Vorteile Nachteile
✅ Reduzierte Startdauer ❌ Schwieriger zu debuggen
✅ Weniger Sicherheitslücken und Triage-Arbeit ❌ Erhöhter Testaufwand
✅ Verbesserte Sicherheit ❌ Erhöhter Rechercheaufwand

Ein Blick auf die Details der in der Tabelle gegenübergestellten Vor- und Nachteile macht deutlich, warum minimale Images nicht zwangsläufig immer die beste Wahl sind.

Vorteile:

  • Reduzierte Startdauer: Minimale Images sind sehr klein und starten daher schneller, da das Herunterladen und Entpacken weniger Zeit benötigen.
  • Weniger Sicherheitslücken und Triage-Arbeit: Schwachstellenscanner wie Trivy oder Grype melden für minimale Images (im Durchschnitt) deutlich weniger Schwachstellen als für nicht-minimale Images. Daher kann das Team sich auf die Softwareentwicklung konzentrieren, anstatt potenzielle False-Positive-Funde der Scanner zu untersuchen (siehe Teil 1 dieser Serie).
  • Verbesserte Sicherheit: Falls ein Angreifer es schafft, eine Schwachstelle der in dem Image laufenden Software auszunutzen (z.B. eine PostgreSQL-Schwachstelle in einem PostgreSQL-Image), wird er keine beliebigen Shell-Befehle ausführen können. Denn im minimalen Image gibt es keine Shell. Er kann also keine zusätzliche Software herunterladen, um damit die (virtuelle) Infrastruktur weiter zu infiltrieren. Ein weiterer Vorteil ist, dass Schwachstellenscanner wie Trivy in den meisten minimalen Images alle vorhandenen Komponenten korrekt identifizieren, was False Negatives vermeidet.

Nachteile:

  • Schwieriger zu debuggen: Wenn es Probleme im Produktivbetrieb gibt, greifen Entwickler- oder Betriebsteams häufig direkt auf die Shell im Container zu, um darin Debug-Befehle auszuführen. Bei minimalen Images funktioniert dies mangels Shell nicht mehr. Es gibt jedoch Workarounds, wie kubectl debug oder das bessere cdebug. Beide starten einen kurzlebigen (ephemeral) Sidecar-Container, der den Prozess-Namespace und das Filesystem mit dem zu debuggenden Container teilt.
  • Erhöhter Testaufwand: Tauscht man bei einer containerisierten Anwendung das offizielle durch ein minimales Image aus, muss das Team manuell testen, ob es zu Kompatibilitätsproblemen kommt. Insbesondere Multi-Stage-Builds für Runtimes wie Python muss man genau betrachten. Dort kompiliert man die Anwendung in einer „Build“-Stage und kopiert sie dann in die „Final“-Stage, die das minimale Basis-Image verwendet. Verwendet man in der Build-Stage jedoch das offizielle (nicht-minimale) Image, treten oft subtile, implementierungsspezifische Inkompatibilitäten zwischen beiden Stages auf. Beispielsweise fehlen in der minimalen Final-Stage bestimmte (native) Bibliotheken oder Binärdateien. Oder der Pfad zur Runtime ist unterschiedlich, sodass der Container-Start fehlschlägt. Der Python-spezifische Abschnitt verlinkt ein konkretes Beispiel.
    Zudem ist es bei der Verwendung eines minimalen Image aufgrund der fehlenden Shell nicht möglich, mehrere Befehle (oder Shell-Entrypoint-Scripte) beim Start des Containers auszuführen.
  • Erhöhter Rechercheaufwand: Auch wenn dieser Artikel die Recherchezeit reduziert, um das beste minimale Image zu finden, fällt trotzdem immer der Rechercheaufwand an. Es könnte sich beispielsweise zeigen, dass es kein geeignetes minimales Image gibt, sodass Interessenten ein eigenes erstellen müssen, was nicht trivial und Thema von Teil 3 der Artikelserie ist.

Derzeit sind minimale Images nach wie vor ein Nischenmarkt. Die Maintainer von offiziellen Base-Images (z.B. des Python-Interpreters) oder von Stand-alone-Software wie PostgreSQL sehen aus unersichtlichen Gründen bisher davon ab, minimale Images zu erstellen.Stattdessen haben sich Drittanbieter darauf spezialisiert – wie Chainguard, Rapidfort, Docker, SecureBuild, Minimus und Bitnami.

Der folgende Abschnitt stellt verschiedene Alternativen zu Base-Image-Alternativen für diverse Runtimes sowie ein schlichtes Basis-Linux vor. Es handelt sich um typische Images, die Anwender im FROM-Statement im Dockerfile angeben, um eigene Anwendungen darauf aufzubauen.

Bei der Recherche nach Alternativen empfiehlt es sich, folgende Auswahlkriterien zu berücksichtigen:

  • Baut der Image-Maintainer die minimalen Images regelmäßig neu, z.B. alle paar Tage? Images, bei denen dies nicht der Fall ist, sollte man ignorieren. Der Docker Tag Monitor hilft dabei, die Rebuild-Frequenz bestimmter Image-Tags zu ermitteln (weitere Details finden sich in diesem Blogeintrag des Autors).
  • Sind die Images kryptografisch signiert, z. B. mit Cosign? Falls nicht, lässt sich nicht überprüfen, ob das Image manipuliert wurde.
  • Können Schwachstellenscanner (wie Trivy) die Komponenten korrekt identifizieren und mit Schwachstellendatenbanken abgleichen? Falls nicht, bleibt unklar, ob das minimale Image etwaige Schwachstellen enthält (siehe Teil 1 dieser Serie).

Alle im Folgenden vorgestellten Images erfüllen die Kriterien – andernfalls weist der Artikel auf Ausnahmen explizit hin. Die Tabelle unten bietet eine Übersicht der auf dem Markt verfügbaren Hersteller (Spalten 2-4) für die verschiedenen Use Cases (Spalte 1):

Image-Anbieter und Anwendungsfälle im Vergleich
Use case Google Distroless WolfiOS / Chainguard Ubuntu Chiseled Weitere
Basis-Linux ✅ (4 Varianten) ✅ (2 gratis Varianten, 1 Bezahl-Variante die aber gratis selbst gebaut werden kann) ⚠️ (nur bei Eigenbau)
PHP ✅ (neueste Upstream-Version)
Python ✅ (v3.11, kein ctypes Support) ✅ (neueste Upstream-Version) ✅ (v3.10, v3.12)
⚠️ (v3.13 bei Eigenbau für Ubuntu 25.04)
Java ✅ (v17, v21) ✅ (neueste Upstream-Version) ✅ (v8, v11, v17, v21) jlink
C# / .NET ✅ (neueste Upstream-Version) ✅ (.NET v6-10, von Microsoft)
Node.js ✅ (v20, v22) ✅ (neueste Upstream-Version) ⚠️ (v18, ist End-Of-Life
⚠️ (v20.18.1 bei Eigenbau für Ubuntu 25.04)



Source link

Entwicklung & Code

Vorstellung Studie Cupra Tindaya: Betont unruhig


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

In den Weiten des Volkswagen-Konzerns darf sich kaum eine Marke optisch so weit vorwagen wie Cupra. Tatsächlich seriennah dürfte die Studie Tindaya kaum sein, und doch ist die spektakuläre Formgebung mehr als nur ein Blickfang auf der IAA. Der Name Tindaya, nach einem Vulkan auf der Insel Fuerteventura, ist dabei durchaus Programm.

Terramar, Tavascan, Formentor und auch noch der Ateca, dessen Produktion absehbar ausläuft: An SUVs mangelt es der Marke Cupra derzeit wahrlich nicht. Ist dort perspektivisch Platz für ein weiteres Modell mit rund 4,7 m Länge? Ja, befanden offenbar die Verantwortlichen. Die Studie Tindaya ist 4,72 m lang und ausschließlich auf batterieelektrische Antriebe ausgerichtet. Welche Plattform in einem Serienmodell genutzt werden würde, ist aktuell noch zweitrangig. Viel spricht dafür, dass es die Basis des kommenden VW ID.4 sein könnte.

Das kantig-faltige Design ist bewusst überzeichnet. Allein schon der gesetzliche Fußgängerschutz würde einem Serieneinsatz dieser Front vermutlich entgegenstehen. Riesige Radhäuser, in denen selbst 23-Zoll-Felgen samt Reifen mit geringer Flankenhöhe nicht übertrieben scheinen, haben da vermutlich bessere Chancen. Innen gibt es vier Einzelsitze, ein 24-Zoll-Display, ein Lenkrad im Gaming-Stil und eine Mittelkonsole, die an die 2023er-Studie des Lamborghini Lanzador erinnert. In der Mitte der bis in den Fond durchgehenden Konsole befindet sich ein Zentralknopf, mit dem sich verschiedene Funktionen ansteuern lassen.

Ein aufregend gestaltetes Serienmodell würde sich bei den Antriebskomponenten vermutlich im Baukasten des Konzerns bedienen. Hinter- wie Allradantrieb wären damit möglich. Das Leistungsangebot dürfte sich zwischen 210 und 250 kW bewegen, wobei wir damit rechnen, dass sich Volkswagen irgendwann genötigt sehen könnte, in dieser Hinsicht nachzulegen. Ein Ende des Wettrüstens ist schließlich nicht abzusehen – ganz im Gegenteil: Der Umstieg auf Elektromobilität macht mehr Leistung vergleichsweise problemlos möglich, was eher Folgen für die Verkehrssicherheit haben wird als auf den Bedarf an Fahrenergie.


Falls Sie sich gerade fragen, ob die Umgebung, in der diese Pressebilder entstanden sind, nicht doch ein wenig … (Bild:

Cupra

)

Unter anderem Volkswagen hat mit dem E-Motor APP550 gezeigt, dass sich selbst 210 kW Spitzenleistung potenziell mitführen lassen, ohne beim Verbrauch dramatisch über dem zu liegen, was ein elektrischer Kleinwagen wie der Opel Corsa-e auch braucht. Auch in dieser Hinsicht unterscheiden sich Verbrenner und batterieelektrischer Antrieb enorm. Das Potenzial eines aufgeladenen V8 wird auch bei gemäßigter Fahrweise immer ein Stück weit zu füttern sein. Beim ungleich effizienteren E-Motor steigt der Verbrauch erst dann, wenn die Leistung abgerufen wird.

Zweigeteilt ist die Welt bei Volkswagen hinsichtlich der Ladeleistung. Audi und Porsche haben schon Modelle mit 800 Volt Spannungsebene, was Ladeleistung von deutlich mehr als 200 kW an der gängigen, mit 500 Ampere abgesicherten Ladeinfrastruktur erlaubt. Marken wie Skoda, VW und eben auch Cupra nutzen derzeit ein 400-Volt-System. Damit ist an Ladesäulen mit 500 A bei 200 kW die Spitze erreicht. Mittelfristig werden auch andere Konzernmarken Elektroautos mit 800 Volt ins Sortiment aufnehmen. Ob ein Serienableger der Studie Tindaya dazu gehören könnte, ist ungewiss.

Lesen Sie mehr zur Marke Cupra


(mfz)



Source link

Weiterlesen

Entwicklung & Code

Bewölkte Aussichten: Nur noch Cloud-Lizenzen bei Atlassian


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Der Softwareanbieter Atlassian stellt den Verkauf seiner Data-Center-Produkte ein. Dazu gehören die Wiki-Software Confluence oder das Projektmanagement-Tool Jira. Ab März 2026 wird es für Neukunden nur noch Cloud-Lizenzen geben.

Den Schritt begründet Atlassian damit, dass sich inzwischen nahezu alle Neukunden für die Cloud entscheiden. Mit dem Wechsel auf die Cloud-Plattform würde auch eine deutliche Verbesserung der Teamarbeit einhergehen. Den Verkauf von Serverlizenzen seiner Produkte hat Atlassian bereits im Jahr 2021 eingestellt.

Die Cloud-Umstellung führt Atlassian schrittweise über einen Zeitraum von drei Jahren durch. Ab dem 16. Dezember 2025 nimmt die Firma neue Marketplace-Apps für Data Center nicht mehr an. Am 30. März 2026 endet dann der Verkauf von Data-Center-Abonnements und Marketplace-Apps für Neukunden. Bestandskunden können noch bis zum 30. März 2028 neue Lizenzen erwerben.


Infografik Zeitplan

Infografik Zeitplan

Zeitplan: Atlassian migriert seine Data Center-Produkte ab Dezember 2025 schrittweise in die Cloud. Bis 2029 soll der Umzug vollständig durchgeführt sein.

(Bild: Atlassian)

Abgesehen von zwei Ausnahmen laufen alle Lizenzen dann am 28. März 2029 ab. Die Versionsverwaltung Bitbucket Data Center wird weiterhin über eine neue Hybridlizenz verfügbar sein, die Kunden gleichermaßen Zugriff auf Bitbucket Data Center und Bitbucket Cloud gewährt. Des Weiteren bietet Atlassian für bestimmte Rechenzentrumskunden auch nach dem 28. März 2029 noch eine erweiterte Wartung an, um sie beim Umzug in die Cloud zu unterstützen.

Den Umstieg in die Cloud begleitet der Hersteller mit seinem neuen Programm Atlassian Acend, das Kunden den Wechsel möglichst leicht machen will, etwa durch Live-Webinare und individuellen Support. Je nach Unternehmensgröße stehen unterschiedliche Cloud-Migrationstools zur Verfügung.

Kunden mit weniger als tausend Benutzerinnen und Benutzern verweist der Anbieter auf seine Self-Service-Tools. Größeren Organisationen offeriert Atlassian das FastShift-Programm. Dabei handelt es sich um eine kostenlose strategische Partnerschaft, mit der sich die Cloud-Migration drastisch verkürzen lassen soll. Kunden mit mehr als 5000 Benutzern lässt Atlassian mit dem Solution Design Acceleration-Programm, das auf die Geschäftsziele des Unternehmens abgestimmt ist, die breiteste Unterstützung zukommen.

Atlassian will seine Cloud-Plattform künftig weiter ausbauen, etwa über eine Partnerschaft mit Google Cloud zur Entwicklung einer Multi-Cloud. Welche Updates geplant sind, lässt sich in der öffentlichen Roadmap im Detail einsehen.


(who)



Source link

Weiterlesen

Entwicklung & Code

Testing Unleashed: Wie Tester Vertrauen in Softwareteams aufbauen


In dieser Folge sprechen Richard Seidl und Katja Obring (alias: Kat) darüber, wie agile Teams die Qualität des gesamten Produkts steigern. Sie zeichnen die Rolle des Testers nach – vom Fehlerfinder zum Moderator, der Risiken, Daten und Empathie in die tägliche Arbeit einbringt.

Eine Geschichte über einen Check-out, der auf alten Telefonen fehlgeschlagen ist, zeigt, warum Zugänglichkeit und Leistung in den Sprint gehören und nicht ans Ende. Sie sprechen auch darüber, was es zu automatisieren und zu erforschen gilt, wie man scharfe Metriken festlegt und wie Pairing und kleine Experimente Gewohnheiten ändern.

„So I think the first step is always trying to understand who you are talking to, trying to understand what matters to them, what do they really care about. Bad quality is something that hurts the business, but how does it hurt this particular person? What is the impact on this person or on the team that this person works with?“ – Kat Obring

Dieser Podcast betrachtet alles, was auf Softwarequalität einzahlt: von Agilität, KI, Testautomatisierung, bis hin zu Architektur- oder Code-Reviews und Prozessoptimierungen. Alles mit dem Ziel, bessere Software zu entwickeln und die Teams zu stärken. Frei nach dem Podcast-Motto: Better Teams. Better Software. Better World.

Richard Seidl spricht dabei mit internationalen Gästen über modernes Software Engineering und wie Testing und Qualität im Alltag gelebt werden können.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Wie Tester Vertrauen in Software-Teams aufbauen – Kat Obring“ und steht auf YouTube bereit.


(mdo)



Source link

Weiterlesen

Beliebt