In 2024, organizations experienced an average of nine cloud security incidents. And nearly nine out of ten report that this number is increasing year over year (source: IDC / Microsoft study)
Behind these figures lies a simple reality: every resource added to the cloud is a new surface to defend. Some drifts easily fly under the radar: a Security Group modified in a rush for debugging, then never reconfigured, can be enough to leave a service exposed indefinitely without anyone noticing.
This is exactly the type of silent, mundane, yet critical drift that CSPM (Cloud Security Posture Management) is designed to fix: continuously identifying your exposed resources, detecting configuration gaps, prioritizing risks, and orchestrating remediation.
In this article, we break down CSPM: why it has become essential, and how Cyberwatch enables you to implement it while integrating workload protection (CWPP) and container security for a comprehensive CNAPP approach.
What is CSPM and why has it become essential?
Definition and key principles
CSPM is a cybersecurity approach designed to continuously assess, monitor, and improve the security posture of cloud environments.
Its fundamental principle: ensuring that an organization's cloud resources are correctly configured, exposed only as much as necessary, and compliant with security best practices.
What cloud exposure actually entails
An organization's cloud surface is much broader than a simple inventory of virtual machines.
It encompasses all resources deployed across various providers (AWS, Azure, GCP, OpenStack), as well as:
- Configurations associated with each service,
- Identities and access rights,
- Data stored in the cloud (S3 buckets, databases, backups, Azure Blob storage accounts, etc.),
- Resources publicly exposed to the Internet, sometimes unintentionally,
- Network settings (security rules, subnets, interconnections),
- Applied security mechanisms (encryption, authentication, logging).
Cloud exposure refers to anything within the cloud environment that is accessible, misconfigured, or insufficiently protected, particularly with regard to best practices and security frameworks such as CIS Benchmarks.
Why the cloud creates new blind spots
Unlike on-premises infrastructure, cloud environments are neither static nor centralized. The massive adoption of multicloud (public, private, or hybrid) multiplies entry points and fragments visibility: resources are spread across multiple platforms, each with different management models.
But what really makes the situation worse is speed. Modern architectures (containers, Kubernetes orchestrators, CI/CD pipelines) introduce resources with lifecycles measured in minutes, sometimes seconds.
A Kubernetes pod can appear, be exposed, and then disappear before it has even been inventoried. An image deployed automatically via a CI/CD pipeline can introduce a vulnerability before any team has had time to identify it.
In addition to this dynamic complexity, there are more traditional, yet equally critical, blind spots:
- Test environments that remain active long after they are used
- Access rights that proliferate without regular review
- Cloud shadow IT that completely escapes the security team's notice
Without a dedicated tool, it becomes impossible to maintain a reliable and up-to-date view of what is actually exposed.
Increasingly stringent regulatory requirements
On top of these technical challenges, there is growing regulatory pressure. The NIS2 directive, applicable since October 2024, imposes enhanced cyber risk management obligations with penalties of up to 2% of global annual turnover.
ISO 27001, GDPR, SecNumCloud: frameworks directly affecting the security of cloud environments are multiplying and now require continuous traceability, far beyond the annual audit.
In this context, CSPM becomes a tool for compliance as much as for operational security.
CSPM in practice: the 4 key functions
1) Automated cloud resource inventory
You cannot secure what you cannot see.
The primary function of CSPM is therefore to automatically identify all assets deployed in the cloud (virtual machines, containers, managed services, storage accounts, network resources, etc.) regardless of the provider(s).
This inventory must be dynamic: a resource created today must appear within the monitored scope without manual intervention. This is the essential prerequisite for maintaining a reliable map in environments where deployments happen continuously.
2) Risk detection and prioritization
Once assets are identified, CSPM solutions analyze their actual exposure. This involves detecting known vulnerabilities (CVEs) affecting them, as well as identifying configuration gaps (an unnecessarily open port, an obsolete protocol, an unprotected access key, etc.).
But detection is not enough: you need to know what to fix first.
In a cloud environment where vulnerabilities number in the thousands, prioritization based solely on raw CVSS scores is insufficient. It must incorporate context: the business criticality of the asset in question, its level of network exposure, and the actual probability of the flaw being exploited.
3) Continuous compliance monitoring
The CSPM approach then involves continuously monitoring cloud resource configurations to detect deviations from recognized security standards, primarily CIS Benchmarks, or the organization's internal policies.
This continuous control is fundamental: a configuration that is compliant today may not be tomorrow, following an update, a manual change, or a new deployment. Annual audits are no longer enough.
4) Remediation and patch orchestration
The final function of CSPM is to turn detection into action. This means providing precise, actionable recommendations. It is not just about flagging an anomaly, but indicating exactly which version to patch, which configuration to change, or which access to revoke.
In modern environments, this remediation must be easily orchestrated: it should integrate with existing ticketing tools and patch management solutions, fitting into IT team workflows without creating additional friction.
CSPM with Cyberwatch: from discovery to remediation
Multi-cloud discovery (AWS, Azure, GCP, OpenStack)
Visibility into cloud assets is the starting point for any CSPM initiative. Cyberwatch addresses this through native discovery mechanisms capable of automatically identifying machines deployed across major cloud providers.
In detail:
- AWS discovery : Cyberwatch queries the Amazon EC2 API directly to list all instances and their metadata (ID, IP, status, tags). The solution uses an IAM role with read-only permissions, in strict adherence to the principle of least privilege. It is also possible to segment discovery by IAM role to compartmentalize environments.
- Azure discovery : via the Azure Resource Manager API, Cyberwatch inventories virtual machines and their attributes (name, IP, resource group) using a service account with read-only permissions on compute resources.
- Google Cloud Platform discovery : discovery relies on the GCP API and allows for listing VMs and their metadata (zone, IP, status) by using a service account with read permissions on Compute Engine.
- OpenStack Discovery : for private infrastructures, Cyberwatch connects to the OpenStack API to retrieve instances and their characteristics. This capability is particularly useful for organizations that combine public and private clouds.
Beyond this API-based discovery, Cyberwatch can also leverage connection mechanisms adapted to the technical contexts of cloud resources. For example, for an AWS instance, a standard SSH connector can be supplemented by access via AWS Systems Manager (SSM). This approach allows for interaction with certain machines without direct network exposure, which enhances both security and operational flexibility.
Creating a Cloud project asset also triggers an automatic inventory of all associated managed services and resources: storage services (S3, Cloud Storage), managed databases (RDS), network resources, and IAM users and roles.
All these assets (virtual machines, managed services, identities) are thus centralized in an exhaustive, continuously updated inventory. This is the essential prerequisite for any CSPM approach: without this complete visibility, exposed or misconfigured resources can go unnoticed, and the attack surface cannot be truly controlled.
3D Prioritization: CVSS-BTE, EPSS, CISA KEV
Cyberwatch does more than just detect vulnerabilities: the platform prioritizes them using a three-dimensional contextual approach.
Prioritization is based on a criticality policy specific to each asset, defined according to security requirements (Confidentiality, Integrity, Availability). This policy uses the environmental metrics of the CVSS standard (v2, v3, v4) to calculate an adapted score, the CVSS-BTE, which incorporates both the intrinsic severity of the vulnerability and its potential impact on the asset in question.
In practical terms, a server that is completely isolated from the network may have the criticality of its remotely exploitable vulnerabilities automatically downgraded. Conversely, a flaw affecting a system exposed in production will maintain a high priority level.
This contextualization is supplemented by two additional indicators:
- The EPSS score, which reflects the probability of actual exploitation in the wild,
- Presence in recognized reference catalogs such as CISA KEV or CERT-FR ALE, which flag actively exploited vulnerabilities.
We no longer reason in terms of global theoretical severity, but in terms of real risk for a given asset.
CIS Benchmark compliance for cloud environments
Cyberwatch provides continuous monitoring of cloud configurations via CIS Benchmarks, covering AWS, Microsoft Azure, Google Cloud Platform, and Microsoft 365. In practice, this translates into hundreds of hardening rules verified automatically and continuously.
Here are some concrete examples of the controls applied:
For Microsoft Azure:
- CIS-Azure-4.1: secure transfer required enabled on storage accounts
- CIS-Azure-4.4: periodic regeneration of storage account access keys
- CIS-Azure-4.6: public network access disabled for storage accounts
- CIS-Azure-7.1: RDP access from the internet evaluated and restricted
For Google Cloud Platform:
- CIS-GCP-3.1: default network removed from projects
- CIS-GCP-3.3: DNSSEC enabled for Cloud DNS
- CIS-GCP-4.1: use of the default service account on instances prohibited
- CIS-GCP-4.3: project-wide SSH key blocking enabled for VMs
For AWS:
- CIS-AWS-1.4: verification that no access keys exist for the root account
- CIS-AWS-1.5: MFA enabled for the root account
- CIS-AWS-1.8: password policy implemented with a minimum length of 14 characters
- CIS-AWS-1.12: dedicated support role created for secure incident management
Beyond standard frameworks, Cyberwatch also allows you to define custom rules to align with each organization's internal policies.
Integrated remediation and ITSM integrations
Cyberwatch provides precise corrective actions based on official vendor bulletins. Each recommendation specifies the corrected version or the patch to apply, taking into account system specifics, including distribution-specific Linux branches.
For implementation, the platform relies on native system mechanisms:
- Linux: using package managers (APT, YUM, DNF) to apply patches,
- Windows: leveraging Windows Update to deploy the necessary KBs,
- Third-party Microsoft products: using winget to install or update applications.
Cyberwatch also integrates with existing IT team tools: patch management solutions (WAPT, Ivanti, Intune) and ticketing tools (ServiceNow, Jira, GLPI). A validated vulnerability can thus be automatically transformed into a pre-filled ticket, including all relevant context: affected asset, criticality level, and recommended fix.
From CSPM to CNAPP: how Cyberwatch unifies security for your cloud environments
While Cyberwatch fully covers the needs of a modern CSPM, the platform doesn't stop there.
And for good reason: today's cloud environments are no longer limited to virtual machines; containers, Kubernetes clusters, CI/CD pipelines, and hybrid workloads coexist in increasingly complex architectures.
To address this, Cyberwatch integrates CWPP (Cloud Workload Protection Platform) capabilities, laying the foundation for a truly unified CNAPP (Cloud-Native Application Protection Platform) strategy.
Workload protection with CWPP
CWPP aims to protect workloads (virtual machines, servers, containers, infrastructure components) against vulnerabilities, misconfigurations, and the threats that can arise from them.
Where CSPM focuses on cloud posture, CWPP drills down to the level of the workloads themselves, whether they are cloud-based, on-premise, or hybrid.
Cyberwatch addresses this challenge by unifying the inventory, classification, and analysis of workloads within a single platform, regardless of their nature or location:
- Local infrastructure: hypervisors, servers, network appliances, via dedicated discovery covering VMware vSphere/ESXi, Microsoft Hyper-V, Proxmox, Nutanix, Active Directory, Fortinet, Stormshield…
- Public cloud: AWS, Azure, GCP, OpenStack, using the same discovery mechanisms described in the CSPM section.
- Internet exposure: via DNS enumeration, Certificate Transparency, and WHOIS data, Cyberwatch identifies publicly exposed domains, services, or machines—sometimes poorly referenced or forgotten—that can represent a significant attack surface.
This comprehensive approach makes it possible to understand the actual exposure of an information system, regardless of where the workloads are running.
This visibility is accompanied by a fine-grained analysis capability, made possible by a coverage of over 80,000 technologies. Cyberwatch inspects systems, application dependencies (Pip, npm, Gem, etc.), and components embedded within containers.
This ensures a consistent level of analysis, whether a workload is hosted in the cloud or in an on-premises environment.
Container and Kubernetes security
Cyberwatch analyzes containers using a two-step approach. Since a Docker image is generally built around a minimal environment containing an application component, the platform begins by analyzing all packages in the underlying operating system. This first layer identifies vulnerabilities affecting the image's base system.
It then complements this inspection with a precise detection of the software dependencies used by the application: libraries, runtimes, and dependencies from development ecosystems such as Pip, Gem, or npm.
This dual approach simultaneously reveals vulnerabilities affecting the OS and those originating from application components.
Beyond the image itself, Cyberwatch extends its coverage to runtime environments. The platform provides discovery and inventory for Kubernetes clusters (AKS, EKS, OpenShift, Rancher) as well as Docker Swarm and image registries (Amazon ECR, Harbor, GitLab Registry). Newly deployed images can be scanned automatically, ensuring continuous control throughout the lifecycle of containerized workloads.
DevSecOps and CI/CD integration
Finally, Cyberwatch integrates natively into DevSecOps practices, thanks to its ability to interface with a Harbor scanner and plug directly into a GitLab CI/CD pipeline. This capability strengthens prevention before deployment: non-compliant or vulnerable images can be blocked before they reach production.
This is the core logic of CNAPP: cloud posture, workload protection, and container security are no longer treated in silos, but as a coherent and automated continuum, from the initial inventory to remediation.
In summary
By 2026, many organizations have adopted a multicloud strategy. Yet, many still lack a reliable, up-to-date view of what is actually running in their cloud environment, or what is truly exposed.
The CSPM approach addresses this challenge precisely: continuously identifying cloud resources, detecting configuration gaps, prioritizing real risks, and orchestrating remediation. It is no longer an option; it is a prerequisite for any organization serious about its cybersecurity.
With Cyberwatch, this approach becomes fully operational:
- An automated and centralized inventory of all your cloud resources (AWS, Azure, GCP, OpenStack), updated continuously,
- Contextual vulnerability prioritization based on CVSS-BTE, EPSS, and the CISA KEV and CERT-FR ALE catalogs, to focus efforts where the risk is real,
- Continuous compliance monitoring via CIS Benchmarks for AWS, Azure, GCP, and Microsoft 365,
- Integrated, traceable remediation that connects to your existing tools (ServiceNow, Jira, GLPI, Intune, etc.),
- Extended coverage for workloads, containers, and Kubernetes clusters for a truly unified CNAPP approach.
Request a free demo and get a concrete assessment of your cloud exposure.
FAQ
What is the difference between a CSPM and a traditional vulnerability scanner?
A traditional vulnerability scanner analyzes the assets you explicitly submit to it. A CSPM goes further: it automatically discovers all your cloud resources, including those you are unaware of, analyzes their configurations, and monitors their compliance continuously, rather than just at the moment of a scan.
What is the difference between CSPM and CWPP?
CSPM focuses on the posture and configuration of cloud environments. CWPP (Cloud Workload Protection Platform) drills down to the workload level (virtual machines, servers, containers) to analyze and protect them against vulnerabilities and misconfigurations, whether they are in the cloud, on-premises, or hybrid.
Does CSPM help meet NIS2 requirements?
Yes. Article 21 of the NIS2 directive requires affected entities to implement a series of cyber risk management measures, including vulnerability management, configuration control, supply chain security, and traceability of remediation actions. CSPM directly addresses several of these requirements: continuous asset inventory, detection of configuration drift, contextual vulnerability prioritization, and tracking of applied patches. It also provides the necessary evidence for audits or inspections by the competent authority.
Is CSPM only for large companies with complex multi-cloud environments?
Historically, yes, but current solutions have become widely accessible. Cyberwatch, for example, is designed to adapt to both large organizations and mid-sized structures, with rapid deployment and integration into existing tools.
What is the difference between CSPM and CNAPP?
CSPM focuses on cloud posture and configuration. CNAPP is a broader approach that encompasses CSPM while adding workload protection, container security, and DevSecOps integration. CSPM is an essential building block of CNAPP, but CNAPP goes further.
How does CSPM integrate into a DevSecOps approach?
By shifting security controls as early as possible in the development cycle: scanning container images before deployment, blocking vulnerable images in the CI/CD pipeline, and integrating with team tools (GitLab, Harbor, etc.). The goal is to make security a continuous component of the application lifecycle, not a final step.
