Trivy findet hunderte CVEs in euren Images. So entscheidet ihr, welche ihr vor dem nächsten Release fixt.
Trivy scannt Images, SBOMs und Cluster-Konfiguration und meldet jede bekannte Schwachstelle im Layer. Priorität bekommt ein Finding erst über den Kontext: Ist das Paket im laufenden Container überhaupt geladen, ist der Pod von außen erreichbar, existiert ein Fix-Release? Ohne diesen Filter arbeitet ihr eine Liste ab, die nie kürzer wird. Praktisch heißt das: Scan in die CI, Severity plus Fixverfügbarkeit als Gate, alles andere in ein Backlog mit Frist.
Was Trivy scannt und was der Scanner nicht sieht
Trivy ist ein Open-Source-Scanner von Aqua Security. Er liest die Paketliste eines Artefakts und gleicht sie gegen öffentliche Schwachstellen-Datenbanken ab, also NVD, die Advisories der jeweiligen Distribution und die Sprach-Ökosysteme. Vier Scan-Ziele sind im Alltag relevant: das gebaute Container-Image, das Repository vor dem Build, IaC-Dateien und Kubernetes-Manifeste, und der laufende Cluster. Dazu kommt der Import einer SBOM, wenn ihr Artefakte von Dritten prüfen müsst.
Im Report steht: welches Paket in welcher Version in welchem Layer liegt, welche CVE dazu bekannt ist, welche Severity die Quelle vergibt und ob es ein Release gibt, in dem die Lücke geschlossen ist.
Im Report steht nicht: ob das betroffene Binary im Container überhaupt gestartet wird, ob der Pod eine Route von außen hat, ob das Paket nur zum Kompilieren gebraucht wurde und ob für den Fund bereits eine Entscheidung dokumentiert ist.
Diese Lücke ist keine Schwäche des Werkzeugs, sondern seine Aufgabenteilung. Der Scanner liefert Fakten über das Artefakt, die Bewertung kommt aus eurem Betrieb. Und aus einem Scan-Ergebnis wird erst dann eine Regel, wenn ein Admission Controller das Deployment ablehnt: Wie ihr das durchsetzt, steht auf Policies im Kubernetes-Cluster.
Warum hunderte Findings noch keine Handlungsliste sind
Der typische Fall aus unseren Reviews sieht so aus: Ein Team scannt zum ersten Mal ein Anwendungsimage mit voller Distro-Base und bekommt einen Report mit mehreren hundert Zeilen, verteilt über alle Severity-Stufen. Zwei Wochen später ist die Liste länger, nicht kürzer, weil die CVE-Datenbank schneller wächst als die Sprints. Der Scan war schnell eingebaut, die Entscheidung darüber fehlt seit Monaten.
Die Reaktion ist berechenbar. Entweder das Team stellt das Gate scharf, blockiert bei jedem kritischen Finding und wird nach zwei Wochen per Ignore-Datei umgangen. Oder es lässt den Scan nur warnen, und dann liest den Report niemand mehr. Beides sieht nach Security aus und ist keine.
Ein Gate, das alles blockiert, wird umgangen. Danach scannt ihr zwar noch, aber ihr entscheidet nichts mehr.
Der Scan selbst kostet nichts, die Priorisierung ist die Arbeit. Bei uns ist genau dieser Schritt beziffert: 0,5 bis 1 Personentag als Konfigurations-Review, ab 850 EUR. Zum Marktkontext, weil die Frage regelmäßig kommt: Wir haben den deutschen Anbietermarkt durchgesehen, 0 von 17 Anbietern haben ein buchbares Security-Produkt mit Preis. Alles andere läuft über Erstgespräch und Angebot.
Wie ihr ein Finding nach Erreichbarkeit im Cluster einstuft
Die folgende Matrix ist die Entscheidungslogik, die wir in Reviews anlegen. Sie ersetzt den CVSS-Score nicht, sie ordnet ihn ein. Drei Spalten muss jemand aus eurem Team beantworten, der den Workload kennt, sonst bleibt die Severity das einzige Kriterium und die Liste bleibt lang.
| Trivy-Severity | Paket im laufenden Prozess geladen | Workload von außen erreichbar | Fix im Upstream-Release | Einstufung |
|---|---|---|---|---|
| CRITICAL | ja | Ingress | ja | sofort patchen |
| CRITICAL | ja | Ingress | nein | dokumentierte Ausnahme mit Ablaufdatum |
| CRITICAL | ja | nur clusterintern | ja | nächster Release |
| CRITICAL | nur Build-Abhängigkeit | Ingress | ja | nächster Release |
| HIGH | ja | Ingress | ja | sofort patchen |
| HIGH | ja | Ingress | nur Major-Sprung | Backlog mit Frist |
| HIGH | nein | nur clusterintern | ja | nächster Release |
| HIGH | nein | kein Netzwerkpfad | nein | dokumentierte Ausnahme mit Ablaufdatum |
| MEDIUM | ja | Ingress | ja | nächster Release |
| MEDIUM | nur Build-Abhängigkeit | kein Netzwerkpfad | nein | Backlog mit Frist |
Zwei Dinge fallen beim Ausfüllen sofort auf. Erstens verschwindet ein großer Teil der Findings in der Zeile Build-Abhängigkeit, weil das Paket im finalen Layer gar nichts zu suchen hat. Zweitens hängt die Spalte Erreichbarkeit an eurer Netzwerkkonfiguration, nicht am Scanner. Wie ihr Pfade im Cluster tatsächlich abschneidet, steht auf NetworkPolicies, hier ist Erreichbarkeit nur das Sortierkriterium.
Trivy in der CI: wann der Build bricht und wann er nur warnt
Fünf Schritte, in dieser Reihenfolge eingeführt. Wer mit Schritt zwei anfängt, hat innerhalb eines Monats ein umgangenes Gate.
Scannen ohne Konsequenz. Trivy läuft bei jedem Build, der Report wird als Artefakt gespeichert, der Exit-Code ist null. Zwei bis drei Wochen lang. Ihr braucht die Grundlinie, bevor ihr blockiert.
Gate mit zwei Bedingungen. Der Build bricht, wenn Severity HIGH oder CRITICAL ist und ein Fix im Upstream verfügbar ist. Beides zusammen, nicht einzeln. Ein Finding ohne Fix darf keinen Merge blockieren, weil das Team es sonst wegkonfiguriert.
Täglicher Scan der laufenden Workloads. Der Build-Scan prüft, was ihr neu einbaut. Der tägliche Cluster-Scan prüft, was gestern noch sauber war. Ohne den zweiten seht ihr neue CVEs erst beim nächsten Deployment, und bei stabilen Services kann das ein halbes Jahr dauern.
Owner und Frist pro Finding. Jedes Finding, das nicht sofort gepatcht wird, bekommt ein Team und ein Datum. Ohne Owner landet der Report im Kanal, in dem alle Reports landen.
Ausnahmen mit Ablaufdatum. Trivy unterstützt Ignore-Einträge mit Gültigkeitsdatum. Nutzt sie ausschließlich so. Ein Eintrag ohne Datum ist eine stille Dauerentscheidung, die niemand mehr prüft.
Was ihr mit CVEs macht, für die es keinen Fix gibt
Ihr dokumentiert sie. Ein Finding ohne verfügbaren Fix hat drei Angaben zu tragen: warum es in eurem Kontext nicht ausnutzbar ist, welche kompensierende Maßnahme greift, und wann ihr erneut prüft. Kompensierend heißt zum Beispiel, dass der Workload keinen Ingress hat, dass eine NetworkPolicy den Egress abschneidet oder dass die betroffene Funktion im Code nicht aufgerufen wird.
Der Unterschied zwischen Dokumentieren und Ignorieren ist das Ablaufdatum. Läuft der Eintrag aus, taucht das Finding im nächsten Build wieder auf und jemand entscheidet neu. Genau diese Einträge sind auch das, wonach ein Prüfer fragt: nicht nach einem leeren Report, sondern nach einer nachvollziehbaren Kette aus Fund, Bewertung, Entscheidung und Wiedervorlage. Was davon in einen Nachweis gehört, steht auf Kubernetes-Compliance.
Base-Image, Distroless, Rebuild: wo die meisten Findings herkommen
Der überwiegende Teil der Findings in einem typischen Anwendungsimage stammt nicht aus eurem Code, sondern aus dem Base-Layer. Eine vollständige Distribution bringt Paketmanager, Shell, Netzwerk-Werkzeuge und Bibliotheken mit, die eure Anwendung nie anfasst. Jedes dieser Pakete kann eine CVE bekommen, und jede dieser CVEs landet in eurem Report.
Drei Hebel wirken hier, bevor ihr überhaupt priorisiert. Erstens ein schlankeres Base-Image: Distroless oder eine minimale Variante entfernt Pakete, statt sie zu patchen. Zweitens ein Multi-Stage-Build, der Compiler und Build-Abhängigkeiten nicht ins finale Image mitnimmt. Drittens eine Rebuild-Kadenz: Ein Image, das seit sechs Monaten nicht neu gebaut wurde, sammelt Findings, die ein wöchentlicher Rebuild gegen ein aktuelles Base-Image von selbst erledigt. Wer den Rebuild automatisiert im Betrieb halten will, findet den Rahmen unter Managed Kubernetes. Wie Image-Härtung und Laufzeitkonfiguration zusammenhängen, steht auf Container Security.
Der Angriffsflächen-Check ist ein Konfigurations-Review, kein Pentest
Was wir machen Wir lesen eure Cluster-Konfiguration, die Image-Pipeline und eure Scan-Ergebnisse gegen den CIS-Benchmark und sagen euch, welche Findings in eurem Setup überhaupt erreichbar sind. Aufwand 0,5 bis 1 Personentag, ab 850 EUR.
Was wir nicht machen Wir greifen nichts an, exploiten nichts und liefern keinen Nachweis, dass ein Angriff durchgeht. Wenn ihr einen echten Penetrationstest braucht, weil ein Kunde oder ein Auditor ihn verlangt, vermitteln wir einen Partner, der liegt bei 8.000 EUR. Und ein Prüftestat ist beides nicht, das erteilen ausschließlich akkreditierte Stellen.
Rahmen Servicezeit Mo-Fr 08:00-18:00 MEZ. Pexon ist ISO 27001 zertifiziert, im Team sind CKA, CKAD, CKS und KCNA.
Was der Check kostet und was danach auf dem Tisch liegt
Der Einstieg ist der Self-Check über 20 Punkte, kostenlos und ohne Gespräch, zu finden auf dem Hub Kubernetes Security. Wer danach eine Einstufung seiner konkreten Findings will, bucht den Angriffsflächen-Check ab 850 EUR. Ergebnis ist eine sortierte Liste im Format der Matrix oben, dazu die Gate-Regel für eure Pipeline und die Ausnahmen, die mit Ablaufdatum dokumentiert gehören.
Zwei Anschlüsse gibt es, beide optional. Der Compliance-Snapshot für 1.250 EUR, wenn ihr die Kette für einen Prüfer belegen müsst. Und der laufende Betrieb ab 2.500 EUR im Monat, wenn Scan, Rebuild und Patch-Kadenz nicht mehr an einzelnen Personen hängen sollen. Zur Größenordnung: Ein Senior-Engineer betreut 30 bis 50 Cluster mit GitOps, deshalb ist der wiederkehrende Teil dieser Arbeit automatisierbar und der Review-Teil nicht.
Verwandte Seiten im Security-Zweig
- Kubernetes Security: der Hub mit Self-Check, Angriffsflächen-Check und Compliance-Snapshot.
- Container Security: die Laufzeit: was ein Container darf, nachdem das Image gebaut ist.
- Policies und Admission Control: Regeln, die ungescannte oder veraltete Images gar nicht erst zulassen.
- Network Policies: Trennung im Netz, falls ein verwundbares Image doch läuft.
- Kubernetes RBAC: wer im Cluster was darf, unabhängig vom Image.
- Kubernetes Compliance: Nachweise für NIS2, ISO und Kundenaudits.
- Managed Kubernetes: wenn Scan, Rebuild und Patch-Kadenz nicht an einzelnen Personen hängen sollen.
- Hardening-Checkliste: die bestehende Liste zum Durcharbeiten.
- Trivy Kubernetes Scanner: Festpreis-Report mit priorisierten Findings (850 EUR).
- Trivy Kubernetes Scanner (Praxis): CLI und Operator im Cluster.
Häufige Fragen zu Trivy und Image-Scanning
Wie finde ich heraus, welche der Trivy-Findings in meinem Cluster wirklich ausnutzbar sind?
Trivy sagt euch, welche Pakete im Image liegen, nicht welche davon laufen. Den Filter baut ihr selbst: Läuft das betroffene Binary im Container, ist der Pod über Ingress oder Service erreichbar, hängt das Paket nur als Build-Abhängigkeit im Layer? Erst diese drei Fragen machen aus dem Report eine Liste, die kürzer wird.
Soll Trivy den Build brechen oder nur warnen?
Brechen, aber nur bei zwei Bedingungen zusammen: Severity hoch oder kritisch und ein Fix ist im Upstream verfügbar. Alles andere warnt und landet im Backlog mit Frist. Ein Gate, das bei jedem kritischen Finding ohne verfügbaren Fix blockiert, wird nach zwei Wochen per Ignore-File umgangen. Dann scannt ihr zwar, aber ihr entscheidet nichts mehr.
Was mache ich mit CVEs, für die es kein Fix-Release gibt?
Dokumentieren statt ignorieren. Ihr haltet fest, warum das Finding im eigenen Kontext nicht ausnutzbar ist, welche kompensierende Maßnahme greift und wann ihr erneut prüft. Trivy unterstützt das über die Ignore-Datei mit Ablaufdatum. Ohne Datum wird aus der Ausnahme Dauerzustand, und genau diese Einträge fallen im nächsten Audit auf.
Reicht der Scanner meiner Registry oder brauche ich Trivy zusätzlich?
Der Registry-Scanner deckt Images ab, die in der Registry liegen. Trivy deckt zusätzlich das Repository vor dem Build, IaC-Dateien, Kubernetes-Manifeste und den laufenden Cluster ab. Wenn ihr nur wissen wollt, ob ein veröffentlichtes Image Lücken hat, reicht die Registry. Sobald ihr Findings vor dem Merge sehen wollt, braucht ihr den Scan in der Pipeline.
Wie oft muss ich Images scannen, wenn sich der Code nicht ändert?
Täglich, auch wenn sich nichts ändert. Der Code bleibt gleich, die CVE-Datenbank nicht. Ein Image, das gestern sauber war, hat heute ein kritisches Finding im Base-Layer. Praktikabel ist ein täglicher Scan der laufenden Workloads plus ein Scan bei jedem Build. Der erste findet neue CVEs, der zweite verhindert, dass ihr neue einbaut.
Prüft NIS2 oder ISO 27001, ob ich Container-Images scanne?
Beide verlangen einen Prozess für technische Schwachstellen, keinen bestimmten Scanner. NIS2 ist über das BSIG am 06.12.2025 in Kraft getreten und fordert Risikomanagement inklusive Umgang mit Schwachstellen. ISO 27001 fordert denselben Nachweis. Ein Prüfer will sehen: wer scannt, in welchem Takt, wer entscheidet über Ausnahmen und wo das dokumentiert ist.
Der nächste Schritt
Wenn ihr einen Trivy-Report habt und nicht wisst, welche Zeilen davon vor dem nächsten Release gehören, bringt ihn ins Erstgespräch mit. Wir gehen ihn gegen die Matrix oben durch, und ihr seht am Ende des Gesprächs, wie viel von der Liste tatsächlich Handlungsbedarf ist. Wenn danach nichts folgt, habt ihr trotzdem die Sortierlogik. Servicezeit Mo-Fr 08:00-18:00 MEZ.