Aller au contenu principal

Publié le 7 juillet 2026 · Sécurité cloud

CSPM, CWPP, CIEM, CNAPP : quelles différences ?

Le CSPM (Cloud Security Posture Management) détecte les mauvaises configurations de votre infrastructure cloud. Le CWPP (Cloud Workload Protection Platform) protège vos charges de travail : machines virtuelles, conteneurs et fonctions serverless. Le CIEM (Cloud Infrastructure Entitlement Management) analyse les identités et les permissions. Le CNAPP (Cloud-Native Application Protection Platform) réunit ces trois briques dans une plateforme unique qui corrèle leurs signaux.

Sur le papier, c’est simple. En pratique, ces sigles sont devenus des arguments marketing interchangeables : la plupart des éditeurs rebaptisent leurs produits au gré des tendances, et il devient difficile de savoir ce que l’on achète réellement. Résultat : des budgets sécurité dépensés sur des outils redondants, ou des angles morts que personne ne couvre. Cet article remet chaque terme à sa place, avec des exemples concrets sur AWS, Azure et GCP.

Ces catégories ne sont pas nées en même temps. Le CSPM et le CWPP existent depuis la fin des années 2010 comme marchés distincts ; le CIEM est apparu ensuite, quand les incidents liés aux identités cloud se sont multipliés ; et le terme CNAPP a été popularisé par les analystes au début des années 2020 pour désigner la convergence des trois. Comprendre cette généalogie aide à lire les fiches produit : derrière chaque sigle, il y a une question de sécurité précise.

Qu’est-ce que le CSPM ?

Le CSPM est un outil qui inventorie en continu les ressources de vos comptes cloud et les compare à des règles de bonne configuration pour détecter les écarts. Il répond à la question : « mon cloud est-il configuré de façon sûre ? » Techniquement, il fonctionne sans agent : il interroge les API du fournisseur cloud avec un rôle en lecture seule, reconstruit l’inventaire complet, puis évalue chaque ressource contre des centaines de règles.

Concrètement, un CSPM détecte par exemple : un bucket S3 accessible publiquement, un security group AWS ouvert en 0.0.0.0/0 sur le port 22, un compte de stockage Azure sans chiffrement ni restriction réseau, un bucket Cloud Storage GCP partagé avec « allUsers », ou encore CloudTrail désactivé sur un compte de production. Il rattache souvent ces constats à des référentiels de conformité (CIS Benchmarks, ISO 27001, NIS2, SOC 2).

Ses limites : le CSPM regarde la configuration autour des workloads, jamais à l’intérieur. Il ne sait pas si votre machine virtuelle embarque une vulnérabilité critique, ni si le rôle attaché à cette machine permet de prendre le contrôle du compte. Et comme il évalue chaque ressource isolément, il produit de longues listes d’alertes sans hiérarchie réelle de risque.

Qu’est-ce que le CWPP ?

Le CWPP est une solution qui protège les charges de travail elles-mêmes : machines virtuelles, images et conteneurs, clusters Kubernetes et fonctions serverless. Il répond à la question : « ce qui tourne dans mon cloud est-il vulnérable ? »

Un CWPP identifie par exemple : une image dans Amazon ECR ou Azure Container Registry contenant une CVE critique de type Log4Shell, une VM EC2 construite sur une AMI obsolète, un pod Kubernetes exécuté en mode privilégié avec le système de fichiers de l’hôte monté, ou une fonction Lambda utilisant un runtime en fin de vie. Les approches modernes sont agentless : elles analysent les workloads via les API du fournisseur cloud, sans agent à déployer.

Ses limites : le CWPP ignore la posture du compte qui héberge le workload. Une CVE critique sur une VM isolée dans un sous-réseau privé n’a pas le même poids que la même CVE sur une VM exposée à Internet — mais un CWPP seul ne fait pas la différence, car il ne voit ni le réseau, ni les identités.

Qu’est-ce que le CIEM ?

Le CIEM est un outil qui analyse les identités (humaines et machines) et calcule leurs permissions effectives pour repérer les droits excessifs, inutilisés ou dangereux. Il répond à la question : « qui peut faire quoi dans mon cloud, et est-ce justifié ? »

Dans la pratique, un CIEM met en évidence : un rôle IAM AWS disposant de iam:PassRole sur des rôles administrateurs (escalade de privilèges possible), un service principal Azure titulaire du rôle Owner sur toute une subscription alors qu’il ne lit qu’un seul compte de stockage, un compte de service GCP avec le rôle Editor au niveau projet, ou des clés d’accès inutilisées depuis des mois. Le calcul des permissions effectives est loin d’être trivial : entre politiques attachées, politiques de groupe, SCP et boundaries, la permission réelle diffère souvent de la permission apparente.

Ses limites : le CIEM raisonne dans le silo des identités. Il sait qu’un rôle est sur-privilégié, mais pas que ce rôle est attaché à une machine vulnérable et exposée — c’est pourtant cette conjonction qui rend le risque critique.

CNAPP : la consolidation des trois

Le CNAPP est une plateforme qui regroupe CSPM, CWPP et CIEM (et généralement l’analyse IaC et la sécurité Kubernetes) dans un même produit, avec un apport décisif : la corrélation. Plutôt que trois listes d’alertes séparées, un CNAPP construit un graphe reliant configurations, workloads, réseau et identités, puis identifie les chemins d’attaque complets.

Exemple typique : une VM exposée à Internet (signal CSPM) + une CVE critique exploitable à distance (signal CWPP) + un rôle d’instance permettant de lire tous les buckets du compte (signal CIEM). Pris séparément, trois constats de sévérité moyenne. Corrélés, ils forment une combinaison toxique : un chemin direct d’Internet vers vos données. C’est précisément ce que les outils en silo ne peuvent pas voir.

Les limites existent aussi côté CNAPP : la profondeur de chaque module varie fortement d’un éditeur à l’autre (certains excellent en posture mais restent superficiels sur les identités), et un CNAPP n’est pas un EDR — il ne remplace pas la détection temps réel sur les endpoints.

OutilCe qu’il protègeQuestions auxquelles il répondExemples de détections
CSPMLa configuration des services cloudMon cloud est-il bien configuré ? Suis-je conforme ?Bucket S3 public, security group ouvert, chiffrement absent, logs désactivés
CWPPVM, conteneurs, Kubernetes, serverlessMes workloads sont-ils vulnérables ?CVE critique dans une image, AMI obsolète, pod privilégié, secret dans une image
CIEMIdentités, rôles et permissionsQui peut faire quoi ? Quels droits sont excessifs ?Rôle sur-privilégié, escalade via iam:PassRole, clés d’accès dormantes
CNAPPL’ensemble, corrélé dans un graphe uniqueQuels risques sont réellement exploitables, et par quel chemin ?Chemins d’attaque, combinaisons toxiques, priorisation contextuelle

Faut-il un CSPM, un CNAPP, ou les deux ?

La réponse dépend moins de votre taille que de votre maturité cloud et de la bande passante de votre équipe sécurité.

Vous débutez dans le cloud, avec peu de workloads : commencez par la posture. Les fonctions CSPM couvrent l’essentiel des risques d’un environnement jeune (expositions publiques, chiffrement, journalisation). Inutile de payer des modules que vous n’exploiterez pas encore.

Vous opérez plusieurs comptes, des conteneurs ou Kubernetes : le CNAPP devient pertinent, car le volume d’alertes en silo n’est plus gérable humainement. La corrélation devient la seule façon de prioriser, surtout pour une équipe de une à trois personnes qui ne peut pas traiter des milliers de findings.

Vous avez déjà des outils en place : la question devient celle de la consolidation. Empiler un CSPM, un scanner de vulnérabilités et un outil IAM séparés coûte cher en licences et en temps d’intégration ; la plupart des organisations qui font ce bilan migrent progressivement vers une plateforme unifiée, en remplaçant les outils au fil des renouvellements de contrat.

Dans tous les cas, un critère de choix simple : demandez à voir comment l’outil priorise. S’il vous présente une liste plate de mille alertes classées par sévérité CVSS, vous achetez du bruit. S’il vous montre les cinq chemins d’attaque qui mènent réellement à vos données sensibles, avec le contexte réseau et identité qui les rend exploitables, vous achetez de la priorisation.

C’est l’approche retenue par Cyvex : une plateforme CNAPP unique où CSPM, CWPP et CIEM alimentent le même graphe de sécurité, pour ne remonter que les risques réellement exploitables.

Questions fréquentes

Un CNAPP remplace-t-il un CSPM ?

Oui, dans la plupart des cas. Un CNAPP intègre nativement les fonctions d’un CSPM et y ajoute la protection des workloads et l’analyse des identités. Si vous déployez un CNAPP, un CSPM autonome devient généralement redondant. L’inverse n’est pas vrai : un CSPM seul ne couvre ni les vulnérabilités des workloads ni les permissions excessives.

Quelle différence entre CNAPP et EDR/XDR ?

Un CNAPP sécurise l’infrastructure et les applications cloud (configurations, vulnérabilités, identités, chemins d’attaque), le plus souvent sans agent, via les API des fournisseurs cloud. Un EDR/XDR détecte les menaces actives sur les endpoints grâce à un agent qui observe les processus en temps réel. Les deux sont complémentaires : le CNAPP réduit la surface d’attaque en amont, l’EDR/XDR détecte l’exploitation en cours.

Un CNAPP est-il utile pour une PME ?

Oui, souvent plus que pour un grand groupe. Une PME n’a généralement pas les ressources pour opérer trois outils séparés ni pour trier manuellement des milliers d’alertes. Un CNAPP consolide tout dans une console unique et priorise les risques réellement exploitables, ce qui permet à une petite équipe de se concentrer sur les quelques problèmes critiques.

Qu’est-ce qu’une combinaison toxique ?

C’est un enchaînement de plusieurs faiblesses individuellement modérées (une VM exposée, une CVE non corrigée, un rôle trop permissif) qui forment ensemble un chemin d’attaque complet vers vos données. Nous y consacrons un article détaillé.

Vous hésitez entre consolider vos outils ou compléter votre CSPM existant ? Parlons de votre environnement : comptes, workloads, contraintes de conformité — et voyons ce qu’une approche CNAPP changerait concrètement pour votre équipe.

Échanger avec un expert Cyvex →