Wissen, welche Lücken laufen: Schwachstellen-Scanning mit Trivy

Man kann nicht absichern, was man nicht sieht. Ein Container-Image bringt fremde Software mit, und die altert. Was heute sauber ausgeliefert wurde, hat in einem halben Jahr ein Dutzend öffentlich dokumentierte Lücken, ganz ohne dass sich am Image etwas geändert hätte. Die Frage ist nur: Weiß ich davon? Der Trivy-Operator beantwortet sie, kontinuierlich und direkt im Cluster.

Der Operator scannt, was wirklich läuft

Der Trivy-Operator beobachtet die Workloads im Cluster. Für jedes Image startet er einen Scan-Job und schreibt das Ergebnis als eigene Kubernetes-Ressource, einen VulnerabilityReport, neben den Workload. Kein separates Portal, kein Export: Der Sicherheitsstand ist per kubectl abfragbar wie jede andere Ressource, und er wird bei Änderungen und nach Zeitplan neu erhoben.

Ich habe den Operator auf einen Demo-Workload losgelassen, ein bewusst veraltetes Image. Das Ergebnis ist ernüchternd und typisch:

Was ein Report zeigt

18 kritische und 333 hohe Schwachstellen in einem einzigen Image. Und es sind keine exotischen Funde, sondern Klassiker: Request Smuggling in Apache (CVE-2022-36760, CVE-2023-25690), eine curl-Lücke, ein Heap-Overflow in zlib. Der entscheidende Punkt steht in der letzten Spalte: Für die meisten gibt es längst einen Fix. Es sind bekannte, veröffentlichte, behebbare Lücken, die nur deshalb im Cluster laufen, weil das Image nie aktualisiert wurde. Genau das ist das häufigste Einfallstor, und es steht hier schwarz auf weiß.

Ein Teil hat übrigens keinen Fix (kein Fix in der Liste). Auch das ist ehrlich: Nicht jede Lücke ist behoben, manche wird es nie. Das gehört zur Bewertung dazu.

Die Egress-Wand: wenn der Scanner selbst nicht scannt

Jetzt die Falle, die mich in einem abgeschotteten Cluster wirklich Zeit gekostet hat. Der Scan-Job muss zwei Dinge erreichen: die Schwachstellen-Datenbank (die Trivy herunterlädt) und die Registry mit dem Image. In einer Umgebung mit dichtem Ausgang gelang beides nicht. Die Scan-Jobs kamen weder an die öffentliche DB-Quelle noch an die interne Registry heran, und weil es keine NetworkPolicy war, lag die Sperre eine Ebene tiefer, in der Firewall.

Das Tückische daran: Ein Scanner, der seine Datenbank nicht laden kann, meldet im schlechtesten Fall nichts zu beanstanden und wiegt einen in Sicherheit. Die Lösung war nicht, den Ausgang aufzureißen, sondern die Trivy-Datenbank in die interne Registry zu spiegeln und den Operator dorthin zeigen zu lassen. Genau für solche abgeschotteten Umgebungen beschreibt die Trivy-Dokumentation die Konnektivitäts- und Air-Gap-Optionen, etwa das Selbst-Hosten der Datenbank. Wer eine Registry wie Harbor betreibt, kann sie ohnehin registry-seitig scannen lassen und den In-Cluster-Scan entlasten.

Ehrlich: Ein Report ist kein Fix

Scanning findet, es behebt nichts. Der Wert entsteht erst, wenn jemand die Reports regelmäßig durchsieht, die kritischen Funde bewertet und die Images aktualisiert. Kontinuierliches Scannen ist die Voraussetzung, nicht die Lösung. Es macht aus „müsste eigentlich sicher sein“ ein „das läuft, das ist neu, das muss gepatcht werden“. Wie man das Aktualisieren dann verlässlich und dokumentiert hinbekommt, habe ich im Beitrag Patch-Management mit Ansible beschrieben.

Sie wollen wissen, welche bekannten Lücken in Ihren laufenden Systemen stecken, bevor es jemand anders herausfindet? Ich richte kontinuierliches Schwachstellen-Scanning ein und mache aus den Funden einen abarbeitbaren Plan. Mehr unter IT-Sicherheit & ISMS, das Erstgespräch ist unverbindlich.