CSPM vs cloud penetration testing: what each one finds and when you need which

By Kike Gandia · Co-Founder & CEO, OSCP

A CSPM (Cloud Security Posture Management) tool continuously checks the configuration of your cloud accounts against a set of rules and tells you what deviates. A cloud penetration test puts a human team to work doing what an attacker would do with whatever they find, and tells you how far they get. The two get confused because both produce a list of security problems in AWS, Azure or Google Cloud, but they answer different questions and neither replaces the other. This guide covers what each does well, what each misses, what the surrounding acronyms mean (CIEM, CWPP, KSPM, CNAPP), what regulations ask for and in which order to roll them out depending on your maturity.

What a CSPM is and what it actually does

A CSPM is a tool that connects to your cloud accounts, subscriptions or projects with read-only permissions, inventories resources through the provider's APIs and continuously compares their configuration with a set of rules: the CIS Benchmarks, the provider's own reference framework —such as the Microsoft Cloud Security Benchmark— or the controls of standards like ISO 27001 or PCI DSS. What it returns is a list of recommendations ranked by severity and, almost always, a posture score that shows the trend over time.

Typical examples of what it detects:

• A storage bucket or container with public access.
• The root account or an administrator without MFA.
• Activity logging (CloudTrail, the Azure activity log, Cloud Audit Logs) switched off in a region or project.
• A security group exposing SSH or RDP to the whole internet.
• Long-lived access keys nobody has rotated in months.
• Unencrypted databases or disks, or instances that still accept the old version of the metadata service.

The options fall into three families:

In every case the principle is the same: the tool reads configuration and evaluates it against rules. It does not try to exploit anything.

What a cloud penetration test is and which question it answers

A cloud penetration test is a point-in-time exercise, with scope and rules agreed in writing, in which a human team starts from a realistic assumption and tries to get as far as possible. The most common starting points are:

• External attacker: only what is visible from the internet, such as endpoints, buckets, exposed functions or subdomains pointing to resources that no longer exist.
• Leaked credential: a developer's access key published in a repository or stolen from a laptop.
• Compromised workload: an application with a vulnerability that gives code execution or file reads on a machine, a container or a serverless function.
• Low-privilege identity: a user or role with limited permissions, to measure whether it can escalate.

The question it answers is not “what is misconfigured” but “what can an attacker achieve with what is there”: read customer data, obtain production credentials, move into other accounts in the organisation or take over the whole account. The output is attack chains demonstrated with evidence and a remediation plan prioritised by real impact.

The underlying difference fits in one sentence: a CSPM evaluates each resource against a rule; a pentest evaluates what the resources allow when combined.

CSPM vs cloud penetration testing: comparison

Read by column, the table explains why the two coexist: a CSPM provides coverage and continuity; a pentest provides depth and context.

What a CSPM does better than any pentest

It would be wrong to present the pentest as the “good” option and the CSPM as the “cheap” one. There are things a posture tool does better and that no point-in-time exercise can match:

• Catching drift. A pentest is a snapshot; configuration changes with every deployment. If someone opens a port to the internet on a Friday to debug a problem and forgets to close it, the CSPM will see it as soon as it evaluates; last year's pentest never will.
• Covering everything. Dozens of accounts, every region and the projects nobody remembers creating. A pentest is always scoped.
• Producing compliance evidence. A continuous report against a control framework is what an ISO 27001 or ENS auditor asks for to show that configuration is monitored, not just reviewed once.
• Providing an inventory. Knowing which resources exist is the first control. Many organisations discover services they did not know they had through their CSPM.
• Finding the obvious cheaply. It makes no sense to pay for a pentester's hours to discover that the root account has no MFA or that activity logging is off.

That is why, if you have nothing today, the logical order is to switch on the native CSPM or run Prowler, fix what is critical and then commission the pentest. That way the pentest spends its time on what only a person can find.

What a CSPM cannot see and a pentest can

A CSPM's limitations are not flaws of a particular product: they come from the way it works, which is reading configuration and applying rules.

• Attack chains. Three medium-severity findings can add up to a critical one. For example: an application with an SSRF vulnerability, an instance that still accepts version 1 of the metadata service and an attached role that can read every bucket. The CSPM flags the last two among hundreds of recommendations; it does not even see the SSRF, because it lives in the code. Together, they let an attacker on the internet download the data.
• IAM privilege escalation. Some permissions are only dangerous in combination. Whoever can create a function, assign it a role (iam:PassRole) and invoke it can run code with that role's privileges even if their own user looks limited. The most advanced platforms model these paths as a graph, but they infer them from the configuration they can read; a pentest checks whether the path is genuinely exploitable, taking into account organisation policies, permission boundaries and conditions.
• What runs on top of the infrastructure. SSRF, injection, broken authorization in the API or insecure deserialisation in a function: the CSPM knows the function exists, not what it does.
• Secrets outside connected resources. Keys in Git history, in CI/CD pipeline variables, in published container images or in logs. Some platforms scan part of this, but only where they reach.
• What is not connected. Test accounts created outside the organisation, the environment of a supplier with access to your account, or the inside of a Kubernetes cluster —RBAC, pods, secrets— if the tool does not assess Kubernetes.
• Badly scoped trust. Roles that can be assumed from another account without an external ID, or identity federations —such as GitHub Actions access via OIDC— whose condition lets any repository obtain credentials.
• Your detection capability. A pentest checks whether GuardDuty, Defender for Cloud or your SOC raise an alert when someone enumerates permissions, creates keys or downloads data. A CSPM can tell you the detection service is enabled, not whether anyone is watching the alerts.

CSPM, CIEM, CWPP, KSPM, DSPM and CNAPP: the glossary

An alphabet soup has grown around CSPM. It is worth knowing the terms to understand what the tool you already have, or the one you are being offered, actually covers:

Two caveats. First, every vendor interprets the acronyms in its own way; what matters is which layers the tool covers and how deeply, not the label. Second, none of them is a pentest: they all observe configuration and state, and none attempts the attack the way an adversary would.

False positives, prioritisation and alert fatigue

The practical problem with a CSPM is rarely that it detects too little; it is that it detects too much. In an organisation with several accounts it is normal for the first assessment to return hundreds of recommendations, and many have no real impact in that context:

• A public bucket serving a public website's static files is intentional.
• An unrotated key in an empty lab account is not the same as one in the production account.
• An open security group in front of a load balancer that only serves HTTPS is the design, not a mistake.

When everything is “high”, nothing is, and teams end up ignoring the dashboard. This is where the two complement each other: the pentest identifies which of those recommendations are part of a real chain and which are noise in your environment, which lets you tune the CSPM with documented exceptions and severities that match your context.

The relationship also works the other way round. Every pentest finding should end up as something that prevents it from happening again: a custom rule in the CSPM, an organisation policy (SCPs in AWS, Azure Policy, organisation policies in Google Cloud) or a check in the infrastructure-as-code pipeline. If the pentest report is filed away without that, the same flaw will reappear in the next deployment.

How to combine them: a cycle that works

In practice, this is the order that gives the best results:

• Visibility: native CSPM or Prowler across every account, with activity logs centralised in an account development teams cannot write to.
• Fix the obvious: unintended public access, MFA on root and administrator accounts, long-lived keys, logging switched off, unprotected metadata.
• A pentest focused on identities and chains: using the leaked credential, compromised workload and low-privilege identity scenarios, which is where a CSPM falls short.
• Turn findings into guardrails: organisation policies, custom rules and checks in the infrastructure code.
• Retest: check that each fix breaks the chain, not just the isolated finding.
• Repeat: after major changes —a new architecture, a migration, a new production account, an acquisition— and as often as your regulatory framework or your customers require.

And depending on the starting point:

What regulations and customers ask for

No regulation requires you to buy a CSPM, and almost none mentions cloud penetration testing by that name, but several ask for the two things they provide: continuous monitoring of configuration and verification that controls work.

• ENS (Spain's National Security Framework, Royal Decree 311/2022): measure op.nub.1, “Protection of cloud services”, requires that, when third-party cloud services are used, the systems behind them either conform to the ENS or meet a CCN-STIC guide that includes, among other requirements, a “penetration testing audit”. At medium and high categories it adds certification of the service and, at high, security configurations following the CCN guides.
• ISO/IEC 27001:2022: control 5.23 covers information security for the use of cloud services and 8.8, the management of technical vulnerabilities. A CSPM is good evidence of continuous monitoring; a pentest, that vulnerabilities are actively sought.
• NIS2: Article 21 requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures. A posture dashboard shows controls exist; a pentest shows they work.
• DORA: the digital operational resilience testing programme expressly includes penetration testing among the tests financial entities must perform on their systems, including those hosted in the cloud.
• Enterprise customers and due diligence: security questionnaires usually ask for a recent pentest report with its scope. A screenshot of the CSPM dashboard does not replace it.

FAQ

If we already have a CSPM, do we also need a cloud penetration test?

If your environment holds data or services that matter, yes. The CSPM tells you which configurations deviate from a baseline; it does not check whether an attacker can chain them, it does not review the application running on top and it does not test your detection. The pentest answers exactly that, and it also helps prioritise the CSPM's noise.

Can a pentest replace a CSPM?

No. A pentest is a snapshot of one moment and a limited scope; configuration changes with every deployment. Without a tool monitoring continuously, a mistake introduced the week after the pentest can stay open until the next one.

Is there a free CSPM to get started?

Yes. Microsoft Defender for Cloud includes Foundational CSPM at no cost, which can also assess connected AWS accounts and Google Cloud projects, and Prowler is an open-source tool covering all three providers. Advanced features, such as attack path analysis, are usually in the paid plans.

Don't tools with attack path analysis already do what a pentest does?

They do something useful and different: they infer possible paths from the configuration they can read, which helps a lot with prioritisation. But they do not check whether the path is exploitable in practice, they do not see vulnerabilities in the deployed code or anything outside the connected accounts, and they do not measure whether anyone reacts when it is attempted.

How often should we run a cloud pentest if we already have a CSPM?

As a rule of thumb, once a year and always after a major change: a new architecture, a migration, a new production account or integrating another company. If a specific framework applies to you, such as PCI DSS, DORA or the ENS, or a customer requires it by contract, that frequency takes precedence.

Does the pentester also use posture tools?

Yes, in a white-box pentest it is common to start by running a posture tool such as Prowler and enumeration tools such as CloudFox to get a quick overview. But that is the starting point, not the deliverable: the value lies in what comes next, which is checking what each finding allows when combined with the others.

Related service

cloud penetration testing on AWS, Azure and Google Cloud

Related content

• The most common cloud misconfigurations
• AWS penetration testing: what is tested and what AWS allows
• Kubernetes security: common mistakes and how it is audited
• Pentesting vs vulnerability assessment
• Continuous vulnerability assessment
• ENS compliance, including cloud services

Sources

• NSA, with CISA — Top Ten Cloud Security Mitigation Strategies (2024)
• Microsoft Learn — What is CSPM in Microsoft Defender for Cloud (Foundational CSPM and Defender CSPM)
• Spanish Royal Decree 311/2022, National Security Framework (BOE) — measure op.nub.1, protection of cloud services (Spanish)

Request a penetration test of my cloud environment