Cloud WorkloadProtection.
Cloud Workload Protection schützt die Rechenlast selbst: virtuelle Maschinen, Container und Serverless-Funktionen in der Cloud und im eigenen Rechenzentrum. Ein Agent im Workload erkennt und blockiert Angriffe während des Betriebs; ein Scan ohne Agent prüft Disk-Snapshots und Images auf Schwachstellen, Secrets und Malware.
Marktbild: hohe Priorität für produktive Cloud-Workloads. CWPP wird überwiegend als Modul einer CNAPP angeboten. Der Markt ist breit, aber funktional uneinheitlich zwischen agentenloser Sicht, hostbasiertem Sensor und echtem Runtime Enforcement. Dieser Vergleich umfasst elf Plattformen.
Laufzeit schützen.
CWPP prüft Images und Workloads, erkennt verdächtige Prozesse, Netzwerkverbindungen und Dateiaktivität und kann zur Laufzeit reagieren. Agentenlose Scans schaffen schnelle Sicht, liefern aber nicht automatisch dieselbe Laufzeitkontrolle wie ein Sensor im Workload.
Erforderlich sind Cloud-Konten, Workload-Inventar, Images, Orchestrator-Kontext und ein definiertes Betriebsmodell für Sensoren und Reaktionsrechte. Kurzlebige Workloads verlangen eine zeitnahe Telemetrie.
Was läuft, und wer greift ein?
Ein Workload ist die Rechenlast, auf der eine Anwendung läuft: eine virtuelle Maschine, ein Container, ein Kubernetes-Knoten oder eine Serverless-Funktion. Cloud Workload Protection (CWPP) schützt diese Einheiten über ihren ganzen Lebenszyklus, vom Image im Registry über den Start bis zum Betrieb, in Public Clouds und häufig auch im eigenen Rechenzentrum. Die Aufgaben lassen sich in zwei Gruppen teilen: Risiken finden, bevor sie ausgenutzt werden (Schwachstellen, Secrets, Malware, unsichere Konfiguration im Betriebssystem), und Angriffe erkennen oder stoppen, während der Workload läuft. CSPM prüft die Cloud-Dienste von aussen über ihre Schnittstellen, CWPP setzt im Betriebssystem und im Container an. Einige Server-Agenten schirmen bekannte Schwachstellen zusätzlich per Intrusion Prevention ab, bis ein Patch eingespielt ist.[1,2,3]
Für das Finden gibt es den agentenlosen Weg. Die Plattform erstellt über die Cloud-Schnittstelle einen Snapshot der Disk, analysiert Dateisystem und installierte Pakete in einer isolierten Umgebung und löscht die Kopie danach. Der Workload merkt davon nichts, und die Abdeckung ist sofort breit. Container-Images werden analog direkt im Registry geprüft, bevor sie überhaupt laufen. Der Preis: Ein Snapshot ist eine Momentaufnahme, er sieht weder laufende Prozesse noch Netzverbindungen.[4,5]
Für das Erkennen und Eingreifen braucht es einen Agenten oder Sensor im Workload. Er beobachtet Systemaufrufe, Prozessstarts, Dateizugriffe und Verbindungen und vergleicht sie mit Regeln und Verhaltensmodellen. Je nach Produkt meldet er nur, blockiert einzelne Aktionen, beendet Prozesse oder isoliert den Workload. Unter Linux setzen viele Sensoren auf eBPF: Kleine, vom Kernel geprüfte Programme hängen sich an Ereignisse, ohne dass ein eigenes Kernel-Modul geladen wird, das bei jeder neuen Kernel-Version angepasst werden müsste. Das Open-Source-Projekt Falco arbeitet nach diesem Prinzip mit offenen, anpassbaren Regeln.[6,7]
Bei Kubernetes kommen zwei Quellen dazu: die Audit-Logs der Control Plane, die ohne Agent ausgewertet werden können, und ein Admission Controller, der den Start nicht konformer Images verhindert. Serverless-Funktionen und Serverless-Container wie Fargate brauchen eigene Varianten, weil dort kein Host-Agent installiert werden kann. Viele Plattformen kombinieren beides: agentenlos für die Breite, Sensor für kritische Systeme.[5,8]
| Ansatz | Was er sieht | Was er leistet |
|---|---|---|
| Image-Scan im Registry | Pakete und Secrets im Image vor dem Start | Verhindert, dass bekannte Schwachstellen ausgerollt werden |
| Agentenloser Snapshot-Scan | Dateisystem und Software einer Disk zu einem Zeitpunkt | Breite Abdeckung ohne Eingriff in den Workload |
| Agent oder Sensor | Prozesse, Dateien, Netzverbindungen zur Laufzeit | Erkennt Angriffe und kann sie blockieren oder eindämmen |
| Kubernetes-Audit-Logs | Aktionen an der Cluster-API | Erkennt riskante Änderungen wie privilegierte Rollen |
| Serverless-Agent | Funktion oder Serverless-Container von innen | Laufzeiterkennung dort, wo kein Host zugänglich ist |
Typische Probleme
| Problem | Wie man es löst |
|---|---|
| Agenten fehlen auf kurzlebigen Workloads | Autoscaling-Gruppen und Container starten und verschwinden, bevor jemand einen Agenten installiert. Lösung: Agenten ins Basis-Image oder als DaemonSet ausrollen und die Abdeckung mit einem agentenlosen Scan gegenprüfen. |
| Snapshot-Befunde ohne Laufzeitkontext | Hunderte Schwachstellen in installierten Paketen, von denen nur wenige geladen oder erreichbar sind. Lösung: nach Exposition, Ausnutzbarkeit und tatsächlich laufendem Code priorisieren. |
| Kernel-Abhängigkeit des Agenten | Kernel-Module können bei neuen Kernel-Versionen brechen, und ein fehlerhaftes Update eines verbreiteten Sensors legte am 19.07.2024 weltweit Windows-Systeme lahm. Lösung: eBPF-basierte Sensoren bevorzugen, wo verfügbar, und gestaffelte Verteilung von Agenten- und Inhalts-Updates verlangen.[6,9] |
| Blockieren in Produktion | Eine zu strenge Regel stoppt einen legitimen Prozess. Lösung: neue Regeln zuerst im Erkennungsmodus betreiben, Ausnahmen je Workload dokumentieren und erst danach auf Blockieren umstellen. |
| Lücke vor der Aktivierung | Erkennung wirkt erst ab dem Zeitpunkt, an dem der Schutz aktiv ist. Lösung: neue Konten und Cluster automatisch einbinden und Aktivierung als Teil der Bereitstellung behandeln.[5] |
| Getrennte Werkzeuge für Rechenzentrum und Cloud | Server im eigenen Rechenzentrum und Cloud-Workloads laufen in zwei Konsolen mit unterschiedlichen Regeln. Lösung: bei der Auswahl die Abdeckung beider Welten prüfen und Richtlinien einheitlich führen. |
Auswahlfragen
| Frage | Worauf die Antwort hinweisen sollte |
|---|---|
| Welche Workload-Typen deckt das Produkt ab, und mit welcher Methode? | Erwartet wird eine Liste für VMs, Container, Kubernetes, Serverless und On-Prem-Server, jeweils mit Agent, agentenlos oder beidem. |
| Was tut der Agent bei einem Angriff selbständig? | Die Antwort sollte zwischen Melden, Blockieren, Prozess beenden und Isolieren unterscheiden und sagen, was konfigurierbar ist. |
| Wie wird der Agent technisch eingebunden, und wie werden Updates verteilt? | Hinweis auf eBPF oder Kernel-Modul, unterstützte Kernel-Versionen sowie gestaffelte Updates mit Rücknahme. |
| Wie werden Schwachstellen priorisiert? | Gute Antworten verknüpfen Exposition, Ausnutzbarkeit und Laufzeitdaten, statt nur nach CVSS zu sortieren. |
| Wie ist der Schutz in Deployment und Pipeline verankert? | Erwartet werden Registry-Scan, Admission Control und Freigaberegeln für Images. |
| Welche Daten verlassen den Workload, und wo werden sie gespeichert? | Die Antwort sollte Telemetrieumfang, Region, Aufbewahrung und Zugriff des Herstellers benennen. |
Betrieb und Verantwortung
Das Plattform- oder Cloud-Team verantwortet Ausrollung und Abdeckung der Agenten, Security Engineering pflegt Regeln und Ausnahmen, das SOC oder ein MDR-Dienst bearbeitet Laufzeitalarme. Für Schwachstellen in Images und Paketen sind die Anwendungsteams zuständig, weil nur sie Images neu bauen können. Sinnvolle Kennzahlen sind die Agentenabdeckung je Workload-Typ, die Zeit bis zur Eindämmung eines Laufzeitalarms, die Zeit bis zur Behebung kritischer Schwachstellen und der Anteil blockierter Deployments.
Regulatorischer Bezug
ISO/IEC 27001:2022 adressiert das Thema in Annex A vor allem über 8.7 «Protection against malware», 8.8 «Management of technical vulnerabilities» und 8.16 «Monitoring activities». NIS2 verlangt in Art. 21 Abs. 2 unter anderem die Bewältigung von Sicherheitsvorfällen und die Behandlung von Schwachstellen; DORA fordert in Art. 9 Schutz- und Präventionsmassnahmen und in Art. 10 Mechanismen zur Erkennung anomaler Aktivitäten. Der IT-Grundschutz beschreibt hostbasierte Angriffserkennung in SYS.1.1 «Allgemeiner Server» (A27) und SYS.1.6 «Containerisierung» (A24).[10,11,12,13,14,15,16,17]
Quellen: [1] docs.trendmicro.com · [2] learn.microsoft.com · [3] learn.microsoft.com · [4] learn.microsoft.com · [5] learn.microsoft.com · [6] bitdefender.com · [7] falco.org · [8] docs.sysdig.com · [9] cisa.gov · [10] opensecurityarchitecture.org · [11] eur-lex.europa.eu · [12] eur-lex.europa.eu · [13] nis-2-directive.com · [14] digital-operational-resilience-act.com · [15] digital-operational-resilience-act.com · [16] bsi.bund.de · [17] bsi.bund.de
Dreizehn Werkzeuge im Vergleich.
Cloud Workload Protection schützt die Rechenlast selbst: virtuelle Maschinen, Container und Serverless-Funktionen in Public Clouds und bei vielen Produkten auch Server im eigenen Rechenzentrum. Zwei technische Wege prägen die Produkte: ein Agent oder Sensor im Workload, der Prozesse, Dateien und Netzverbindungen zur Laufzeit überwacht und Angriffe blockiert, und der agentenlose Scan, der Disk-Snapshots oder Images auf Schwachstellen, Secrets und Malware prüft. Anbieter aus dem Endpunktschutz erweitern ihre Server-Agenten auf Cloud-Workloads und Container, CNAPP-Anbieter ergänzen ihren agentenlosen Scan um eigene Laufzeitsensoren. Viele Linux-Agenten nutzen eBPF, um ohne eigene Kernel-Module auszukommen; das Open-Source-Projekt Falco (CNCF Graduated, Apache 2.0) setzt dieselbe Technik für regelbasierte Laufzeiterkennung ein. Eigentum und Namen haben sich verändert: Wiz gehört seit 11.03.2026 zu Google, und das Unternehmensgeschäft von Trend Micro firmiert seit 23.03.2026 als TrendAI. Palo Alto Networks hat am 13.02.2025 Cortex Cloud als nächste Version von Prisma Cloud vorgestellt; die selbst betriebene Prisma Cloud Compute Edition wird weiter gepflegt (Release 34.05 vom 11.10.2026).
VMs: VMs · Container: Container · Serverless: Serverless · Agentenlos: agentenloser Scan · Laufzeit: Laufzeitschutz · Schwachstellen: Schwachstellen · On-Prem: On-Prem-Server. ● = auf offizieller Hersteller- oder Projektseite beschrieben, – = nicht belegt (nicht zwingend nicht vorhanden). Auswahl nicht abschliessend, keine Rangliste. Stand: Oktober 2026.
Microsoft Defender for Cloud (Defender for Servers und Defender for Containers)
Microsoft
Windows- und Linux-Maschinen in Azure, AWS, Google Cloud und on-premises; Defender for Containers schützt Cluster, Knoten, Workloads, Registries und Images, die CWPP-Funktion nennt auch Serverless-Funktionen.
Plan 1 nutzt die EDR-Funktionen von Defender for Endpoint; Plan 2 ergänzt agentenlosen Scan auf Schwachstellen, Secrets und Malware sowie File Integrity Monitoring.
Für Container kombiniert der Dienst einen Sensor mit agentenloser Auswertung der Kubernetes-Audit-Logs; Alarme sind auf MITRE ATT&CK für Container abgebildet.
Registry-Images in ACR, ECR, Google Artifact Registry und weiteren Registries werden agentenlos auf Schwachstellen geprüft; ein Admission Controller kann Deployments mit verletzter Richtlinie blockieren.
Aktivierung je Abonnement; Just-in-Time-VM-Zugriff ist für Azure- und AWS-Maschinen verfügbar, einige Funktionen setzen eine Anbindung über Azure Arc voraus.
Organisationen mit Microsoft-Sicherheitsstack, die Server und Container in mehreren Clouds und im eigenen Rechenzentrum aus einem Portal schützen wollen.
Agentenbasierter EDR-Schutz und agentenloser Scan laufen im selben Dienst und werden gemeinsam angezeigt.
Agentenloser Scan, File Integrity Monitoring und Just-in-Time-Zugriff gibt es nur in Plan 2; Alarme für Container entstehen erst für Aktionen nach der Aktivierung.
Falcon Cloud Security (Cloud Workload Protection)
CrowdStrike
VMs und Container unter Windows und Linux sowie Workloads über Cloud-Konten und Kubernetes-Cluster hinweg.
Ein Sensor im Workload erkennt und beantwortet Angriffe in Echtzeit; dazu kommt agentenlose Sicht und Prüfung über die Cloud-Dienste.
Laufzeitverhalten wird über VMs und Container hinweg überwacht; Schwachstellen werden mit CrowdStrike-Angreiferinformationen priorisiert.
Agentenloser Scan von Container-Images in Registries und Pipelines.
Cloud-Dienst der Falcon-Plattform, die Workload-, Endpunkt- und Identitätssignale gemeinsam auswertet.
Organisationen mit Falcon-Endpunktschutz, die Cloud-Server und Container mit demselben Sensor und SOC abdecken wollen.
Derselbe Sensor und dieselbe Erkennungslogik wie am Endpunkt, ergänzt um Cloud-Kontext.
Die CWPP-Seite nennt weder Serverless-Funktionen noch Server im eigenen Rechenzentrum.
Singularity Cloud Workload Security
SentinelOne
Server, VMs, Container, Container-as-a-Service, Serverless und Kubernetes in AWS, Azure, Google Cloud und Private Cloud.
Leichtgewichtige Agenten auf eBPF-Basis, die laut Hersteller die Abhängigkeit vom Kernel und das Risiko für die Produktion senken.
Ransomware, Kryptomining, dateilose Angriffe, Container-Drift und laterale Bewegung werden in Echtzeit erkannt und automatisch eingedämmt.
Telemetrie fliesst in den Singularity Data Lake und wird dort mit Endpunkt-, Identitäts- und Drittdaten korreliert; Abfragen in natürlicher Sprache über Purple AI.
Storylines zeichnen Angriffsketten nach und unterstützen die Untersuchung.
Organisationen, die Cloud-Workloads mit derselben EDR-Logik wie Endpunkte schützen und mit Singularity Cloud Native Security für die Posture kombinieren.
Laufzeitschutz mit automatischer Eindämmung für Server, Container und Serverless aus einem Agenten.
Die Produktseite beschreibt Schwachstellenmanagement nicht als Funktion; Posture und Image-Scan liegen im separaten Produkt Cloud Native Security.
Cortex Cloud Runtime Security
Palo Alto Networks
Workload-Schutz für VMs, Container, Kubernetes und Serverless-Anwendungen über mehrere Clouds.
Ein einzelner, leichtgewichtiger Agent blockiert Malware und Exploit-Techniken; im Cloud-Einsatz ist das der um Cloud-Datenquellen erweiterte Cortex-XDR-Agent.
Bekannte und Zero-Day-Bedrohungen werden zum Zeitpunkt der Ausführung gestoppt, für Hosts, Container und Serverless-Workloads.
Schwachstellen in VMs, Containern, Serverless und Open-Source-Paketen werden nach Ausnutzbarkeit, Patch-Verfügbarkeit und Internet-Exposition priorisiert; Fälle fliessen in Cortex XSIAM.
Agentenloser Scan beim Onboarding der Cloud-Konten ergänzt den Agenten; der Laufzeitschutz enthält laut Mitteilung die CNAPP-Funktionen ohne Zusatzkosten.
Organisationen mit Cortex XDR oder XSIAM, die Cloud-Workloads mit demselben Agenten und SOC schützen wollen.
Endpunkt-Agent, Cloud-Posture und SOC-Plattform aus einer Hand.
Die Seite zum Laufzeitschutz nennt keine Server im eigenen Rechenzentrum und kein Schwachstellenmanagement; dieses beschreibt die Plattform-Doku.
Prisma Cloud Compute Edition
Palo Alto Networks
Schutz für Hosts, Container und Serverless-Funktionen in der Cloud, im eigenen Rechenzentrum und in Umgebungen ohne Internetverbindung.
Defender je nach Workload: Container Defender, Host Defender für Server ohne Container, Orchestrator-Defender für Kubernetes, ECS und OpenShift, Serverless Defender für AWS Lambda und Azure Functions sowie App-Embedded Defender für Container-Dienste ohne Zugriff auf den Host. Daneben prüft ein agentenloser Snapshot-Scan Hosts und Container in AWS, Azure, GCP und OCI auf Schwachstellen und Compliance.
Der Laufzeitschutz erkennt etwa Prozesse, die nicht zum ursprünglichen Image gehören, unerwartete Netzwerk-Sockets und Malware, die einem Workload hinzugefügt wird.
Das Schwachstellenmanagement überwacht Hosts, Images und Funktionen laufend, lässt sich in CI-Prozesse einbinden und verbindet Befunde mit einem laufend aktualisierten Bedrohungsfeed und dem Wissen, was tatsächlich läuft.
Console und Defender werden heruntergeladen und selbst betrieben; bei Updates folgt zuerst die Console, danach die Defender. Für isolierte Umgebungen liefert der Hersteller zu jedem Release Werkzeuge, die die Bereitstellungsdateien für das Update ohne Zugang zum Supportportal erzeugen.
Organisationen, die volle Kontrolle über ihre Daten wollen oder Workloads in Umgebungen ohne Internetverbindung schützen müssen.
Workload-Schutz mit eigener Console, auch in Umgebungen ohne Internetverbindung.
Betrieb, Updates und Verfügbarkeit von Console und Defendern liegen bei der Organisation; Cloud-Posture (CSPM) liefert Palo Alto Networks in der SaaS-Ausgabe, die Compute Edition deckt den Workload-Teil ab.
TrendAI Vision One Server & Workload Protection
TrendAI (Trend Micro)
Physische, virtuelle und Cloud-Server sowie Container-Workloads mit breiter Linux-Unterstützung.
Der Agent vereint Application Control, Anti-Malware, Web Reputation, Firewall und Intrusion Prevention, dazu Integrity Monitoring und Log Inspection.
Exploit-Schutz und Intrusion Prevention schirmen Schwachstellen ab, bevor ein Patch eingespielt ist; Forschung der Zero Day Initiative fliesst ein.
Automatische Workload-Erkennung in AWS, Azure und Google Cloud; EDR und XDR über die Plattform TrendAI Vision One.
Zentrale Konsole für Richtlinien, Inventar und Erkennungen über Endpunkte, Server und Workloads; ein MDR-Dienst ist verfügbar.
Gemischte Serverlandschaften aus Rechenzentrum und Cloud, bei denen Patches nicht sofort eingespielt werden können.
Viele Schutzschichten im Server-Agenten, darunter Intrusion Prevention als Schutz bis zum Patch.
Serverless-Funktionen und agentenloser Workload-Scan sind auf der Workload-Seite nicht genannt; agentenlose Prüfung beschreibt TrendAI beim Produkt Cloud Risk Management.
GravityZone Cloud Workload Protection und Security for Containers
Bitdefender
Virtualisierte und hybride Umgebungen in Public und Private Clouds sowie Rechenzentren; Container auf Docker, Podman, Kubernetes, Amazon ECS und EKS, Azure AKS und Google GKE.
Security for Containers kommt ohne Linux-Kernel-Module aus; ein einzelner, kernelunabhängiger Agent unterstützt mehrere Linux- und Container-Distributionen.
Verhaltensüberwachung und Zero-Day-Schutz überwachen Speicherzugriffe und blockieren Exploits wie Prozess-Hijacking und Container-Ausbrüche.
Teil der GravityZone-Plattform mit Application Control, Machine Learning und weiteren Schutzschichten für Server.
Scans lassen sich auf eine dedizierte Security Virtual Appliance auslagern; Lizenzierung nach CPU oder über die gehostete Cloud-Konsole.
Virtualisierte Rechenzentren und hybride Clouds mit gängigen Hypervisoren, die Server und Container mit einer Plattform schützen.
Schutz für Rechenzentrum, Virtualisierung und Container aus einer Plattform, mit kernelunabhängigem Linux-Agenten.
Schwachstellenmanagement und Serverless-Workloads sind auf den Workload- und Container-Seiten nicht beschrieben.
Sophos Cloud Workload Protection
Sophos
Alle aktuellen Versionen von Windows Server sowie Linux-Distributionen wie RHEL, Ubuntu LTS, Amazon Linux, Debian, Oracle Linux und CentOS Stream auf x86_64 und ARM64; Knoten und Container.
Ein schlanker Agent mit geringer Last für Cloud-Umgebungen; native Telemetrie aus AWS, Azure, GCP und OCI wird zusätzlich eingelesen.
Laufzeiterkennung auch in Namespaces ohne Root-Rechte; verdächtige Konfigurationsänderungen werden gemeldet.
Sophos XDR bündelt Erkennung, Untersuchung und Reaktion über Cloud-Plattformen, Workloads und übrige Umgebung.
Verwaltung über eine einheitliche Konsole für den gesamten Cloud-Bestand; Sophos MDR überwacht und reagiert rund um die Uhr.
Organisationen mit Sophos-Endpunktschutz oder MDR, die Cloud-Server und Container in denselben Betrieb aufnehmen.
Breite Liste unterstützter Server-Betriebssysteme und direkte Anbindung an den MDR-Dienst des Herstellers.
Serverless-Workloads und der Betrieb für Server im eigenen Rechenzentrum sind auf der Produktseite nicht beschrieben.
Wiz (agentenloser Workload-Scan und Runtime Sensor)
Wiz (Google)
Alle Cloud-Workloads einschliesslich virtueller Maschinen, Container-Registries, Serverless-Funktionen und virtueller Appliances.
Workloads werden ohne Agenten erkannt und auf Schwachstellen, Secrets, Malware und Fehlkonfigurationen geprüft.
Der Wiz Runtime Sensor überwacht den Workload von innen auf Bedrohungen und bösartiges Verhalten.
Schwachstellen werden mit Kontext aus dem Wiz Security Graph priorisiert, etwa Exposition und Identitäten.
SaaS mit API-Anbindung; Google bestätigt, dass Wiz auf AWS, Azure, Google Cloud und Oracle Cloud verfügbar bleibt.
Organisationen, die zuerst agentenlos die Breite abdecken und den Sensor gezielt auf kritischen Workloads einsetzen.
Agentenloser Tiefenscan und Laufzeitsensor speisen denselben Risikograph.
Die CWPP-Seite nennt keine Unterstützung für Server im eigenen Rechenzentrum.
Orca Cloud Security Platform (CWPP)
Orca Security
VMs, Container, Kubernetes-Cluster und Serverless-Funktionen in der Cloud.
SideScanning liest Workloads aus, ohne dass ein Agent installiert wird.
Der Orca Sensor auf eBPF-Basis ergänzt Laufzeitbeobachtung und -schutz; Malware-Erkennung findet bekannten und potenziell bösartigen Code.
Über 20 Schwachstellen-Datenquellen dienen der Erkennung und Priorisierung über den gesamten Cloud-Bestand.
SaaS mit regionalen Instanzen; Workload-Befunde stehen im selben Graph wie Posture- und Identitätsrisiken.
Umgebungen mit hohem Anteil kurzlebiger oder fremd betriebener Workloads, auf denen Agenten schwer durchsetzbar sind.
Vollständige Sicht ohne Agenten, Laufzeitschutz nur dort, wo ein Sensor gewünscht ist.
Die CWPP-Seite nennt keine Unterstützung für Server im eigenen Rechenzentrum.
Aqua Platform (CWPP)
Aqua Security
Laufzeitschutz für Container, Kubernetes, Serverless-Funktionen und VMs in hybriden und Multi-Cloud-Umgebungen.
Agentenloser Scan zeigt die Workload-Posture; Richtlinien werden im Workload auf Kernel-Ebene durchgesetzt.
Drift Prevention hält Container unveränderlich und blockiert unautorisierte Aktivität, während der Container weiterläuft.
Die Ausnutzung von Schwachstellen ohne verfügbaren Fix wird verhindert; Schwachstellen werden nach Erreichbarkeit, EPSS und aktiver Ausnutzung priorisiert.
Betrieb on-premises, hybrid oder in mehreren Clouds, auch in abgeschotteten Umgebungen ohne Internetverbindung.
Container-lastige Plattformen in regulierten Umgebungen, die Unveränderlichkeit zur Laufzeit erzwingen wollen.
Durchsetzung zur Laufzeit inklusive Drift Prevention, auch in air-gapped Umgebungen.
Die CWPP-Seite beschreibt den Schutz für VMs knapp; der Schwerpunkt liegt auf Containern und Kubernetes.
Sysdig Secure (Workload-Schutz)
Sysdig
Linux- und Windows-Hosts, Kubernetes-Knoten, Registries sowie Serverless-Container wie AWS ECS on Fargate, Azure Container Apps und Google Cloud Run.
Ein Agent auf Hosts und Knoten, für Fargate ein Serverless Agent, liefert Laufzeitdaten; der Host-Scanner läuft als Container oder Paket.
Laufzeiterkennung und Richtliniendurchsetzung auf Basis von Falco, auch für Serverless-Workloads.
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; Schwachstellenmanagement ist mit dem Onboarding der Cloud-Konten für AWS, Azure, GCP und OCI verbunden.
Container- und Kubernetes-Plattformen, die Laufzeiterkennung auf Falco-Regeln stützen und Schwachstellen nach Laufzeitkontext bewerten wollen.
Laufzeiterkennung auf Basis des offenen Falco-Regelwerks bis hin zu Serverless-Containern.
Die Doku beschreibt eine agentenlose Anbindung der Cloud-Konten; einen Snapshot-Scan von Workloads nennt sie nicht ausdrücklich.
Falco
Falco (CNCF, Open Source)
Laufzeitsicherheit für Hosts, Container, Kubernetes und Cloud-Umgebungen; Installation auch direkt auf Linux-Hosts per DEB- oder RPM-Paket.
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; Falco meldet, die Reaktion übernehmen angebundene Systeme.
Alarme im JSON-Format lassen sich an über 50 Drittsysteme wie SIEMs weiterleiten und in Reaktionsabläufe einbinden.
CNCF-Projekt mit Status Graduated; Betrieb, Regelpflege und Alarmverarbeitung liegen beim Anwender.
Plattform-Teams, die Laufzeiterkennung offen, nachvollziehbar und ohne Lizenzkosten in eigene Abläufe einbauen wollen.
Offenes Regelwerk für Laufzeiterkennung, das etwa Sysdig Secure als Referenzbibliothek nutzt.
Falco erkennt und meldet, Schwachstellen-Scan und automatisches Blockieren gehören nicht zum Kern.
Weitere Anbieter
Kurz eingeordnet, ausserhalb der Vergleichsmatrix.
- Fortinet FortiCNAPP: agentenloser Workload-Scan auf Schwachstellen und Secrets belegt; Umfang des Laufzeitschutzes dort nicht belegt
- Tenable One Cloud Exposure: Schwachstellen in VMs, Containern und Kubernetes belegt; Laufzeitschutz im Workload nicht belegt
- Check Point CloudGuard Workload Protection: Check Point hat am 11.02.2025 die Migration seiner CNAPP-Kunden zu Wiz angekündigt
- Qualys TotalCloud: Produktseite nennt agentenlose und agentenbasierte Optionen, beschreibt Workload-Funktionen aber nicht im Detail
- Upwind, Uptycs, Broadcom Symantec Data Center Security: weitere Angebote für Workload-Schutz
- Agentenlose Sicht wird mit aktivem Laufzeitschutz verwechselt.
- Kurzlebige Container verschwinden, bevor Befunde zuverlässig korreliert sind.
- Blockierende Regeln ohne abgestimmten Rollout gefährden produktive Workloads.
Build und Runtime trennen.
Teste einen verwundbaren Workload, einen unerwarteten Prozess, eine verdächtige Verbindung und einen kurzlebigen Container. Dokumentiere, welche Kontrolle nur erkennt und welche tatsächlich verhindert oder isoliert.
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.