Containersicherheit ist schwierig – Aikido Container AutoFix macht es einfach

Containersicherheit beginnt mit Ihrem Basis-Image.
Aber hier ist der Haken:

• Ein einfaches Upgrade auf die „neueste“ Version eines Basis-Images kann Ihre Anwendung beschädigen.
• Sie sind gezwungen, sich zwischen dem Ausliefern bekannter Schwachstellen oder dem tagelangen Beheben von Kompatibilitätsproblemen zu entscheiden.
• Und oft... sind Sie sich nicht einmal sicher, ob sich ein Upgrade lohnt.

In diesem Beitrag untersuchen wir, warum das Aktualisieren von Basis-Images schwieriger ist, als es scheint, gehen reale Beispiele durch und zeigen, wie Sie sichere, intelligente Upgrades automatisieren können, ohne Ihre Anwendung zu beschädigen.

Das Problem: „Aktualisieren Sie einfach Ihr Basis-Image“ – Leichter gesagt als getan

Wenn Sie dies lesen, haben Sie wahrscheinlich etwas gegoogelt wie „Wie sichert man seine Container“, und der erste Punkt in jedem KI-generierten Schrottartikel, den Sie gelesen haben, ist dieser: aktualisieren Sie Ihr Basis-Image. Einfach, oder? Nun, nicht ganz so schnell. 

Ihr Basis-Image ist Ihr zentraler Sicherheitspunkt; wenn Ihr Basis-Image Schwachstellen enthält, trägt Ihre Anwendung diese Schwachstellen mit sich. Lassen Sie uns dieses Szenario durchspielen. 

Sie führen einen Scan Ihres Container-Images durch und es wird eine CVE mit hohem Schweregrad gefunden. Die hilfreiche Empfehlung lautet, das Basis-Image zu aktualisieren – fantastisch, Sie sind vor dem Mittagessen fertig. 

⚠️ CVE-2023-37920 gefunden in ubuntu:20.04
Schweregrad: Hoch
Behoben in: 22.04
Empfehlung: Basis-Image aktualisieren

„…aber Sie entdecken ein Problem.“ 

Durch blindes Upgrade von ubuntu:20.04 zu ubuntu:22.04, zerbricht Ihre Anwendung.

Schauen wir uns einige Beispiele an, wie ein Base Image aktualisiert wird und was in der Realität passiert. 

Beispiel 1: Ein Dockerfile, das nach einem Upgrade fehlschlägt

Initiales Dockerfile:

FROM python:3.8-buster‍
RUN apt-get update && apt-get install -y libpq-dev
RUN pip install psycopg2==2.8.6 flask==1.1.2
COPY . /appCMD ["python", "app.py"]

Das Team rüstet auf zu:

FROM python:3.11-bookworm‍
RUN apt-get update && apt-get install -y libpq-dev
RUN pip install psycopg2==2.8.6 flask==1.1.2COPY . /appCMD ["python", "app.py"]

Ergebnis:

• psycopg2==2.8.6 lässt sich nicht gegen neuere kompilieren libpq Header aktiviert Bücherwurm.
• flask==1.1.2 unterstützt nicht Python 3.11 Laufzeitfunktionen (veraltete APIs führen zu Fehlern).
• Der Build schlägt in CI fehl.
• Ihr Dev-Team ist verärgert und Ihr Mittagessen ist ruiniert. 

Beispiel 2: Base-Image-Upgrades, die subtile Laufzeitfehler einführen

Original:

FROM node:14-busterCOPY . /app
RUN npm ci
CMD ["node", "server.js"]

Upgrade auf:

FROM node:20-bullseye
COPY . /app
RUN npm ci
CMD ["node", "server.js"]

Laufzeitproblem:

• node:20 verwendet neuere OpenSSL Versionen — strenge TLS-Verifizierung führt bei älteren axios-Konfigurationen zu Problemen.
• Die App wirft UNABLE_TO_VERIFY_LEAF_SIGNATURE Laufzeitfehler HTTP Aufrufe an Legacy-Dienste.

Warum „latest“ eine Falle ist

Das Docker-Ökosystem fördert die Verwendung von neuesten Tags oder Top-Line-Releases. Dies bedeutet jedoch oft, dass Ihre Anwendung, die am Montag noch lief, am Dienstag plötzlich ausfällt. Dies ist oft eine Falle, die zu Kopfschmerzen, Ausfällen und einer langsameren Entwicklung führt, da Sie Zeit mit der Fehlerbehebung verbringen. 

Die Lösung ist dann offensichtlich, auf eine getestete Minor-Version zu pinnen… Nicht so schnell, denn jetzt sind Sie in das Spiel des Security Whack-a-Mole eingetreten, wo Sie für immer neue CVEs entdecken werden, die Sie anfällig machen könnten. 

Entscheidungslähmung: Sollten Sie ein Upgrade durchführen oder nicht?

Sicherheitsteams drängen auf Upgrades.
Entwickelnde wehren sich aufgrund der Stabilität.

Wer hat Recht? Es kommt darauf an.

UM die Entscheidung überhaupt zu verstehen, müssen Sie alle Optionen prüfen, was bedeutet, eine riesige Tabelle mit allen Versionen, Sicherheitsrisiken, Stabilitätsrisiken und Verfügbarkeiten zu erstellen. 

Werfen wir einen Blick darauf, wie das aussehen könnte. 

Das führt zu komplexen, mangelhaften und unmöglichen Entscheidungen 

1. Bleiben Sie beim alten Image und akzeptieren Sie Schwachstellen.
2. Ihre App upgraden und dabei beschädigen, mit dem Risiko von Produktionsausfällen
3. Manuelle Kompatibilitätstests versuchen – tagelange Arbeit

Der manuelle Upgrade-Workflow:

Wenn Sie dies manuell tun, sieht es so aus:

• CVEs prüfen: trivy image python:3.8-buster
• Jede CVE recherchieren: Ist sie im Kontext Ihrer Anwendung erreichbar?
• Über Upgrade-Kandidaten entscheiden 
• Testen Sie das neue Image:
  
  • Build
  • Führen Sie Unit-Tests aus
  • Führen Sie Integrationstests aus
• Im Fehlerfall versuchen Sie, Code zu patchen oder Bibliotheken zu aktualisieren.
• Für jeden Container wiederholen.

Es ist anstrengend.

Die Kosten des Stillstands

Sie denken vielleicht: “Never change a running system.”

Aber ungepatchte Container-CVEs tragen massiv zu Sicherheitsverletzungen bei: „87 % der in Produktion befindlichen Container-Images wiesen mindestens eine kritische oder hochgradige Schwachstelle auf.“ Quelle 

Es gibt auch viele bekannte Exploits, die in gängigen Basis-Images existieren. 

• Unzip Path Traversal Schwachstelle (CVE-2020-27350) — saß jahrelang in Millionen von Containern.
• Heartbleed (CVE-2014-0160) verblieben lange nach offiziellen Fixes in Legacy-Containern.
• PHP-FPM RCE (CVE-2019-11043) ermöglichen es Remote-Angreifern, beliebigen Code über manipulierte HTTP-Anfragen auszuführen und war extrem häufig in Container-Basis-Images mit vorinstalliertes PHP-FPM bevor sie gepatcht werden

Wie unsere Auto-Fix-Funktion hilft

Um dieses Szenario zu lösen, hat Aikido Security unsere Container-Autofix-Funktion eingeführt, denn wir kennen dieses Problem nur zu gut. 

Die Funktion funktioniert so: Aikido scannt Ihre Container auf Schwachstellen. Wenn (oder wahrscheinlicher: sobald) wir Schwachstellen finden, benachrichtigen wir Sie wie immer, und anstatt Sie aufzufordern, Ihr Basis-Image zu aktualisieren, bieten wir Ihnen verschiedene Optionen an. Wir erstellen eine Tabelle, die Ihnen zeigt, welche Version des Basis-Images welche CVEs beheben wird, so können Sie sehr schnell erkennen, dass ein kleines Update alle oder die meisten kritischen CVEs beseitigen kann, was eine ausreichende Aktualisierung des Basis-Images darstellt. 

Wenn das Upgrade ein kleiner Versionssprung ist, können Sie automatisch einen Pull Request erstellen, um die Version zu erhöhen. 

Das spart Stunden an Arbeit.

Fazit:

• Das Upgrade von Container-Basis-Images ist tatsächlich schwierig.
• Der Ratschlag „einfach upgraden“ vereinfacht einen komplexen, risikobehafteten Prozess zu stark.
• Ihre Teams sind zu Recht vorsichtig – aber sie sollten sich nicht zwischen Sicherheit und Stabilität entscheiden müssen.
• Aikidos Container-Autofix erledigt die schwierige Arbeit für Sie, damit Sie eine fundierte Entscheidung treffen können. 
• Wenn Sie also das nächste Mal eine Schwachstellenwarnung für Basis-Images sehen, werden Sie nicht in Panik geraten. Sie erhalten einen PR.