CWPP

01 — DéfinitionQu'est-ce qu'un CWPP ?

Un CWPP (Cloud Workload Protection Platform) est une plateforme de sécurité qui protège les workloads cloud — machines virtuelles, containers, fonctions serverless, bases de données, services PaaS — tout au long de leur cycle de vie. Concept formalisé par Gartner en 2017, le CWPP est devenu l'un des trois piliers centraux des plateformes CNAPP modernes.

Le CWPP est l'héritier modernisé de l'antivirus serveur et de l'EDR, adapté aux architectures cloud-natives. Alors que l'EDR protège traditionnellement les endpoints (PC, serveurs on-premises), le CWPP répond aux défis spécifiques du cloud :

• Workloads éphémères (containers qui vivent minutes).
• Déploiements à forte fréquence via CI/CD.
• Intégration dans les pipelines DevOps.
• Couverture multi-environnements (VMs, K8s, serverless).
• Auto-scaling dynamique.
• Architectures distribuées microservices.

Différence avec le CSPM

CSPM et CWPP sont complémentaires :

• CSPM : analyse les configurations au niveau du cloud provider (buckets, security groups, IAM policies).
• CWPP : analyse le contenu des workloads (OS, bibliothèques, applications, comportements).

Un bucket S3 mal configuré est détecté par le CSPM. Une CVE Log4Shell dans une application déployée est détectée par le CWPP. Les deux disciplines sont intégrées dans les plateformes CNAPP.

Un attaquant qui exploite une vulnérabilité dans un container n'a rien à voir avec une mauvaise config S3. CSPM et CWPP traitent des surfaces complètement différentes, c'est pourquoi ils sont tous deux nécessaires.

02 — CapacitésCe que fait un CWPP

1. Scanning de vulnérabilités

Détection des CVE dans :

• Système d'exploitation (noyau, paquets).
• Bibliothèques applicatives (Java, Python, Node.js, Go).
• Images de containers (couches Docker).
• Fonctions serverless et leurs dépendances.
• Dépendances tierces via SBOM.

Priorisation selon CVSS, EPSS, présence au KEV catalog CISA (vulnérabilités activement exploitées).

2. Détection de malwares

Identification de logiciels malveillants dans les images et workloads : ransomware, backdoors, cryptomineurs, RAT. Signatures classiques complétées par des analyses comportementales et heuristiques ML.

3. Protection runtime

Le cœur distinctif du CWPP : détection et blocage en temps réel de comportements anormaux ou malveillants dans les workloads en production. Détecte :

• Processus suspects (shells lancés dans des containers non-interactifs).
• Connexions réseau anormales vers des IP malveillantes ou vers du C2.
• Modifications de fichiers système critiques.
• Escalade de privilèges.
• Techniques MITRE ATT&CK appliquées au cloud.
• Exploitation en cours de vulnérabilités connues ou zero-day.

Basée sur des agents légers avec technologies modernes comme eBPF (extended Berkeley Packet Filter) qui permet une observabilité profonde sans modifier le noyau.

4. Scanning d'images et shift-left

Analyse des images de containers avant déploiement :

• Dans le pipeline CI/CD : scanning à chaque build.
• En registry : scan périodique des images stockées.
• À l'admission dans Kubernetes : blocage des images non conformes.
• Détection de secrets, malwares, CVE, mauvaises pratiques (images as root, images non signées).

5. Détection de secrets

Recherche de secrets exposés dans :

• Images Docker.
• Variables d'environnement.
• Code source dans les repositories.
• Logs applicatifs.
• Fichiers de configuration.

6. Intégrité des fichiers (FIM)

File Integrity Monitoring : détection des modifications non autorisées de fichiers système critiques, binaires, configurations. Utile pour détecter l'installation de backdoors, modifications de scripts système, tamper attacks.

7. Segmentation micro (microsegmentation)

Contrôle granulaire des flux réseau entre workloads. Limitation des mouvements latéraux : un container compromis ne peut pas atteindre les autres services qui ne lui sont pas nécessaires. S'appuie sur les primitives réseau de Kubernetes (Network Policies) ou des technologies comme Calico, Cilium.

8. Sécurité Kubernetes

Capacités dédiées quand le CWPP couvre aussi Kubernetes (souvent appelé KSPM quand centré configuration) :

• Admission controllers sécurisés (Gatekeeper, Kyverno).
• Runtime security via Falco ou équivalents.
• RBAC analysis.
• Pod Security Standards enforcement.
• Service mesh security (Istio, Linkerd).

9. Serverless security

Spécificités serverless :

• Scanning du code des fonctions.
• Analyse des permissions IAM des fonctions (droits excessifs).
• Détection d'attaques spécifiques (cold start abuse, event injection).
• Monitoring des API invoquées par les fonctions.

10. Durcissement (hardening)

Recommandations d'amélioration de la posture : configuration OS durcie, désactivation de services inutiles, application des CIS Benchmarks au niveau système, plutôt qu'infrastructure.

03 — Agent vs agentlessDeux philosophies

Approche agent (historique)

Installation d'un agent sur chaque workload. L'agent collecte en continu et peut agir directement.

Avantages

• Runtime protection précise : détection en millisecondes.
• Visibilité profonde : processus, mémoire, syscalls.
• Actions immédiates : kill process, blocage connexions.
• Détection d'exploits en temps réel.
• Protection offline : fonctionne même si la connexion au cloud est coupée.

Limites

• Overhead : 2-5% CPU/mémoire typiquement.
• Maintenance : déploiement, mises à jour.
• Compatibilité OS : tous les Linux, Windows Server ne sont pas supportés partout.
• Workloads éphémères : les containers qui vivent quelques minutes ne justifient pas l'installation d'agents classiques.

Acteurs agent : CrowdStrike Falcon, Sysdig Secure (avec eBPF), Aqua Enforcer, SentinelOne, Trend Micro.

Approche agentless (moderne)

Scan via API des snapshots de workloads côté cloud provider, sans rien installer sur le workload.

Avantages

• Déploiement immédiat : quelques heures pour couvrir tout l'environnement.
• Aucun overhead sur les workloads.
• Couverture 100% : même les workloads nouveaux, éphémères, tiers.
• Pas de maintenance d'agents.
• Pas de compatibilité OS : scan des snapshots bloc-level.

Limites

• Pas de runtime protection : détection basée sur snapshots périodiques (15 min à 24h).
• Pas d'action immédiate : détection décalée, pas de kill process.
• Pas de visibilité processus/mémoire : uniquement l'état à l'instant du snapshot.
• Latence sur les exploits : attaque possiblement terminée avant détection.

Acteurs agentless pionniers : Wiz, Orca Security.

Approche hybride (standard 2026)

La plupart des CNAPP matures combinent :

• Agentless par défaut : découverte universelle, scanning des snapshots, analyse de configuration.
• Agents ciblés : sur les workloads critiques nécessitant du runtime (applications financières, systèmes de production à forte valeur).

Cette combinaison offre le meilleur compromis : couverture exhaustive + profondeur quand nécessaire. Les acteurs pure-agent (CrowdStrike, Sysdig) ajoutent des capacités agentless. Les acteurs pure-agentless (Wiz, Orca) proposent des agents optionnels pour le runtime.

eBPF — la technologie qui change la donne

eBPF (extended Berkeley Packet Filter) permet d'exécuter du code sandboxé dans le noyau Linux pour observer et filtrer les événements système sans modifier le noyau. Devient la technologie standard pour :

• Observabilité runtime sans overhead significatif.
• Détection d'anomalies comportementales.
• Monitoring réseau au niveau des syscalls.
• Enforcement de policies sans modifier les applications.

Adopté par : Falco (projet open source CNCF), Cilium (networking Kubernetes), Sysdig, Isovalent, Tetragon. eBPF combine les avantages des agents (visibilité profonde) et des approches agentless (léger, non intrusif).

04 — Cycle de vieCouverture du build au runtime

Phase 1 — Build (shift-left)

• Scanning des images dans le pipeline CI/CD.
• Détection de CVE avant publication de l'image.
• SBOM généré à chaque build.
• Scan de secrets.
• Bonnes pratiques Dockerfile : non-root, minimal base, multi-stage builds.
• Signatures d'images : cosign, Notary.
• Blocage des PR avec issues critiques.

Phase 2 — Registry

• Scanning périodique des images stockées.
• Alerte sur nouvelles CVE affectant les images existantes.
• Policies d'admission : quelles images peuvent être pulled.
• Suppression automatique des images obsolètes ou vulnérables.

Phase 3 — Deploy

• Admission controllers : validation avant acceptation dans Kubernetes.
• Policies organisationnelles : OPA Gatekeeper, Kyverno.
• Vérification des signatures.
• Validation des configurations du manifest Kubernetes.

Phase 4 — Runtime

Phase la plus active :

• Monitoring continu des processus, syscalls, connexions réseau.
• Détection d'anomalies comportementales.
• Application de règles MITRE ATT&CK for Cloud.
• Corrélation d'événements.
• Actions immédiates : kill, isolate, block selon gravité.
• FIM — détection des modifications système.

Phase 5 — Response

• Intégration avec le SOC.
• Enrichissement des alertes pour les SOC analysts.
• Intégration SIEM et SOAR.
• Investigations forensic : capture d'état du workload compromis.
• Actions de remédiation coordonnées.

05 — ActeursLe marché CWPP

Plateformes CNAPP intégrées (leaders)

• CrowdStrike Falcon Cloud Security : EDR + CWPP unifié, approche agent historique, runtime fort.
• Palo Alto Prisma Cloud : suite enterprise complète, agents et agentless.
• Microsoft Defender for Cloud : CWPP intégré, très bon sur les workloads Azure.
• Wiz : agentless leader, ajout progressif d'agents optionnels (Wiz Runtime Sensor).
• Orca Security : agentless SideScanning, runtime via eBPF en ajout.

Spécialistes CWPP

• Sysdig Secure : pionnier eBPF, très fort sur les containers et Kubernetes, créateur de Falco.
• Aqua Security : historique de la sécurité containers, plateforme CNAPP complète.
• Trend Micro Cloud One : acteur historique antivirus devenu CWPP enterprise.
• Uptycs : approche unifiée endpoint + cloud via osquery.
• Sweet Security, Upwind : entrants récents focus runtime.
• Rapid7 InsightCloudSec : combiné avec leur VM.
• Tenable Cloud Security : approche issue de la gestion de vulnérabilités.

Acteurs SentinelOne et concurrents unifiés

• SentinelOne Singularity Cloud : renforcé par rachats Attivo et PingSafe.
• Trellix Cloud Workload Security : issu de la fusion McAfee/FireEye.
• Check Point CloudGuard Workload.

Services natifs cloud providers

• AWS Inspector : scanning de vulnérabilités EC2, ECR, Lambda.
• AWS GuardDuty : détection de menaces runtime.
• Azure Defender for Servers, Containers, SQL.
• Google Security Command Center : ajoute progressivement des capacités CWPP.

Open source

• Falco : référence runtime security Kubernetes, projet CNCF.
• Trivy : scanning d'images et IaC (Aqua).
• Clair : scanning d'images containers.
• Anchore : compliance et scanning containers.
• Tetragon : Isovalent, runtime security basé eBPF.
• KubeLinter : analyse statique des manifests Kubernetes.
• Cilium : networking eBPF avec capacités sécurité.

06 — Bonnes pratiquesDéployer un CWPP efficacement

07 — FAQQuestions fréquentes

CWPP remplace-t-il l'EDR ?

Pas systématiquement, mais la frontière s'estompe. Pour les environnements purement cloud-native, un CWPP avec capacités runtime (agent ou eBPF) peut suffire. Pour les organisations hybrides avec endpoints corporate (PC, Macs, serveurs on-premises), l'EDR reste nécessaire. Les plateformes unifiées (CrowdStrike Falcon, Microsoft Defender XDR, SentinelOne Singularity) couvrent les deux dans une seule plateforme, tendance forte en 2025-2026.

Combien coûte un CWPP ?

Tarification indicative 2026, généralement par workload ou vCPU. Services natifs cloud providers : AWS Inspector à quelques USD par compute/mois, Azure Defender ~15 USD/serveur/mois. CWPP standalone : 20 à 40 USD par workload/mois pour les gammes moyennes. CNAPP complet : 50 000 à 500 000 €/an selon taille. Open source : Falco, Trivy gratuits mais expertise nécessaire.

Quelle couverture pour le serverless ?

Émergente mais en forte progression. Les CWPP leaders couvrent désormais AWS Lambda, Azure Functions, GCP Cloud Functions via : scanning du code des fonctions, analyse des permissions IAM (droits excessifs via CIEM), détection de CVE dans les runtimes, monitoring des invocations anormales. Certains acteurs ont un positionnement spécifique serverless (PureSec, devenu Palo Alto Prisma Cloud). La couverture reste moins mature que les VMs et containers, à vérifier selon votre stack.

Faut-il un CWPP si on utilise déjà un EDR sur ses VMs ?

Dépend du périmètre. Si votre EDR (CrowdStrike, Microsoft Defender, SentinelOne) couvre les VMs et supporte les containers, il peut faire office de CWPP partiel. Il manque typiquement : scanning d'images en CI/CD, protection serverless, compréhension Kubernetes native, intégration dans une CNAPP unifiée avec CSPM/CIEM. Stratégie courante : conserver l'EDR sur les endpoints et adopter un CNAPP qui couvre le cloud-native — les deux coexistent.

eBPF est-il obligatoire pour un CWPP moderne ?

Pas obligatoire mais de plus en plus standard. eBPF offre une observabilité profonde sans overhead significatif, idéale pour les environnements cloud-native. Les acteurs qui n'ont pas encore adopté eBPF sont typiquement en transition. Pour un choix en 2026, vérifier que la plateforme supporte eBPF nativement est un plus fort, car c'est la direction claire du marché. Sysdig a été pionnier, Isovalent/Tetragon pousse cette vision, Cilium intègre eBPF côté networking Kubernetes.