Trivy für Kubernetes: Images, Cluster und Operator scannen

Cluster-Konfiguration prüfen lassen? Das Cluster-Audit von WZ-IT prüft Konfiguration, Versionen, Zugriffe, Netzwerk-Richtlinien, Secrets und Backups eines Kubernetes-Clusters gegen den CIS Kubernetes Benchmark und BSI IT-Grundschutz und liefert einen Bericht mit priorisierten Maßnahmen. Kubernetes-Cluster-Audit ansehen

Trivy ist ein Open-Source-Scanner von Aqua Security für bekannte Schwachstellen, Fehlkonfigurationen und Secrets in Images, Manifesten und Clustern. Für Kubernetes gibt es drei Betriebsarten, die verschiedene Fragen beantworten: trivy image in der Pipeline, trivy k8s per CLI und den Trivy Operator im Cluster. Dieser Leitfaden zeigt Befehle, Installation, Priorisierung und die Grenzen. Stand Oktober 2026: Trivy v0.76.1 (21.10.2026) und Trivy Operator v0.35.0 (05.10.2026, aktuelles GitHub-Release), beide unter Apache-2.0 (Operator: LICENSE).

Inhaltsverzeichnis

• Was Trivy prüft und wie es Funde ermittelt
• Drei Betriebsarten im Vergleich
• trivy image: Images vor dem Deployment prüfen
• trivy k8s: den laufenden Cluster prüfen
• Trivy Operator: Dauerbetrieb im Cluster
• Betrieb: Netzwerkzugriffe, Telemetrie und eigene Registry
• Funde priorisieren: eine Entscheidungsregel
• Grenzen und Abgrenzung
• Der Scanner als Teil der Lieferkette
• Stand und Methodik
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

Was Trivy prüft und wie es Funde ermittelt

Die Schwachstellenfunde beruhen auf einem Versionsabgleich mit Advisory-Quellen (Doku). Das hat Folgen für die Auswertung:

• Für OS-Pakete gelten die Advisories des Distributors, nicht die Upstream-Daten, weil Distributoren Korrekturen zurückportieren. Die Schwere stammt ebenfalls vom Distributor: CVE-2023-0464 steht in der NVD auf High, bei Red Hat auf Low, Trivy zeigt Low.
• Pakete aus Drittquellen sind nicht abgedeckt. Laut Doku unterstützt Trivy offizielle Pakete der Distributoren, aber keine Pakete aus Fremdrepositories und keine selbst kompilierten Pakete. Das vermeidet Fehlalarme, kann aber Funde auslassen. Bei verzögerten oder fehlenden Distributor-Advisories zieht --detection-priority comprehensive zusätzlich Upstream-Advisories heran, auf Kosten von Fehlalarmen.
• Der Standard priorisiert Präzision. Ein Lauf ohne Funde ist kein Beleg für Schwachstellenfreiheit.

Drei Betriebsarten im Vergleich

trivy image: Images vor dem Deployment prüfen

trivy image --severity HIGH,CRITICAL --ignore-unfixed --exit-code 1 registry.example.com/team/app:1.4.2

--ignore-unfixed blendet Funde ohne verfügbare Korrektur aus, --exit-code 1 lässt die Pipeline bei einem Fund scheitern. Beides wurde mit v0.76.1 gegen ein Testimage geprüft: Mit Funden endet der Lauf mit Exit-Code 1. In GitHub Actions bindet die trivy-action den Scan ein:

- name: Trivy image scan
  uses: aquasecurity/trivy-action@FULL-COMMIT-SHA  # v0.36.0
  with:
    image-ref: registry.example.com/team/app:${{ github.sha }}
    severity: CRITICAL,HIGH
    ignore-unfixed: true
    exit-code: "1"

Ausnahmen gehören mit Begründung und Ablaufdatum in eine .trivyignore.yaml (Felder id, statement, expired_at, paths). Die Datei ist laut Doku experimentell und muss mit --ignorefile angegeben werden (Filterung). Für Code-Scanning-Oberflächen liefert --format sarif das passende Format (Reporting).

Auch Requests und Limits werden geprüft: trivy config meldete für ein Deployment ohne Ressourcenangaben in v0.76.1 unter anderem KSV-0011 (CPU not limited), KSV-0015 (CPU requests not specified), KSV-0016 (Memory requests not specified) und KSV-0018 (Memory not limited), alle mit Schweregrad LOW. Wer CPU-Limits bewusst weglässt, dokumentiert das in der Ignore-Datei (Hintergrund im Leitfaden zu ResourceQuota und LimitRange):

misconfigurations:
  - id: KSV-0011
    statement: CPU-Limit bewusst nicht gesetzt, um Throttling zu vermeiden
    expired_at: 2027-04-30

trivy k8s: den laufenden Cluster prüfen

Der Befehl braucht eine kubeconfig mit list-Rechten auf die Ressourcen der API-Gruppen core, apps, batch, networking.k8s.io und rbac.authorization.k8s.io. Der Node-Collector, der Node-Konfigurationen einsammelt, startet Jobs und legt einen Namespace an; --disable-node-collector verzichtet darauf und lässt Node-Befunde aus (Doku).

# Überblick als Zusammenfassung
trivy k8s --report summary

# Ein Namespace, nur HIGH und CRITICAL, mit Details
trivy k8s --include-namespaces production --severity HIGH,CRITICAL --report all

# Nur Konfiguration und RBAC, ohne Images zu laden
trivy k8s --scanners misconfig,rbac --skip-images --report summary

# Eingebautes Compliance-Profil (CIS Kubernetes Benchmark v1.23)
trivy k8s --compliance k8s-cis-1.23 --report summary

# Stückliste der Cluster-Komponenten (KBOM) als CycloneDX
trivy k8s --format cyclonedx --output kbom.cdx.json

--report hat laut CLI-Referenz den Standardwert all (Referenz), summary oder all deshalb immer ausdrücklich angeben. Ältere Anleitungen schreiben trivy k8s cluster: In v0.76.1 ist das Positionsargument ein Kontext der kubeconfig, cluster endet, sofern kein Kontext dieses Namens existiert, mit der Meldung context "cluster" does not exist. Die Doku nennt eine Einschränkung selbst: Der KBOM-Abgleich funktioniert für reine Kubernetes-Distributionen, bei Herstellervarianten einschließlich mancher Managed-Dienste nur eingeschränkt. Hinzu kommt der Stand des CIS-Profils: Das eingebaute Profil basiert auf Version 1.23, während CIS auf der Benchmark-Seite derzeit 2.1.0 für Kubernetes führt. Das Ergebnis ist ein Hinweis, kein Konformitätsnachweis.

Trivy Operator: Dauerbetrieb im Cluster

Der Operator beobachtet Änderungen im Cluster, startet Scan-Jobs und legt die Ergebnisse als Custom Resources ab, unter anderem VulnerabilityReport, ConfigAuditReport, ExposedSecretReport, RbacAssessmentReport, InfraAssessmentReport, ClusterComplianceReport und SbomReport (Doku).

helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm repo update
helm install trivy-operator aqua/trivy-operator \
  --namespace trivy-system --create-namespace \
  --version CHART-VERSION \
  --set trivy.ignoreUnfixed=true

kubectl get vulnerabilityreports -A -o wide
kubectl get configauditreports -A -o wide

Die Chart-Version wird festgeschrieben (Helm-Installation). Stand 28.10.2026 ist 0.37.0 die neueste Chart-Version im Helm-Repository (App-Version 0.35.0); helm search repo aqua/trivy-operator --versions listet die verfügbaren. Betrieblich relevant sind diese Standardwerte aus der values.yaml zu v0.35.0:

• Scan-Jobs: bis zu 10 gleichzeitig (operator.scanJobsConcurrentLimit), je Scan-Container standardmäßig Request 100m CPU und 100M Memory, Limit 500m und 500M (trivy.resources). Diese Last braucht Platz auf den Nodes und im Namespace des Operators.
• Datenbank: Im Standardmodus lädt jeder Scan-Job die Schwachstellen-Datenbank neu, was zu Rate-Limits führen kann. operator.builtInTrivyServer=true aktiviert den Client-Server-Modus mit gemeinsamer Datenbank (Doku).
• Lebensdauer der Berichte: 24 Stunden (operator.scannerReportTTL).
• Metriken: Der Chart kann Prometheus-Metriken und einen ServiceMonitor bereitstellen.

Der Operator erzeugt Berichte je Container-Image eines Workloads; kubectl get vulnerabilityreports -o wide zeigt je Bericht die Anzahl nach Schweregrad. Dasselbe Image in zehn Deployments erscheint zehnmal, für die Bewertung zählen deshalb Images, nicht Berichte.

Betrieb: Netzwerkzugriffe, Telemetrie und eigene Registry

Trivy braucht im Normalbetrieb Internetzugriff. Die Datenbanken für Schwachstellen, Java und Checks liegen als OCI-Images in öffentlichen Registries, standardmäßig mirror.gcr.io und ghcr.io; das Projekt weist auf mögliche Rate-Limits bei hoher Last hin (Netzwerk-Doku). Wer externe Zugriffe vermeiden will, spiegelt die Datenbanken in eine eigene Registry und setzt --db-repository, --java-db-repository und --checks-bundle-repository (Self-Hosting). Die Spiegelung muss laufend aktualisiert werden, sonst veralten die Funde. Außerdem sammelt Trivy anonyme Nutzungsdaten (Hash einer Maschinenkennung, Version, Betriebssystem, nicht identifizierende Scan-Optionen) und prüft über check.trivy.dev auf Updates (Telemetrie). Beides schalten --disable-telemetry und --skip-version-check ab; es sind zwei getrennte Schalter.

Funde priorisieren: eine Entscheidungsregel

Ein Scan liefert Kandidaten, keine Prioritäten. Trivy zeigt Schweregrad, CVSS-Werte, Fixed Version und Status je Fund (JSON-Felder Severity, CVSS, FixedVersion, Status, geprüft mit v0.76.1). Aussagen zu Ausnutzung und Erreichbarkeit fehlen. Sie kommen aus dem Cluster und aus externen Listen: dem KEV-Katalog der CISA für beobachtete Ausnutzung und dem EPSS für die geschätzte Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen. CVSS beschreibt die Schwere, nicht das Risiko im eigenen Betrieb. Unsere Vorgehensregel, in dieser Reihenfolge:

Erreichbar heißt: Service vom Typ LoadBalancer oder NodePort, Route über Ingress oder Gateway, keine einschränkende Network Policy. VEX-Aussagen mit dem Status not_affected (Begründung etwa vulnerable_code_not_in_execute_path) blenden Funde aus; die Option --vex ist experimentell und gilt nur mit belegter Herkunft (VEX).

Grenzen und Abgrenzung

Trivy erkennt bekannte Schwachstellen und Fehlkonfigurationen zum Zeitpunkt des Scans. Es beobachtet kein Laufzeitverhalten, bewertet keine Ausnutzbarkeit und kennt keine unbekannten Schwachstellen. Daneben stehen andere Prüfungen mit anderem Gegenstand:

Das Cluster-Audit bewertet, was ein Scanner nicht sieht, etwa den Restore-Weg und den Upgrade-Pfad. Der Schwachstellenscan als Service arbeitet mit OpenVAS von Greenbone und prüft Systeme aus dem Netz; die Schichten einzelner Images sind nicht sein Gegenstand. Das CVE-Monitoring gleicht das Inventar laufend mit neuen CVE-Meldungen ab und ordnet sie nach Exposition ein.

Der Scanner als Teil der Lieferkette

Im März 2026 wurden Trivy-Artefakte kompromittiert. Am 19.03.2026 erschien ein manipuliertes Release v0.69.4, 76 von 77 Versions-Tags der trivy-action und alle 7 Tags von setup-trivy verwiesen auf Schadcode, am 22.03.2026 folgten manipulierte Docker-Hub-Images (v0.69.5 und v0.69.6). Der Schadcode in den manipulierten Actions las Zugangsdaten aus CI-Runnern aus (Sicherheitshinweis GHSA-69fq-xp46-6x23). Unkritisch waren laut Hinweis unter anderem Images, die per Digest einer unveränderten Version referenziert wurden, und Actions, die auf eine sichere Commit-SHA gepinnt waren (Details zu den Zeiträumen im Hinweis). Daraus folgen vier Regeln für die Einbindung:

• Trivy-Version festschreiben, das Image per Digest referenzieren.
• GitHub Actions auf die vollständige Commit-SHA pinnen, nicht auf ein Tag.
• Release-Signaturen mit cosign prüfen (Befehle stehen im Hinweis).
• Scan-Jobs ohne Deployment-Zugangsdaten ausführen.

Stand und Methodik

Stand 28.10.2026. Grundlage sind die Trivy-Dokumentation und das Repository (Docs, CLI-Referenz, Release v0.76.1), die Dokumentation des Trivy Operators (Chart-Werte aus dem Tag v0.35.0), der Sicherheitshinweis GHSA-69fq-xp46-6x23 sowie die Seiten von CIS, CISA und FIRST. Gegen v0.76.1 selbst geprüft wurden: die Flags von trivy k8s und trivy image, der Exit-Code, die JSON-Felder, das Positionsargument von trivy k8s, die Misconfig-Funde zu fehlenden Requests und Limits und die Ignore-Datei für KSV-0011. Nicht ausgeführt wurden trivy k8s gegen einen Cluster und die Helm-Installation des Operators; hier gelten die Angaben der Dokumentation. Die Priorisierungsregel ist eine Vorgehensregel von WZ-IT, keine Vorgabe von Trivy.

Unser Vorgehen bei WZ-IT

Trivy deckt die Ebene der Images, Manifeste und Cluster-Objekte ab. Im Managed-Kubernetes-Betrieb gehören CVE-Bewertung und Härtung zum Leistungsumfang: Schwachstellen werden eingeordnet, die Exposition bewertet und Maßnahmen risikobasiert umgesetzt. Monitoring erfolgt 24/7, die Reaktion auf P1-Incidents erfolgt entsprechend Service Level. Für die Konfigurationsebene gegen CIS und BSI gibt es das Cluster-Audit, für den Abgleich von Inventar und CVE-Meldungen das CVE-Monitoring. Welcher Umfang zu einem Cluster passt, klärt eine Bestandsaufnahme, wie sie die Übernahme-Checkliste beschreibt.

Weiterführende Guides

• Kubernetes Requests, Limits, ResourceQuota und LimitRange
• Kubernetes-Cluster übernehmen: Audit-Checkliste
• Schwachstellenscan als Service
• CVE-Monitoring
• Kubernetes Support ohne Vertrag für einzelne Aufgaben

Cluster prüfen und danach betreiben lassen? Das Cluster-Audit kostet ab 1.490 € netto einmalig und ist auf den ersten Betriebsmonat anrechenbar. Managed Kubernetes kostet ab 590 € netto je Cluster und Monat inklusive 3 Worker-Nodes, jeder weitere Worker-Node 129,90 €, monatlich kündbar mit 30 Tagen Frist zum Monatsende (Stand Oktober 2026).