Kubernetesund Container Security.
Kubernetes- und Container-Security schützt Anwendungen vom Image bis zum laufenden Pod. Image- und Registry-Scans finden Schwachstellen vor dem Deployment, ein Admission Controller setzt Regeln beim Deployment durch, KSPM prüft die Cluster-Konfiguration, und Sensoren überwachen Container im laufenden Betrieb.
Marktbild: hohe Priorität bei produktivem Kubernetes. Der Markt ist von CNAPP-Anbietern, Kubernetes-Spezialisten und Open-Source-Projekten geprägt. Verglichen werden elf Plattformen mit unterschiedlicher Tiefe bei Posture, Admission und Runtime.
Cluster statt Einzelcontainer.
Die Klasse bewertet Clusterrollen, Workload-Identitäten, Admission Policies, Secrets, Netzwerkregeln, Images und Laufzeitaktivität. Managed Kubernetes reduziert Betriebsaufwand, überträgt aber nicht die Verantwortung für Workloads und Berechtigungen.
Benötigt werden Clusterinventar, Owner, Deployment-Pipelines, Registry-Zugriff und ein klares Verhältnis zwischen Plattformteam, Entwicklung und Security. Policies müssen vor der Blockierung im Audit-Modus geprüft werden.
Vom Image bis zum Pod.
Container-Sicherheit beginnt beim Image. Ein Image bündelt Anwendung, Bibliotheken und Teile eines Betriebssystems; jede dieser Schichten kann bekannte Schwachstellen, eingebettete Secrets oder unsichere Einstellungen enthalten. Scanner zerlegen das Image, erstellen eine Stückliste der Komponenten (SBOM) und gleichen sie mit Schwachstellendatenbanken ab, im Build, im Registry und laufend nach dem Deployment, weil täglich neue Schwachstellen bekannt werden. Das Open-Source-Werkzeug Trivy prüft auf diese Weise Images, Registries, Infrastrukturcode und Kubernetes-Cluster. Signaturen, etwa mit Sigstore Cosign, belegen zusätzlich, dass ein Image aus der eigenen Pipeline stammt und unterwegs nicht verändert wurde.[1,2,3]
Kubernetes-Sicherheit betrifft den Cluster, der diese Images ausführt. Die Control Plane mit ihrem API-Server ist der zentrale Steuerpunkt: Wer dort Rechte hat, kann Workloads starten, Secrets lesen oder Rollen vergeben. Wer was darf, regelt die rollenbasierte Zugriffskontrolle (RBAC) mit Rollen für Personen und Service-Accounts. Kubernetes Security Posture Management (KSPM) prüft Cluster-Konfiguration, Rollen und Workload-Einstellungen gegen Benchmarks wie den CIS Kubernetes Benchmark. Die Pod Security Standards von Kubernetes definieren drei aufeinander aufbauende Stufen: Privileged ohne Einschränkungen, Baseline gegen bekannte Rechteausweitungen und Restricted nach aktuellen Härtungsregeln.[4,5]
Zwischen Image und Cluster steht der Admission Controller. Er fängt jede Anfrage an den API-Server ab, nachdem sie authentisiert und autorisiert ist, aber bevor das Objekt gespeichert wird. Hier lassen sich Regeln durchsetzen: nur signierte Images, keine privilegierten Container, keine Images mit kritischen Schwachstellen. Policy Engines wie das Open-Source-Projekt Kyverno beschreiben solche Regeln als Kubernetes-Ressourcen.[6,7]
Zur Laufzeit kommen zwei Schutzebenen dazu. Netzwerkrichtlinien begrenzen, welche Pods miteinander sprechen dürfen. Ohne Richtlinie ist ein Pod nicht isoliert, und Kubernetes setzt Richtlinien nur durch, wenn das Netzwerk-Plugin sie unterstützt. Sensoren auf den Knoten, häufig auf eBPF-Basis wie beim Open-Source-Projekt Falco, beobachten Prozesse und Systemaufrufe in Containern und erkennen etwa eine Shell in einem Produktionscontainer oder einen Ausbruchsversuch auf den Host. Je nach Produkt meldet der Sensor nur oder blockiert den Prozess. Ergänzend werten Plattformen die Audit-Logs des API-Servers aus.[8,9,10]
Typische Probleme
| Problem | Wie man es löst |
|---|---|
| Verwundbare Basis-Images | Viele Befunde stammen aus Paketen im Basis-Image, die das Team nie bewusst gewählt hat. Lösung: wenige, gepflegte Basis-Images festlegen, regelmässig neu bauen und Empfehlungen für Basis-Image-Wechsel nutzen.[11] |
| Netzwerkrichtlinien ohne Wirkung | Richtlinien werden angelegt, das Plugin setzt sie aber nicht durch, oder es gibt gar keine. Lösung: Plugin mit NetworkPolicy-Unterstützung verwenden, je Namespace eine Standard-Deny-Regel setzen und Verbindungen aus beobachtetem Verkehr ableiten.[8] |
| Admission Controller als Ausfallrisiko | Ist der Webhook nicht erreichbar, blockiert er je nach Einstellung alle Deployments oder lässt alles durch. Lösung: Ausfallverhalten bewusst festlegen, den Controller hochverfügbar betreiben und neue Regeln zuerst im Audit-Modus einführen. |
| Zu weite Rechte im Cluster | Service-Accounts mit Cluster-Admin-Rechten oder automatisch eingebundene Tokens öffnen den Weg zur Control Plane. Lösung: Rollen nach Namespace trennen, Service-Account-Tokens nur bei Bedarf einbinden und Rollen per KSPM regelmässig prüfen.[12] |
| Privilegierte Container | Container laufen als Root oder mit Host-Zugriff, weil es einfacher war. Lösung: Pod Security Standards mindestens auf Baseline, für Anwendungen auf Restricted durchsetzen.[4] |
| Laufzeitalarme ohne Empfänger | Sensoren melden, aber niemand bearbeitet die Alarme. Lösung: Alarme ins SOC leiten und je Namespace einen Verantwortlichen festlegen.[9] |
Auswahlfragen
| Frage | Worauf die Antwort hinweisen sollte |
|---|---|
| Welche Phasen deckt das Produkt ab: Build, Registry, Admission, Posture, Netzwerk, Laufzeit? | Erwartet wird eine klare Zuordnung je Phase und der Hinweis, welche Teile ein offenes Projekt übernimmt. |
| Welche Kubernetes-Distributionen und verwalteten Dienste werden unterstützt? | Die Antwort sollte eine Support-Matrix für verwaltete Dienste, OpenShift und selbst betriebene Cluster nennen. |
| Wie verhält sich der Admission Controller bei Ausfall, und wie werden Regeln eingeführt? | Gute Antworten nennen Audit-Modus, Ausnahmen je Namespace und Hochverfügbarkeit. |
| Wie werden Netzwerkrichtlinien erzeugt und getestet? | Hinweis auf Verkehrsbeobachtung, Simulation vor dem Anwenden und Abhängigkeit vom Netzwerk-Plugin. |
| Wie greift der Laufzeitsensor in den Knoten ein? | Erwartet werden Angaben zu eBPF oder Kernel-Modul, Ressourcenbedarf und gestaffelten Updates. |
| Welche Teile beruhen auf Open Source, und unter welcher Lizenz? | Die Antwort sollte Upstream-Projekte, Lizenz und den Umgang mit Abweichungen zwischen Produkt und Projekt benennen. |
Betrieb und Verantwortung
Das Plattform-Team betreibt Cluster, Admission Controller, Netzwerk-Plugin und Sensoren und setzt Pod-Sicherheitsstufen um. Anwendungsteams beheben Schwachstellen in ihren Images und pflegen die Netzwerkrichtlinien ihrer Namespaces, Security legt Regeln, Ausnahmen und Schwellen fest, und das SOC bearbeitet Laufzeitalarme. Sinnvolle Kennzahlen sind der Anteil der Namespaces mit Standard-Deny-Regel, der Anteil von Pods auf Stufe Restricted, die Zeit bis zur Behebung kritischer Image-Schwachstellen und die Zahl abgelehnter Deployments.
Regulatorischer Bezug
ISO/IEC 27001:2022 adressiert das Thema in Annex A vor allem über 8.8 «Management of technical vulnerabilities», 8.9 «Configuration management» und 8.22 «Segregation of networks». NIS2 verlangt in Art. 21 Abs. 2 unter anderem Sicherheit der Lieferkette sowie Sicherheit bei Erwerb, Entwicklung und Wartung einschliesslich Schwachstellenbehandlung; DORA fordert in Art. 9 Schutz- und Präventionsmassnahmen für IKT-Systeme. Der IT-Grundschutz beschreibt die Anforderungen in den Bausteinen SYS.1.6 «Containerisierung», etwa sichere Images und Container ohne Privilegien, und APP.4.4 «Kubernetes», etwa Separierung der Netze und automatisierte Auditierung der Konfiguration.[13,14,15,16,17,18,12]
Quellen: [1] trivy.dev · [2] anchore.com · [3] kyverno.io · [4] kubernetes.io · [5] cortex-docs.paloaltonetworks.com · [6] kubernetes.io · [7] kyverno.io · [8] kubernetes.io · [9] falco.org · [10] learn.microsoft.com · [11] snyk.io · [12] bsi.bund.de · [13] opensecurityarchitecture.org · [14] eur-lex.europa.eu · [15] eur-lex.europa.eu · [16] nis-2-directive.com · [17] digital-operational-resilience-act.com · [18] bsi.bund.de
Sechzehn Werkzeuge im Vergleich.
Kubernetes- und Container-Sicherheit verteilt sich über den Lebenszyklus: Images werden im Build und im Registry gescannt, ein Admission Controller entscheidet beim Deployment, KSPM prüft die Cluster-Konfiguration, Netzwerkrichtlinien begrenzen den Verkehr zwischen Pods, und Sensoren überwachen Container zur Laufzeit. Drei Produktformen prägen den Markt: Kubernetes-Plattformen, die alle Phasen abdecken, Kubernetes-Module von CNAPP-Anbietern und Werkzeuge, die sich auf Images, SBOM und die Software-Lieferkette konzentrieren. Viele Bausteine sind Open Source: Falco und Kyverno sind CNCF-Projekte mit Status Graduated, Kubescape ist Incubating, Trivy steht unter Apache 2.0, und kommerzielle Produkte wie Red Hat Advanced Cluster Security (Upstream StackRox) und SUSE Security (NeuVector) beruhen auf offenem Code. Netzwerkrichtlinien setzt Kubernetes nur mit einem Netzwerk-Plugin durch, das sie unterstützt; Anbieter wie Tigera mit Calico bauen darauf Segmentierung, Richtlinienstufen und Bedrohungserkennung im Netz auf. Bei den Eigentumsverhältnissen ist vor allem relevant, dass Wiz seit 11.03.2026 zu Google gehört und Palo Alto Networks am 13.02.2025 Cortex Cloud als nächste Version von Prisma Cloud vorgestellt hat; die selbst betriebene Prisma Cloud Compute Edition wird weiter gepflegt (Release 34.05 vom 11.10.2026).
Image-Scan: Image-Scan · Admission: Admission Control · Laufzeit: Laufzeitschutz · KSPM: Kubernetes-Posture/KSPM · Netzwerk: Netzwerkrichtlinien · Registry: Registry-Scan · Open Source: Open Source. ● = auf offizieller Hersteller- oder Projektseite beschrieben, – = nicht belegt (nicht zwingend nicht vorhanden). Auswahl nicht abschliessend, keine Rangliste. Stand: Oktober 2026.
Red Hat Advanced Cluster Security for Kubernetes
Red Hat
Kubernetes-native Plattform für Anwendungen und die Plattform darunter; mit Advanced Cluster Security for Virtualization auch für VMs unter Red Hat OpenShift Virtualization Engine.
Kontinuierlicher Container-Scan über Anbindung an CI/CD-Pipelines und Image-Registries; Richtlinien wirken beim Deployment und zur Laufzeit.
Riskante Workloads werden über Deploy-Time- und Laufzeitrichtlinien blockiert; KSPM härtet die Cluster.
Ein Netzwerkgraph zeigt Verbindungen; daraus lassen sich Netzwerkrichtlinien erzeugen und vor dem Anwenden simulieren.
Automatisierte Compliance-Prüfungen gegen CIS, NIST, PCI und HIPAA; Upstream-Projekt StackRox unter Apache 2.0.
OpenShift-Umgebungen und gemischte Kubernetes-Landschaften, die Sicherheit selbst betreiben wollen.
Deckt Build, Deployment, Laufzeit und Netzwerkrichtlinien in einer Kubernetes-nativen Plattform ab.
Die Hinweise zu Abhängigkeiten in StackRox gelten laut Projektseite für das Red-Hat-Produkt und sind mit dem Upstream-Projekt nicht getestet.
SUSE Security (NeuVector)
SUSE
Container, Hosts und Orchestrierungsplattformen; läuft auf AWS, Azure und Google Cloud und integriert sich mit Rancher und OpenShift.
Schwachstellen-Scan und Admission Control in Build, Test und Deployment sowie Scan laufender Container und Hosts; Registry-Scan unter anderem für Harbor, Amazon ECR und Google GCR.
Erkennt und blockiert Netzwerk-, Zero-Day- und Anwendungsangriffe in Echtzeit; eine Layer-7-Container-Firewall trennt Container- und Pod-Paare.
Admission Control mit Sigstore Cosign und Konfigurationsprüfung von Kubernetes-Ressourcen; Syslog, Webhooks, LDAP und SAML.
Audits nach Docker Bench und CIS Kubernetes Benchmark mit Berichten für PCI DSS, HIPAA und GDPR; Code unter Apache 2.0.
Rancher- und Kubernetes-Umgebungen, auch abgeschottete, die Zero-Trust-Segmentierung zwischen Pods durchsetzen wollen.
Vollständig quelloffen, mit Layer-7-Segmentierung zwischen Pods und Betrieb auch air-gapped.
Die Plattform wird im eigenen Cluster betrieben; Betrieb und Updates liegen beim Kunden.
Aqua Platform (Kubernetes und Container Security)
Aqua Security
Verwaltete und selbst betriebene Kubernetes-Umgebungen sowie Container über den ganzen Lebenszyklus.
Images werden in der Pipeline auf Schwachstellen, Malware und Secrets gescannt; Assurance Policies wirken als Freigabetor vor dem Deployment.
Laufzeitrichtlinien verhindern Drift und erkennen Angriffe; Kubernetes Assurance Policies nutzen OPA mit Rego-Regeln für die Zulassung.
Eine identitätsbasierte Firewall setzt Netzwerkregeln innerhalb und zwischen Clustern durch und arbeitet mit Calico, Weave, Flannel und Contiv.
Prüfung nach CIS Kubernetes Benchmark mit über 100 Checks und täglichen Scans auf Basis des Open-Source-Werkzeugs kube-bench; Betrieb auch air-gapped.
Regulierte Container-Plattformen, die Freigabe, Laufzeit und Netzwerk mit einer Plattform steuern wollen.
Freigabe, Drift Prevention und Segmentierung in einer Plattform, auch ohne Internetverbindung.
Den Scan direkt in Registries beschreiben die Kubernetes- und Container-Seiten nicht; Registries deckt das Open-Source-Werkzeug Trivy ab.
Sysdig Secure (Kubernetes und Container)
Sysdig
Kubernetes-Knoten unter Linux und Windows, Hosts, Registries und Serverless-Container.
Ein Admission Controller prüft Anfragen nach Authentisierung und Autorisierung und blockiert nicht konforme Workloads und verwundbare Images vor dem Deployment.
Laufzeiterkennung auf Basis der Falco-Referenzbibliothek; Posture-Richtlinien sind an CIS und NIST ausgerichtet.
Registry-Scan unter anderem für AWS ECR, Azure ACR, Google Artifact Registry, Harbor, Quay.io und JFrog Artifactory; CLI-Scanner für Pipelines.
SaaS; Sysdig Network Security verfolgt den Ein- und Ausgangsverkehr jedes Pods, das Network Security Policy Tool erzeugt daraus Kubernetes Network Policies.
Kubernetes-Plattformen, die Zulassung, Laufzeit und Schwachstellen in einem Produkt mit Falco-Regeln verbinden wollen.
Laufzeiterkennung auf Basis von Falco, kombiniert mit Admission Control und Registry-Scan.
Die erzeugten Kubernetes Network Policies setzt das Netzwerk-Plugin des Clusters durch; die Netzwerkfunktion beschreibt die Doku in einem eigenen Abschnitt Netzwerk.
Calico (Open Source, Calico Cloud, Calico Enterprise)
Tigera
Netzwerk und Netzwerksicherheit für Kubernetes mit mehreren Data Planes, WireGuard-Verschlüsselung, BGP und VXLAN.
Calico Network Policies steuern Verkehr auf L3/L4 und L7, mit Richtlinienstufen, Deny-Regeln, DNS-Namen und IP-Bereichen.
Netzbasierter Laufzeitschutz: IDS/IPS auf Workload-Ebene blockiert bösartige IPs und Domains anhand von Threat-Intelligence; dazu WAF und DDoS-Erkennung je Workload.
Mikrosegmentierung begrenzt laterale Bewegung, Namespaces lassen sich automatisch isolieren; erhältlich über die Marktplätze von Azure, AWS und Google Cloud.
Compliance-Berichte für PCI DSS, HIPAA, GDPR, SOC 2, NIST und CCPA mit fortlaufender Überwachung.
Cluster, die Netzwerkrichtlinien und Segmentierung zwischen Pods durchsetzen und dokumentieren müssen.
Netzwerkrichtlinien vom offenen Plugin bis zur verwalteten Plattform aus einer Hand.
Image-Scan, Admission Control und Prozessüberwachung im Container beschreibt die Calico-Cloud-Seite nicht; der Schutz setzt im Netz an.
Prisma Cloud Compute Edition
Palo Alto Networks
Kubernetes, OpenShift, ECS, GKE und Tanzu Application Service über Orchestrator-Defender auf jedem Knoten; CIS-Prüfungen für Kubernetes, OpenShift, GKE, EKS und AKS.
Console und Defender laufen in der eigenen Umgebung; die Defender werden als DaemonSet auf jeden Knoten des Clusters verteilt.
Der Laufzeitschutz erkennt etwa Prozesse, die nicht zum ursprünglichen Image gehören, unerwartete Netzwerk-Sockets und Malware im Workload.
Admission-Regeln in Rego (Open Policy Agent) erlauben oder verweigern Pods, wahlweise mit Alarm oder Blockieren.
Registry-Scan unter anderem für Amazon ECR, Azure Container Registry, Google Artifact Registry, Harbor, JFrog Artifactory, Quay und die OpenShift-Registry; Images, Hosts und Funktionen werden laufend auf Schwachstellen geprüft.
Organisationen, die Kubernetes in Umgebungen ohne Internetverbindung betreiben oder ihre Sicherheitsdaten vollständig selbst halten wollen.
Kubernetes-Schutz von der Registry bis zur Laufzeit mit eigener Console, auch ohne Internetverbindung.
Console, Defender und Updates betreibt die Organisation selbst; die Durchsetzung von Netzwerkregeln zwischen Containern (CNNS) ist laut Hersteller abgekündigt, Radar zeigt Verbindungen nur an.
Cortex Cloud (Kubernetes Security)
Palo Alto Networks
Cluster, Namespaces, Knoten und Workloads; CIS Benchmarks für verwaltete und selbst betriebene Kubernetes-Distributionen.
KSPM erkennt Fehlkonfigurationen mit eingebauten und eigenen Regeln und übernimmt Ergebnisse des Schwachstellen-, Malware- und Secrets-Scans.
Der Laufzeitschutz überwacht Cluster-Aktivität auf bösartiges Verhalten, Zero-Day-Angriffe und unautorisierte Änderungen; Reaktion über die Plattform.
Der Admission Controller fängt Anfragen an den API-Server vor dem Speichern ab und erzwingt Zugriffsregeln, Image Assurance und Sicherheitskonfiguration.
Registry-Scan für Amazon ECR, Azure ACR, Google Artifact Registry und OCI Artifact Registry; Richtlinien werden zentral verwaltet.
Organisationen mit Cortex Cloud, die Kubernetes in dieselbe Posture- und SOC-Sicht aufnehmen wollen.
Kubernetes-Posture, Admission Control und Laufzeit hängen an derselben Plattform wie Cloud-Posture und SOC.
Netzwerkrichtlinien zwischen Pods beschreibt die Kubernetes-Doku-Seite nicht.
Wiz (Container und Kubernetes Security)
Wiz (Google)
Container, Images, Registries und verschiedene Kubernetes-Setups.
Images werden mit Wiz Guardrails und Registry-Scan geprüft; laufende Container agentenlos analysiert.
Der Sensor liefert Bedrohungserkennung in Echtzeit; der Wiz Admission Controller blockiert riskante Ressourcen und Images.
Automatisches KSPM mit fortlaufender Überwachung, Compliance-Bewertung sowie eingebauten und eigenen Regeln.
Befunde fliessen in den Wiz Security Graph, der etwa aus dem Internet erreichbare Container sichtbar macht.
Organisationen mit Wiz für Cloud-Posture, die Kubernetes im selben Risikobild bewerten wollen.
Kubernetes-Befunde werden mit Cloud-Konfiguration und Exposition im selben Graph verknüpft.
Netzwerkrichtlinien zwischen Pods sind auf der Container- und Kubernetes-Seite nicht beschrieben.
Microsoft Defender for Containers
Microsoft
Kubernetes-Cluster, Knoten, Workloads, Registries und Images in Multi-Cloud- und On-Prem-Umgebungen.
Agentenlose Schwachstellenprüfung von Registry-Images, laufenden Containern und Knoten mit täglichem Rescan; Befunde werden signiert dem Image zugeordnet.
Sensor und Auswertung der Kubernetes-Audit-Logs erkennen etwa exponierte Dashboards, privilegierte Rollen und sensible Mounts; Abbildung auf MITRE ATT&CK.
Gated Deployment blockiert oder protokolliert Images, die die Schwachstellenrichtlinie verletzen; Azure Policy für Kubernetes kann privilegierte Container verhindern.
Agentenlose Discovery und Posture-Überwachung über Cloud- und Kubernetes-APIs mit Empfehlungen für Control Plane und Data Plane.
AKS-Nutzer und Organisationen mit Defender for Cloud, die Cluster in mehreren Clouds abdecken wollen.
Agentenloser Image-Scan, Laufzeit und Zulassungskontrolle sind im Defender-Portal und in Defender XDR verbunden.
Alarme entstehen erst für Aktionen nach der Aktivierung; die unterstützten Kubernetes-Plattformen regelt eine separate Support-Matrix.
Snyk Container
Snyk
Container-Images einschliesslich Open-Source-Paketen in Basis-Images und Dockerfile-Befehlen.
Scan in CI/CD-Pipelines während Build und Test sowie in Pull Requests; Befunde verweisen auf die betroffenen Dockerfile-Befehle.
Empfiehlt alternative Basis-Images und aktualisiert sie auf Wunsch automatisch, um Schwachstellen zu beheben.
Registries wie Docker Hub, Amazon ECR, Azure ACR, Google GCR, JFrog Artifactory, VMware Harbor und Red Hat Quay.
Überwachung nach dem Deployment erkennt neue und geänderte Workloads in Kubernetes-Clustern und meldet unsichere Einstellungen; Laufzeitschutz über eine Partnerschaft mit Sysdig.
Entwicklungsteams, die Schwachstellen in Images dort beheben wollen, wo sie entstehen.
Behebung im Entwicklerablauf mit konkreten Empfehlungen für Basis-Images.
Admission Control ist auf der Produktseite nicht genannt, und Laufzeitschutz kommt über einen Partner.
Anchore Enterprise
Anchore
SBOM bei jedem Commit, Build und Deployment mit Abhängigkeiten, Dateimetadaten und Lizenzen in den Formaten Syft, CycloneDX und SPDX.
Laufender Scan auf Schwachstellen, Secrets und Malware, auch für neue Schwachstellen in bestehenden SBOMs ohne Zugriff auf das ursprüngliche Artefakt.
Priorisierung nach CVSS, EPSS und CISA KEV; Richtlinienpakete für NIST, FedRAMP und DISA; eigene Regeln als versionierbares JSON.
Integrationen mit Amazon ECR, Azure ACR, Google GCR und Harbor mit Überwachung von Repositories auf neue Images; Integration als Kubernetes Admission Controller.
Laufzeitinventar der laufenden Images in EKS, ECS, AKS, GKE und OpenShift; Installation per Helm oder Docker Compose, auch air-gapped.
Organisationen mit SBOM- und Nachweispflichten in der Software-Lieferkette, etwa im öffentlichen Sektor.
SBOM-zentrierte Prüfung, die neue Schwachstellen auch in älteren Builds nachträglich findet.
Zur Laufzeit liefert Anchore ein Inventar laufender Images, keine Angriffserkennung im Container.
JFrog Xray
JFrog
Repositories, Build-Pakete und Container-Images über den Entwicklungszyklus.
Tiefer, rekursiver Scan analysiert alle Schichten eines Images und identifiziert jede Komponente.
Eigene Richtlinien blockieren Pakete nach Risikofaktoren wie Versionsalter, Anzahl Mitwirkender und End-of-Life-Status.
Artefakte werden beim Hochladen in Artifactory geprüft; Xray ist Teil der Abonnements Pro X, Enterprise X und Enterprise+.
SaaS mit 99,99 % Verfügbarkeitszusage oder Self-Hosted in Hochverfügbarkeits-Clustern.
Organisationen, die Artifactory als zentrales Registry nutzen und Images vor der Verteilung prüfen wollen.
Prüfung direkt im zentralen Artefakt-Repository, bevor Images verteilt werden.
Xray setzt Artifactory voraus; Kubernetes-Laufzeit und Admission Control beschreibt die Produktseite nicht.
Kubescape
Kubescape (CNCF, von ARMO initiiert)
Open-Source-Plattform für Kubernetes mit Konfigurationsscan, Schwachstellenbewertung, Richtliniendurchsetzung und Laufzeiterkennung.
Prüft gegen CIS Benchmarks, NSA-CISA, MITRE ATT&CK, SOC 2 und weitere Frameworks; für den Image-Scan nutzt es Grype.
Laufzeitüberwachung erkennt verdächtige Aktivität in Clustern; die eBPF-Komponente ist Inspektor Gadget.
Prüft Vorhandensein und Korrektheit von Netzwerkrichtlinien und Seccomp-Profilen; die Doku beschreibt das Erzeugen von Netzwerkrichtlinien.
CNCF-Projekt im Status Incubating, ursprünglich von ARMO entwickelt.
Plattform-Teams, die Kubernetes-Posture und Laufzeit lizenzkostenfrei und nachvollziehbar prüfen wollen.
Posture, Image-Scan, Netzwerkrichtlinien und Laufzeit in einem offenen Projekt.
Admission Control beschreibt die Projektseite nicht; Betrieb und Alarmverarbeitung liegen beim Anwender.
Trivy
Aqua Security (Open Source)
Container-Images, Dateisysteme, Git-Repositories, Kubernetes-Cluster und Registries.
Scanner für Schwachstellen, Fehlkonfigurationen in Infrastrukturcode, Secrets, SBOM und Lizenzen.
Findet bekannte Schwachstellen (CVEs) und Fehlkonfigurationen, bevor Images oder Manifeste ausgerollt werden.
In Go geschrieben und als einzelnes Werkzeug in Pipelines und Entwicklerumgebungen einsetzbar; Partner-Ökosystem über Partner Connect.
Open Source von Aqua Security unter Apache 2.0; eine Premium-Variante bietet Aqua in seiner Plattform an.
Teams, die einen breiten, lizenzkostenfreien Scanner für Images und Kubernetes in CI/CD einsetzen wollen.
Ein Werkzeug für Images, Registries, Infrastrukturcode und Kubernetes-Cluster.
Trivy prüft und meldet; Durchsetzung beim Deployment und Laufzeitschutz übernehmen andere Komponenten.
Kyverno
Kyverno (CNCF)
Policy Engine für Kubernetes, inzwischen auch für andere JSON-Daten wie Terraform und Cloud-Ressourcen.
Richtlinien in YAML und CEL, verwaltet als Kubernetes-Ressourcen; Durchsetzung als Admission Controller, per CLI und zur Laufzeit.
Validiert, verändert, erzeugt oder bereinigt beliebige Kubernetes-Ressourcen.
Prüft Signaturen und Metadaten von Images mit Sigstore Cosign und Notary für die Lieferkette.
CNCF-Projekt mit Status Graduated; Ergebnisse im Format OpenReport, Ausnahmen und Testwerkzeuge für Richtlinien.
Plattform-Teams, die Leitplanken wie Pod Security, Pflicht-Labels oder signierte Images ohne eigene Programmiersprache durchsetzen wollen.
Richtlinien als Kubernetes-Ressourcen, die Teams ohne zusätzliche Sprache lesen und pflegen können.
Kyverno setzt Richtlinien durch; Schwachstellen-Scan und Angriffserkennung gehören zu anderen Werkzeugen.
Falco
Falco (CNCF, Open Source)
Laufzeitsicherheit für Hosts, Container, Kubernetes und Cloud-Umgebungen.
eBPF überwacht Systemaktivität auf Kernel-Ebene; Plugins erweitern die Quellen um Dienste wie AWS CloudTrail, GitHub und Okta.
Mitgelieferte, anpassbare Regeln erkennen auffälliges Verhalten in Containern und auf Hosts.
Alarme im JSON-Format lassen sich an über 50 Drittsysteme wie SIEMs weiterleiten und in Reaktionsabläufe einbinden.
CNCF-Projekt mit Status Graduated; Regelpflege und Alarmverarbeitung liegen beim Anwender.
Kubernetes-Plattformen, die Laufzeiterkennung mit offenen Regeln in bestehende SOC-Abläufe einbinden wollen.
Offenes Regelwerk für Laufzeiterkennung, das etwa Sysdig Secure als Referenzbibliothek nutzt.
Falco erkennt und meldet; Image-Scan, Admission Control und Blockieren übernehmen andere Komponenten.
Weitere Anbieter
Kurz eingeordnet, ausserhalb der Vergleichsmatrix.
- Docker Scout: Image-Analyse mit SBOM und Richtlinien belegt, Admission Control, Laufzeit und KSPM auf der Doku-Startseite nicht beschrieben
- GitLab Container Scanning: Pipeline-Funktion einer DevSecOps-Plattform
- Clair (Quay): Open-Source-Image-Scanner
- RapidFort: Schwerpunkt Härtung und Verkleinerung von Images
- kube-bench (Aqua, Open Source): prüft Cluster gegen den CIS Kubernetes Benchmark; in Aqua Platform integriert
- OPA Gatekeeper, Kubewarden, Cilium/Tetragon: Open-Source-Bausteine für Admission Control, Netzwerk und Laufzeit
- CrowdStrike, SentinelOne, Check Point: Kubernetes-Funktionen in deren Cloud-Plattformen; hier nicht separat geprüft, siehe CWPP
- Ein sicher gescanntes Image läuft mit überprivilegiertem Service Account.
- Admission Policies werden ohne Ausnahme- und Rollbackweg aktiviert.
- Cluster, Namespaces oder kurzlebige Workloads fehlen im Inventar.
Teste einen privilegierten Pod, eine riskante ClusterRole, ein offenes Netzwerksegment, ein verwundbares Image und einen verdächtigen Laufzeitprozess. Jeder Befund muss auf Namespace, Workload und Owner zurückführbar sein.
Security Tool Navigator · Gebiet 06
Im Gebiet Cloud und Infrastructure Security einordnen.
Diese Werkzeugklasse gehört zum Gebiet Cloud und Infrastructure Security. Der Gebietshub zeigt, wie die Werkzeugklassen zusammenwirken, wo sie sich abgrenzen und welche Fragen CIO und CISO jeweils klären.