Trivy Kubernetes Scanner 2026: Cluster prüfen in der Praxis

Robin Werner, Head of Azure bei Pexon Consulting | 8 Min. Lesezeit | 29.08.2026

TL;DR

Trivy Kubernetes ist der Open-Source-Scanner von Aqua Security für CVEs, Fehlkonfigurationen, Secrets und SBOM in Images und laufenden Clustern. Pexon Consulting (ISO 27001, Kubestronauts im Team) setzt Trivy in Audits und CI ein und priorisiert die Funde für NIS2-taugliche Nachweise. Mit Trivy v0.74.0 (Stand 14.08.2026) und 37.690 GitHub-Stars ist der Einstieg in Minuten erledigt, der Produktivnutzen hängt an der Auswertung.

Das Problem: Image-Scan in der CI ist nicht Cluster-Sicherheit

Viele Teams scannen jedes Container Image in der Pipeline und haken Security ab. Im Cluster liegen trotzdem ungepatchte Base-Images, zu weite RBAC-Rechte und Secrets in ConfigMaps.

Das sind zwei verschiedene Fragen. Die Pipeline beantwortet: „Ist dieses Artefakt gerade sauber?“ Der Cluster beantwortet: „Was läuft heute wirklich und wie ist es konfiguriert?“ Trivy kann beides. Die meisten Installationen nutzen nur die erste Hälfte.

Wir sehen das regelmäßig in Kubernetes-Audits: Trivy oder ein vergleichbarer Scanner läuft in GitHub Actions, der Produktions-Namespace wurde seit Monaten nicht gegen CIS oder NSA-Hardening geprüft. Genau diese Lücke nutzen Prüfer und Kunden-Security-Fragebögen.

Was Trivy Kubernetes konkret kann

Trivy ist kein reiner Image-Scanner. Targets sind Container Images, Dateisysteme, Git-Repositories, VM-Images und Kubernetes. Scanner decken CVEs, IaC-Fehlkonfigurationen, Secrets, Lizenzen und SBOM ab.

Für Kubernetes gibt es zwei sinnvolle Betriebsarten:

Unsere klare Empfehlung für den ersten Schritt: CLI-Cluster-Scan mit Summary. Erst wenn jemand die Reports wöchentlich lesen und Tickets schneiden soll, lohnt der Operator. Der Operator ohne Owner ist nur Lärm in etcd.

Frische zum Tool: Release v0.74.0 vom 14.08.2026, Repository aquasecurity/trivy mit 37.690 Stars (Abruf 29.08.2026). Offizielle Doku und Releases liegen auf trivy.dev und GitHub.

Praxis: Cluster-Scan mit der Trivy CLI

Voraussetzung: gültiges KUBECONFIG, Leserechte im Ziel-Cluster, Trivy installiert.

# Installation (Linux/macOS, aktuelle Stable ziehen)
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh 
  | sh -s -- -b /usr/local/bin

trivy version
# erwartet: Version 0.74.x oder neuer

# Cluster-Übersicht: Workloads, Infra, RBAC verdichtet
trivy k8s --report summary cluster

# Nur Production, nur Critical/High
trivy k8s -n production --severity CRITICAL,HIGH --report all cluster

Der Summary-Report gliedert typischerweise Workload Assessment, Infra Assessment und RBAC Assessment. Critical/High in Images sind der Einstieg. Danach die Fehlkonfigurationen, die ohne CVE trotzdem ausnutzbar sind: privileged Pods, hostNetwork, fehlende Network Policies.

Für Compliance-Reports (CIS, NSA/CISA, Pod Security Standards) reicht ein Flag:

# CIS Kubernetes Benchmark (eingebautes Profil)
trivy k8s cluster --compliance k8s-cis-1.23 --report summary

# NSA/CISA Hardening Guidance
trivy k8s cluster --compliance k8s-nsa-1.0 --report summary

Das ersetzt kube-bench nicht in jedem Spezialfall, aber für die meisten Mittelstands-Cluster reicht ein Trivy-Compliance-Lauf als erste Ampel. Wir raten davon ab, den Rohreport ungefiltert an den CISO zu schicken. Ohne Priorisierung nach Ausnutzbarkeit und Business-Impact entsteht nur Alarmmüdigkeit.

In der CI hängt Trivy oft an GitHub Actions oder Azure DevOps: Image bauen, trivy image mit Exit-Code bei CRITICAL, Artifact als SARIF an die PR. Das ist richtig für die Supply Chain. Es ersetzt trotzdem nicht den Blick auf den laufenden Cluster, in dem Helm-Releases, Sidecars und Debug-Pods landen, die nie durch dieselbe Pipeline gingen.

CIS-Ampel und was danach passieren muss

Ein grüner Image-Scan gestern sagt nichts über den Cluster heute. Neue CVEs erscheinen laufend; Workloads, die vor sechs Monaten clean waren, sind es oft nicht mehr.

Deshalb gehört zu jedem Trivy Kubernetes Lauf eine kurze Auswertungslogik:

1. Critical/High mit Fix-Version und Owner-Namespace
2. Misconfigs mit direktem Exploit-Pfad (privileged, hostPath, cluster-admin Bindings)
3. Secrets-Funde in Manifesten und ConfigMaps
4. CIS-Fails an Control Plane und Nodes, die Prüfer zuerst fragen

Was wir in Projekten sehen: Teams mit Trivy in der CI brauchen oft 1 bis 2 Tage, bis der erste vollständige Cluster-Report inklusive Prioritätenliste steht. Der Engpass ist selten das Tool. Der Engpass ist, wer die Top-20-Funde verbindlich schließt.

Wer den Scan nicht selbst betreiben will, braucht denselben Output als Dienst: priorisierte Ampel, Owner-Zuordnung, Übergabe in 30 Minuten. Bei Pexon Consulting liegt dieser Einstieg als Angriffsflächen-Check bei 850 EUR netto für einen Cluster, Befund in 2 bis 5 Werktagen. Dahinter stecken Trivy und verwandte Checks, nicht eine ungefilterte 200-Zeilen-Rohliste.

Trivy Operator: Dauerbetrieb nur mit Betriebskonzept

Der Trivy Operator installiert sich per Helm und schreibt Security-Reports als Custom Resources. Neu deployte Workloads werden nachgezogen, veraltete Reports über Owner-Referenzen aufgeräumt.

helm repo add aqua https://aquasecurity.github.io/trivy-operator
helm repo update

helm install trivy-operator aqua/trivy-operator 
  --namespace trivy-system 
  --create-namespace 
  --set="trivy.ignoreUnfixed=true"

Das ist technisch sauber. Organisatorisch scheitert es, wenn niemand die CRDs in Tickets oder ein Dashboard überführt. Unsere Empfehlung: Operator erst nach dem ersten manuellen Cluster-Scan und einer festgelegten Triage-Runde (zum Beispiel wöchentlich 30 Minuten Platform + App-Owner).

Vergleich kurz und meinungsstark:

Für regulierte Umgebungen (Banking, Energie, KRITIS-nahe SaaS) reicht „wir scannen Images“ als Antwort auf NIS2-Fragen selten. Prüfer wollen wiederholbare Nachweise zum Betrieb, nicht nur zur Build-Pipeline. Trivy liefert Rohdaten. Den Nachweis baut ihr Prozess oder ein Dienstleister.

Worauf Sie bei der Einführung achten sollten

1. Scope festlegen: Ein Namespace oder der ganze Cluster? „Alles“ ohne Priorisierung erzeugt 500 Findings und null Fixes.
2. Severity-Policy: Nur CRITICAL/HIGH in Tickets, Rest als Backlog. Sonst gewinnt niemand.
3. Secrets-Funde sofort behandeln: Das sind keine „später“-Themen.
4. SBOM mitdenken: Trivy erzeugt SBOMs; für Lieferketten-Fragen (Kunden, Versicherer) ist das Gold wert.
5. Nicht mit Pen-Test verwechseln: Trivy findet bekannte Schwächen und Fehlkonfigurationen. Einen gezielten Angriffstest ersetzt es nicht.

Pexon Consulting hat rund 80 Mitarbeiter in Deutschland, ist Microsoft Partner und ISO 27001 zertifiziert. Im Kubernetes-Cluster arbeiten Kubestronauts am Day-2-Betrieb und an Security-Nachweisen. Wir verkaufen kein Trivy-Logo. Wir verkaufen die ausgewertete Lage und den nächsten Fix-Schritt.

Externe Einordnung: Offizielle Projektseite und Scanner-Abdeckung stehen bei Aqua Security unter trivy.dev.

Häufig gestellte Fragen

Was kostet Trivy Kubernetes?

Trivy selbst ist Apache-2.0 und kostenlos. Kosten entstehen bei Integration, Triage und Nachweis. Ein priorisierter Cluster-Check bei Pexon Consulting startet als Angriffsflächen-Check ab 850 EUR netto für einen Cluster.

Trivy vs kube-bench: was brauche ich?

kube-bench fokussiert CIS-Node- und Control-Plane-Checks. Trivy deckt Images, Secrets, Misconfigs und Compliance-Profile in einem Werkzeug ab. Für die meisten Teams reicht Trivy als Einstieg; Spezialfälle an Nodes können weiterhin kube-bench nutzen.

Reicht Trivy in der CI für NIS2?

Kommt darauf an, aber meist nein. NIS2 und ähnliche Pflichten zielen auf nachweisbaren Betrieb, nicht nur auf den Build. Cluster-Scans, Patch-Nachweise und klare Verantwortlichkeiten gehören dazu.

Trivy Operator oder nur CLI?

CLI für Audits und CI-Jobs. Operator, wenn Security dauerhaft im Cluster sichtbar sein soll und jemand die Reports betreibt. Ohne Owner lieber CLI bleiben.

Wie lange dauert der erste sinnvolle Cluster-Scan?

Technisch oft unter einer Stunde inklusive Installation. Mit Priorisierung und Übergabe an App-Owner rechnen Sie realistisch 1 bis 2 Werktage. Genau dieses Fenster deckt unser Security-Angebot ab.

Nächster Schritt

Wenn der Scanner schon läuft und der Report Sie überfordert, oder wenn noch gar kein Cluster-weiter Lauf existiert: Security-Lage in unter 30 Minuten einordnen lassen.

Verwandte Themen