Automatisiertes Patchen von Container-Images

Sicherheitslücken in von Drittanbietern bezogenen Container-Images automatisch schliessen und jeden Eingriff transparent und reproduzierbar dokumentieren.

Ausgangslage

Moderne Software wird heute meist in Containern ausgeliefert: standardisierten Paketen, die ein Programm samt allen Abhängigkeiten enthalten. Viele Unternehmen beziehen solche Container-Images fertig von Drittanbietern aus öffentlichen Katalogen, ähnlich wie man eine fertige App aus einem App-Store lädt. Der Bauplan des Images, das sogenannte Dockerfile, liegt dabei in der Regel nicht vor. Das ist problematisch, denn Container-Images enthalten häufig bekannte Sicherheitslücken in ihren Systemkomponenten. Ohne Bauplan lassen sich diese Lücken nicht auf dem klassischen Weg beheben, also durch Anpassen des Bauplans und erneutes Bauen des Images. Wer das Image einsetzt, kann weder beeinflussen noch verlässlich beurteilen, wie sicher es tatsächlich ist.

Projektbild

Problemstellung / Projektziel

Ziel des Projekts war es zu untersuchen, in welchem Umfang sich solche Sicherheitslücken automatisiert schliessen lassen und welche Lücken trotz Automatisierung offen bleiben. Bestehende Patch-Werkzeuge können Images zwar auch ohne Bauplan reparieren, hinterlassen dabei aber keine Spur, was genau verändert wurde. Im Projekt wurde deshalb das Open-Source-Werkzeug Copa so erweitert, dass jeder Patch-Vorgang zusätzlich ein Dockerfile erzeugt: ein Rezept, das festhält, welche Pakete in welcher Version installiert und welche Sicherheitslücken damit behoben wurden. Lücken, für die noch keine Korrektur existiert, werden offen ausgewiesen statt stillschweigend übergangen. So bleibt der gesamte Vorgang auch für Dritte nachvollziehbar und überprüfbar, etwa für Sicherheitsnachweise und Audits.

Systemkontext

Systemkontext: das Patch-System in seiner Umgebung

Das System als Ganzes: Es erhält den Verweis auf ein zu prüfendes Image sowie die Befunde des Sicherheits-Scanners und liefert ein gepatchtes Image sowie ein Dockerfile, das den Eingriff dokumentiert.

Pipeline in Aktion

Erfolgreicher GitLab-Pipeline-Lauf mit den Stufen scan, patch, verify und deploy

Ein echter Pipeline-Lauf in GitLab: Die Komponenten scannen das Image, patchen es, prüfen die Reproduzierbarkeit und stellen das Ergebnis bereit.

Generiertes Dockerfile

Ausschnitt eines generierten Dockerfiles mit Patch-Zusammenfassung und CVE-Kommentaren

Ausschnitt eines erzeugten Dockerfiles: Eine Zusammenfassung nennt behobene und offene Lücken, jede Paketzeile ist mit den zugehörigen Sicherheitslücken (CVEs) kommentiert.

Entwickelte Lösung und ihr Nutzen

Die Lösung besteht aus einer Erweiterung des Open-Source-Patch-Werkzeugs Copa und einem Satz fertiger Bausteine für die Automatisierungsplattform GitLab. Mit einer einzigen Option schreibt Copa neben dem gepatchten Image nun ein Dockerfile. Diese Datei ist Sicherheits-Änderungsprotokoll und reproduzierbares Rezept zugleich: Sie hält das exakte Basis-Image fest, listet jede installierte Paketversion mit den dadurch behobenen Sicherheitslücken auf und weist die Befunde explizit aus, die mangels verfügbarer Korrektur offen bleiben. Die wichtigsten Vorteile:

  • Beheben von Sicherheitslücken ohne Zugriff auf den Bauplan des Images
  • ein erzeugtes Dockerfile dokumentiert den Patch nachvollziehbar
  • offene Lücken werden transparent aufgelistet statt stillschweigend verworfen
  • eine automatische Prüfung belegt, dass das Rezept den reparierten Zustand reproduziert
  • einfache Einbindung in bestehende GitLab-Projekte als fertige Komponente

Die Evaluation an sieben verbreiteten Debian- und Ubuntu-basierten Images bestätigte den Ansatz: Alle behebbaren Betriebssystem-Sicherheitslücken wurden entfernt, und ein aus dem erzeugten Dockerfile neu gebautes Image wies exakt denselben Sicherheitsstand auf wie das direkt gepatchte. Die Untersuchung machte zugleich die Grenzen der Automatisierung sichtbar: Je nach Image existiert nur für 27 bis 58 Prozent aller Befunde überhaupt eine Korrektur. Automatisiertes Patchen ist damit wirksam und überprüfbar, ersetzt aber nicht die Pflege aktueller Basis-Images.

Technische Schlüsselbegriffe

  • Container-Image Standardisiertes Softwarepaket, das ein Programm samt allen Abhängigkeiten enthält und überall gleich läuft.
  • CVE Öffentlich dokumentierte Sicherheitslücke mit eindeutiger Kennnummer (Common Vulnerabilities and Exposures).
  • Dockerfile Bauplan eines Container-Images, der Schritt für Schritt beschreibt, wie das Image erstellt wird.
  • Post-Build-Patching Nachträgliches Beheben von Sicherheitslücken direkt im fertigen Image, ohne es neu bauen zu müssen.
  • Copa Open-Source-Werkzeug, das Container-Images ohne Zugriff auf deren Bauplan patchen kann; in diesem Projekt erweitert.
  • Trivy Weit verbreitetes Werkzeug, das Container-Images auf bekannte Sicherheitslücken untersucht.
  • CI/CD-Pipeline Automatisierte Abfolge von Schritten, die Software baut, prüft und ausliefert; hier umgesetzt mit GitLab.
  • Reproduzierbarkeit Eigenschaft, dass ein dokumentierter Vorgang später mit identischem Ergebnis wiederholt werden kann.

Team

Dean Bregenzer

Betreuer
Daniel Hass