01Cartographie des notions : CSPM, CWPP, CIEM, KSPM, DSPM
Le CSPM (Cloud Security Posture Management) vérifie en continu les configurations cloud par rapport aux politiques et aux benchmarks et met au jour les erreurs de configuration ainsi que les écarts de conformité. Le CWPP (Cloud Workload Protection Platform) protège les workloads eux-mêmes – machines virtuelles, conteneurs et fonctions serverless – par l'analyse de vulnérabilités et la surveillance à l'exécution. Le CIEM (Cloud Infrastructure Entitlement Management) inventorie les identités cloud avec leurs droits et applique le principe du moindre privilège. Le KSPM transpose la logique de posture aux clusters Kubernetes ; le DSPM (Data Security Posture Management) repère les données sensibles dans les stockages cloud et évalue leur exposition.
02Consolidation en CNAPP : une plateforme, un modèle de données
Plutôt que d'exploiter séparément CSPM, CWPP, CIEM et scanners de vulnérabilités, une CNAPP intègre ces fonctions dans une plateforme unique dotée d'un modèle de données commun – du code au runtime en passant par la pipeline. Une enquête menée en 2023 par la Cloud Security Alliance auprès de 1 201 responsables IT et sécurité montre à quel point l'approche s'est répandue : trois organisations sur quatre avaient déjà adopté une CNAPP ou prévoyaient de le faire – avant tout pour maîtriser la complexité de leurs environnements multi-cloud. Les hyperscalers positionnent eux aussi désormais explicitement leurs suites de sécurité comme des CNAPP, à l'image de Microsoft Defender for Cloud avec ses briques CSPM, DevSecOps et CWPP.
03Sans agent, avec agent – ou les deux
Les approches sans agent lisent les configurations et des snapshots de workloads via les API des fournisseurs cloud : elles atteignent en peu de temps une couverture quasi complète, y compris pour les workloads sur lesquels aucun agent n'a jamais été installé. Leur limite : elles ne fournissent que des instantanés et ne peuvent ni détecter ni bloquer en temps réel les attaques à l'exécution. Les capteurs basés sur agent fournissent en revanche de la télémétrie runtime pour la détection et la réponse, mais engendrent des coûts de déploiement et d'exploitation. Dans la pratique, c'est la combinaison qui s'est imposée – une couverture de base sans agent pour la visibilité et la posture, complétée par des capteurs légers sur les workloads critiques ; c'est le modèle suivi par Wiz, avec un scan sans agent et un capteur runtime optionnel, tout comme par Microsoft Defender for Cloud.
04Un graphe plutôt qu'une liste de findings : contexte et chemins d'attaque
Les outils isolés classiques produisent de longues listes de findings sans lien entre eux ; dans l'enquête de la CSA, 32 % des organisations déclaraient ne pas pouvoir prioriser leurs mesures de sécurité face au flot d'alertes souvent imprécises. Les CNAPP y répondent par l'analyse par graphe : ressources, erreurs de configuration, vulnérabilités, identités, exposition réseau et classification des données sont modélisées sous forme de graphe interconnecté. Les combinaisons toxiques deviennent ainsi visibles – par exemple une VM exposée sur Internet cumulant une vulnérabilité critique et un rôle à privilèges élevés – et les chemins d'attaque montrent par quelles voies des attaquants pourraient réellement atteindre les actifs critiques. La priorisation ne se fonde donc plus sur la sévérité individuelle, mais sur l'exploitabilité réelle.
05Shift-left et runtime : du scan IaC au CDR
Une CNAPP intervient dès avant le déploiement : le scan IaC contrôle les manifestes Terraform, ARM ou Kubernetes dans la pipeline CI/CD à la recherche d'erreurs de configuration et de secrets exposés, afin que les findings soient corrigés là où ils naissent – dans le code. Le contexte cloud aide en parallèle à déterminer quels findings issus du code sont réellement pertinents en production. À l'autre extrémité du cycle de vie se trouvent la protection à l'exécution et la Cloud Detection & Response (CDR), qui détectent les menaces actives dans les workloads en cours d'exécution. Le fait que la sécurité des conteneurs doive couvrir l'ensemble du cycle de vie – de l'image au runtime en passant par la registry et l'orchestration – est déjà décrit dans le guide NIST SP 800-190.
06Critères de sélection et risque fournisseur
Les critères essentiels sont la couverture de votre environnement (fournisseurs cloud, Kubernetes, serverless, le cas échéant on-premises), l'architecture de scan (sans agent plus capteur), la qualité de l'analyse par graphe et des chemins d'attaque, les mappings de conformité vers des référentiels comme les CIS Benchmarks ou le catalogue C5 du BSI, ainsi que les intégrations avec le SIEM, le ticketing et les workflows des développeurs. Le modèle d'exploitation est tout aussi important : sans responsabilités définies pour le traitement des findings, même la meilleure plateforme reste sans effet. S'y ajoute le risque fournisseur, car le marché des CNAPP se consolide – en mars 2026, Google a finalisé le rachat de Wiz pour environ 32 milliards de dollars US. Il est donc recommandé de vérifier régulièrement la parité fonctionnelle sur l'ensemble des clouds utilisés et de traiter contractuellement les coûts de migration et la neutralité multi-cloud.
