En 2024, les organisations ont subi en moyenne neuf incidents de sécurité cloud. Et près de neuf sur dix constatent que leur nombre augmente d’une année sur l’autre (source : étude IDC / Microsoft)
Derrière ces chiffres, une réalité simple : chaque ressource ajoutée dans le cloud est une nouvelle surface à défendre. Et certaines dérives passent facilement sous le radar : un Security Group modifié en urgence pour un debug, puis jamais reconfiguré, peut par exemple suffire à exposer durablement un service sans que personne ne s’en aperçoive.
C’est exactement ce type de dérive silencieuse, banale, et pourtant critique, que le CSPM (Cloud Security Posture Management) est conçu pour corriger : identifier en continu vos ressources exposées, détecter les écarts de configuration, prioriser les risques et orchestrer la remédiation.
Dans cet article, nous décryptons le CSPM : pourquoi il est devenu indispensable, et comment Cyberwatch vous permet de le mettre en œuvre, tout en intégrant la protection des workloads (CWPP) et des conteneurs, pour une approche CNAPP complète.
Qu’est-ce que le CSPM et pourquoi est-il devenu incontournable ?
Définition et principes clés
Le CSPM est une approche de cybersécurité conçue pour évaluer, surveiller et améliorer en continu la posture de sécurité des environnements cloud.
Son principe fondamental : garantir que les ressources cloud d’une organisation sont correctement configurées, exposées au minimum nécessaire, et conformes aux bonnes pratiques de sécurité.
Ce que recouvre concrètement l’exposition cloud
La surface cloud d’une organisation est bien plus large qu’un simple inventaire de machines virtuelles.
Elle englobe l’ensemble des ressources déployées chez les différents fournisseurs (AWS, Azure, GCP, OpenStack), ainsi que :
- Les configurations associées à chaque service,
- Les identités et les droits d’accès,
- Les données stockées dans le cloud (buckets S3, bases de données, sauvegardes, comptes de stockage Azure (Blob)…),
- Les ressources exposées publiquement sur Internet, parfois involontairement,
- Les paramètres réseau (règles de sécurité, sous-réseaux, interconnexions),
- Les mécanismes de sécurité appliqués (chiffrement, authentification, journalisation).
L’exposition cloud correspond ainsi à tout ce qui, dans l’environnement cloud, peut être accessible, mal configuré ou insuffisamment protégé, notamment au regard des bonnes pratiques et des référentiels de sécurité comme les CIS Benchmarks.
Pourquoi le cloud crée de nouveaux angles morts
Contrairement aux infrastructures on-premise, les environnements cloud ne sont ni statiques ni centralisés. L’adoption massive du multicloud (public, privé ou hybride) multiplie les points d’entrée et fragmente la visibilité : les ressources se répartissent sur plusieurs plateformes, avec des modèles de gestion différents.
Mais ce qui aggrave réellement la situation, c’est la vitesse. Les architectures modernes (conteneurs, orchestrateurs Kubernetes, pipelines CI/CD) introduisent des ressources dont le cycle de vie se compte en minutes, parfois en secondes.
Un pod Kubernetes peut apparaître, être exposé, puis disparaître avant même d’avoir été inventorié. Une image déployée automatiquement via une pipeline CI/CD peut introduire une vulnérabilité sans qu’aucune équipe n’ait eu le temps de l’identifier.
À cette complexité dynamique s’ajoutent des angles morts plus classiques, mais toujours aussi critiques :
- Des environnements de test qui restent actifs bien après leur utilisation
- Des droits d’accès qui prolifèrent sans revue régulière
- Du shadow IT cloud qui échappe totalement aux équipes sécurité
Sans outil dédié, il devient impossible de maintenir une vision fiable et à jour de ce qui est réellement exposé.
Des exigences réglementaires qui s’intensifient
À ces défis techniques s’ajoute une pression réglementaire croissante. La directive NIS2, applicable depuis octobre 2024, impose des obligations renforcées de gestion des risques cyber avec des sanctions pouvant atteindre 2% du chiffre d’affaires mondial.
ISO 27001, RGPD, SecNumCloud : les référentiels qui touchent directement à la sécurité des environnements cloud se multiplient et exigent désormais une traçabilité continue, bien au-delà de l’audit annuel.
Le CSPM devient dans ce contexte un outil de conformité autant que de sécurité opérationnelle.
Le CSPM en pratique : les 4 fonctions clés
1) Inventaire automatisé des ressources cloud
Impossible de sécuriser ce qu’on ne voit pas.
La première fonction du CSPM est donc d’identifier automatiquement l’ensemble des actifs déployés dans le cloud (machines virtuelles, conteneurs, services managés, comptes de stockage, ressources réseau…) quel que soit le ou les fournisseurs.
Cet inventaire doit être dynamique : une ressource créée aujourd’hui doit apparaître dans le périmètre supervisé sans intervention manuelle. C’est la condition sine qua non pour maintenir une cartographie fiable dans des environnements où les déploiements s’enchaînent en continu.
2) Détection et priorisation des risques
Une fois les actifs identifiés, les solutions CSPM analysent leur exposition réelle. Cela passe par la détection des vulnérabilités connues (CVE) qui les affectent, mais aussi par l’identification des écarts de configuration (un port ouvert inutilement, un protocole obsolète, une clé d’accès non protégée…).
Mais détecter ne suffit pas : il faut savoir quoi corriger en priorité.
Dans un environnement cloud où les vulnérabilités se comptent par milliers, une priorisation uniquement basée sur le score CVSS brut est insuffisante. Elle doit intégrer le contexte : la criticité métier de l’actif concerné, son niveau d’exposition réseau, et la probabilité réelle d’exploitation de la faille.
3) Contrôle continu de la conformité
L’approche CSPM consiste ensuite à surveiller en permanence les configurations des ressources cloud pour détecter les écarts vis-à-vis des référentiels de sécurité reconnus, au premier rang desquels les CIS Benchmarks, ou des politiques internes de l’organisation.
Ce contrôle continu est fondamental : une configuration conforme aujourd’hui peut ne plus l’être demain, suite à une mise à jour, une modification manuelle ou un nouveau déploiement. L’audit annuel ne suffit plus.
4) Remédiation et orchestration des correctifs
La dernière fonction du CSPM est de transformer la détection en action. Cela implique de fournir des recommandations précises et exploitables. Pas simplement signaler une anomalie, mais indiquer exactement quelle version corriger, quelle configuration modifier, quel accès révoquer.
Dans les environnements modernes, cette remédiation doit pouvoir s’orchestrer facilement : s’intégrer aux outils de ticketing existants, aux solutions de patch management, et s’inscrire dans les workflows des équipes IT sans créer de friction supplémentaire.
Le CSPM avec Cyberwatch : de la découverte à la remédiation
Découverte multi-cloud (AWS, Azure, GCP, OpenStack)
La visibilité sur les actifs cloud est le point de départ de toute démarche CSPM. Cyberwatch y répond grâce à des mécanismes de découverte natifs, capables d’identifier automatiquement les machines déployées sur les principaux fournisseurs cloud.
Dans le détail :
Découvertes AWS: Cyberwatch interroge directement l’API Amazon EC2 pour lister toutes les instances et leurs métadonnées (ID, IP, état, tags). La solution s’appuie sur un rôle IAM disposant uniquement des droits en lecture, dans le respect strict du principe du moindre privilège. Il est également possible de segmenter la découverte par rôle IAM pour compartimenter les environnements.
Découvertes Azure: via l’API Azure Resource Manager, Cyberwatch recense les machines virtuelles et leurs attributs (nom, IP, groupe de ressources), à partir d’un compte de service avec des droits en lecture sur les ressources de calcul.
Google Cloud Platform: la découverte repose sur l’API GCP et permet de lister les VM et leurs métadonnées (zone, IP, état) en s’appuyant sur un compte de service avec des droits en lecture sur Compute Engine.
Découvertes OpenStack: pour les infrastructures privées, Cyberwatch se connecte à l’API OpenStack pour récupérer les instances et leurs caractéristiques. Cette capacité est particulièrement utile pour les organisations qui combinent cloud public et cloud privé.
Au-delà de cette découverte par API, Cyberwatch peut également s’appuyer sur des mécanismes de connexion adaptés aux contextes techniques des ressources cloud. Par exemple, pour une instance AWS, un connecteur SSH classique peut être complété par un accès via AWS Systems Manager (SSM). Cette approche permet d’interagir avec certaines machines sans exposition réseau directe, ce qui renforce à la fois la sécurité et la souplesse opérationnelle.
La création d’un actif de type projet Cloud déclenche par ailleurs un inventaire automatique de l’ensemble des services et ressources managés associés : services de stockage (S3, Cloud Storage), bases de données managées (RDS), ressources réseau, utilisateurs et rôles IAM.
Tous ces actifs (machines virtuelles, services managés, identités) sont ainsi centralisés dans un inventaire exhaustif et mis à jour en continu. C’est le prérequis indispensable à toute démarche CSPM : sans cette visibilité complète, des ressources exposées ou mal configurées peuvent passer inaperçues, et la surface d’attaque ne peut pas être réellement maîtrisée.
Priorisation 3D : CVSS-BTE, EPSS, CISA KEV
Cyberwatch ne se contente pas de détecter les vulnérabilités : la plateforme les priorise selon une approche contextuelle en trois dimensions.
La priorisation repose sur une politique de criticité propre à chaque actif, définie selon les exigences de sécurité (Confidentialité, Intégrité, Disponibilité). Cette politique s’appuie sur les métriques environnementales du standard CVSS (v2, v3, v4) pour calculer un score adapté, le CVSS-BTE, qui intègre à la fois la gravité intrinsèque de la vulnérabilité et son impact potentiel sur l’actif concerné.
Concrètement, un serveur totalement isolé du réseau peut voir la criticité de ses vulnérabilités exploitables à distance automatiquement revue à la baisse. À l’inverse, une faille affectant un système exposé en production conservera un niveau de priorité élevé.
Cette contextualisation est complétée par deux indicateurs supplémentaires :
- Le score EPSS, qui reflète la probabilité d’exploitation réelle dans le monde,
- La présence dans des catalogues de référence reconnus comme le CISA KEV ou le CERT-FR ALE, qui signalent les vulnérabilités activement exploitées.
On ne raisonne plus en sévérité théorique globale, mais en risque réel pour un actif donné.
Conformité CIS Benchmarks pour les environnements cloud
Cyberwatch assure un contrôle continu des configurations cloud via les CIS Benchmarks, couvrant AWS, Microsoft Azure, Google Cloud Platform et Microsoft 365. En pratique, cela se traduit par des centaines de règles de durcissement vérifiées automatiquement et en permanence.
Quelques exemples concrets des contrôles appliqués :
Sous Microsoft Azure :
- CIS-Azure-4.1 : secure transfer required activé sur les comptes de stockage
- CIS-Azure-4.4 : régénération périodique des clés d’accès des Storage Accounts
- CIS-Azure-4.6 : désactivation du Public Network Access pour les comptes de stockage
- CIS-Azure-7.1 : évaluation et restriction de l’accès RDP depuis Internet
Sous Google Cloud Platform :
- CIS-GCP-3.1 : suppression du réseau par défaut dans les projets
- CIS-GCP-3.3 : activation de DNSSEC pour Cloud DNS
- CIS-GCP-4.1 : interdiction de l’usage du compte de service par défaut sur les instances
- CIS-GCP-4.3 : activation du blocage des clés SSH projet-wide pour les VM
Sous AWS :
- CIS-AWS-1.4 : vérification de l’absence de clés d’accès sur le compte root
- CIS-AWS-1.5 : activation du MFA pour le compte root
- CIS-AWS-1.8 : mise en place d’une politique de mots de passe avec une longueur minimale de 14 caractères
- CIS-AWS-1.12 : création d’un rôle de support dédié pour la gestion sécurisée des incidents
Au-delà des référentiels standards, Cyberwatch permet également de définir des règles personnalisées pour coller aux politiques internes de chaque organisation.
Remédiation intégrée et intégrations ITSM
Cyberwatch fournit des actions correctives précises, basées sur les bulletins officiels des éditeurs. Chaque recommandation indique la version corrigée ou le patch à appliquer, en tenant compte des spécificités des systèmes, notamment les branches propres aux distributions Linux.
Pour la mise en œuvre, la plateforme s’appuie sur les mécanismes natifs des systèmes :
- Linux : utilisation des gestionnaires de paquets (APT, YUM, DNF) pour appliquer les correctifs,
- Windows : exploitation de Windows Update pour déployer les KB nécessaires,
- Produits Microsoft tiers : recours à winget pour installer ou mettre à jour les applications.
Cyberwatch s’intègre également aux outils existants des équipes IT : solutions de patch management (WAPT, Ivanti, Intune) et outils de ticketing (ServiceNow, Jira, GLPI). Une vulnérabilité validée peut ainsi être automatiquement transformée en ticket pré-rempli, avec l’ensemble du contexte : actif concerné, niveau de criticité, correctif recommandé.
Du CSPM au CNAPP : comment Cyberwatch unifie la sécurité de vos environnements cloud
Si Cyberwatch couvre pleinement les besoins d’un CSPM moderne, la plateforme ne s’arrête pas là.
Et pour cause : les environnements cloud d’aujourd’hui ne se limitent plus à des machines virtuelles : conteneurs, clusters Kubernetes, pipelines CI/CD, workloads hybrides cohabitent dans des architectures de plus en plus complexes.
Pour y répondre, Cyberwatch intègre des capacités relevant du CWPP (Cloud Workload Protection Platform), posant les bases d’une stratégie CNAPP (Cloud-Native Application Protection Platform) véritablement unifiée.
La protection des workloads avec le CWPP
Le CWPP vise à protéger les workloads (machines virtuelles, serveurs, conteneurs, composants d’infrastructure) contre les vulnérabilités, les mauvaises configurations et les menaces qui peuvent en découler.
Là où le CSPM se concentre sur la posture cloud, le CWPP descend au niveau des workloads eux-mêmes, qu’ils soient cloud, on-premise ou hybrides.
Cyberwatch répond à cet enjeu en unifiant dans une même plateforme l’inventaire, la classification et l’analyse des workloads, quelle que soit leur nature ou leur emplacement :
- Infrastructures locales : hyperviseurs, serveurs, appliances réseau, via des découvertes dédiées couvrant VMware vSphere/ESXi, Microsoft Hyper-V, Proxmox, Nutanix, Active Directory, Fortinet, Stormshield…
- Cloud public : AWS, Azure, GCP, OpenStack, avec les mêmes mécanismes de découverte que ceux décrits dans la section CSPM.
- Exposition Internet : via l’énumération DNS, la Certificate Transparency et les données WHOIS, Cyberwatch identifie les domaines, services ou machines exposés publiquement, parfois mal référencés ou oubliés, qui peuvent représenter une surface d’attaque significative.
Cette approche exhaustive permet de comprendre l’exposition réelle d’un système d’information, indépendamment de l’endroit où les workloads s’exécutent.
Cette visibilité s’accompagne d’une capacité d’analyse fine, rendue possible par une couverture de plus de 80 000 technologies. Cyberwatch inspecte à la fois les systèmes, les dépendances applicatives (Pip, npm, Gem…) et les composants embarqués dans les conteneurs.
De quoi garantir un niveau d’analyse homogène, qu’un workload soit hébergé dans le cloud ou dans un environnement on-premise.
Sécurité des conteneurs et de Kubernetes
Cyberwatch analyse les conteneurs selon une approche en deux temps. Une image Docker étant généralement construite autour d’un environnement minimal embarquant un composant applicatif, la plateforme commence par analyser l’ensemble des paquets du système d’exploitation sous-jacent. Cette première couche permet d’identifier les vulnérabilités affectant la base système de l’image.
Elle complète ensuite cette inspection par une détection fine des dépendances logicielles utilisées par l’application : bibliothèques, runtimes, dépendances issues des écosystèmes de développement comme Pip, Gem ou npm.
Cette double approche révèle simultanément les vulnérabilités affectant l’OS et celles provenant des composants applicatifs.
Au-delà de l’image elle-même, Cyberwatch étend sa couverture aux environnements d’exécution. La plateforme assure la découverte et l’inventaire des clusters Kubernetes (AKS, EKS, OpenShift, Rancher) ainsi que Docker Swarm et des registres d’images (Amazon ECR, Harbor, GitLab Registry). Les images nouvellement déployées peuvent être scannées automatiquement, assurant un contrôle continu tout au long du cycle de vie des workloads conteneurisés.
DevSecOps et intégration CI/CD
Pour finir, Cyberwatch s’intègre nativement dans les pratiques DevSecOps, grâce à la possibilité de s’interfacer avec un scanner Harbor et de s’insérer directement dans une pipeline CI/CD GitLab. Cette capacité renforce la prévention en amont du déploiement : les images non conformes ou vulnérables peuvent être bloquées avant leur mise en production.
C’est là toute la logique CNAPP : posture cloud, protection des workloads et sécurité des conteneurs ne sont plus traités en silos, mais dans une continuité cohérente et automatisée, du premier inventaire jusqu’à la remédiation.
En résumé
En 2026, de nombreuses organisations ont adopté une stratégie multicloud. Pourtant, beaucoup ne disposent toujours pas d’une vision fiable et à jour de ce qui s’exécute réellement dans leur environnement cloud, ni de ce qui est effectivement exposé.
L’approche CSPM répond précisément à ce défi : identifier en continu les ressources cloud, détecter les écarts de configuration, prioriser les risques réels et orchestrer la remédiation. Ce n’est plus une option, c’est un prérequis pour toute organisation sérieuse sur sa cybersécurité.
Avec Cyberwatch, cette approche devient pleinement opérationnelle :
- Un inventaire automatisé et centralisé de l’ensemble de vos ressources cloud (AWS, Azure, GCP, OpenStack), mis à jour en continu,
- Une priorisation contextuelle des vulnérabilités basée sur le CVSS-BTE, l’EPSS et les catalogues CISA KEV et CERT-FR ALE, pour concentrer les efforts là où le risque est réel,
- Un contrôle continu de la conformité via les CIS Benchmarks pour AWS, Azure, GCP et Microsoft 365,
- Une remédiation intégrée, traçable et connectée à vos outils existants (ServiceNow, Jira, GLPI, Intune…),
- Une couverture étendue aux workloads, conteneurs et clusters Kubernetes, pour une approche CNAPP véritablement unifiée.
Demandez une démo gratuite et évaluez concrètement votre exposition cloud.
FAQ
Quelle est la différence entre un CSPM et un scanner de vulnérabilités classique ?
Un scanner de vulnérabilités classique analyse les actifs que vous lui soumettez explicitement. Un CSPM va plus loin : il découvre automatiquement l’ensemble de vos ressources cloud, y compris celles que vous ignorez, analyse leurs configurations, et surveille leur conformité en continu, pas seulement à l’instant du scan.
Quelle est la différence entre le CSPM et le CWPP ?
Le CSPM se concentre sur la posture et les configurations des environnements cloud. Le CWPP (Cloud Workload Protection Platform) descend au niveau des workloads eux-mêmes (machines virtuelles, serveurs, conteneurs) pour les analyser et les protéger contre les vulnérabilités et les mauvaises configurations, qu’ils soient dans le cloud, on-premise ou hybrides.
Le CSPM aide-t-il à répondre aux exigences NIS2 ?
Oui. L’article 21 de la directive NIS2 impose aux entités concernées une série de mesures de gestion des risques cyber, parmi lesquelles la gestion des vulnérabilités, le contrôle des configurations, la sécurisation de la chaîne d’approvisionnement et la traçabilité des actions de remédiation. Le CSPM répond directement à plusieurs de ces exigences : inventaire continu des actifs, détection des écarts de configuration, priorisation contextuelle des vulnérabilités et suivi des correctifs appliqués. Il fournit également les éléments de preuve nécessaires en cas d’audit ou de contrôle par l’autorité compétente.
Le CSPM est-il réservé aux grandes entreprises avec des environnements multicloud complexes ?
Historiquement oui, mais les solutions actuelles se sont largement démocratisées. Cyberwatch, par exemple, est conçu pour s’adapter aussi bien aux grandes organisations qu’aux structures de taille intermédiaire, avec un déploiement rapide et une intégration dans les outils existants.
Quelle différence entre CSPM et CNAPP ?
Le CSPM se concentre sur la posture et les configurations cloud. Le CNAPP est une approche plus large qui l’englobe et y ajoute la protection des workloads, la sécurité des conteneurs et l’intégration DevSecOps. Le CSPM est une brique essentielle du CNAPP, mais le CNAPP va plus loin.
Comment le CSPM s’intègre-t-il dans une démarche DevSecOps ?
En déplaçant les contrôles de sécurité le plus tôt possible dans le cycle de développement : scan des images conteneurs avant déploiement, blocage des images vulnérables dans la pipeline CI/CD, intégration dans les outils des équipes (GitLab, Harbor…). L’objectif : faire de la sécurité une composante continue du cycle de vie applicatif, pas une étape finale.