Cloud VAPT tests identity, configuration and API surfaces, not just IP ranges and open ports. On AWS, Azure and GCP an attacker rarely breaches a firewall; they find a leaked access key or an over-permissioned role and walk in through the API. That gap shows up constantly in cloud VAPT scopes across the UAE and wider GCC: a test that only scans public IPs will pass while public buckets and idle service accounts with admin rights sit completely untested.
- Cloud attack paths run through IAM roles, storage permissions and APIs, not network segments
- A scope built around public IP ranges misses the misconfigurations that actually get exploited
- The UAE's NESA Essential Cybersecurity Controls require periodic testing but do not prescribe a cloud-native methodology, so a weak scope can still pass an audit
- Automated CSPM tools flag misconfigurations at volume; only manual testing proves which ones chain into an exploitable path
Why On-Prem VAPT Method Does Not Map to Cloud
Traditional VAPT assumes a fixed perimeter: a range of public IPs, a DMZ, a handful of internal segments. You scan it, find outdated services and open ports, exploit what you can, and write it up. Cloud infrastructure breaks that model in three specific ways.
The shared responsibility model moves most of the exploitable surface onto the customer. The cloud provider secures the hypervisor, the physical data centre and the managed control plane. Everything above that, identity policies, storage permissions, network security groups, workload configuration, is the customer's problem. Most of what gets exploited in cloud breaches across UAE and GCC engagements is a configuration error on the customer side of that line, not a flaw in the provider's infrastructure.
Resources are ephemeral. Containers and serverless functions spin up and terminate in seconds. A point-in-time scan describes a snapshot that may already be stale by the time the report reaches the client.
Configuration is API-driven. Every change goes through an API call, usually through a CI/CD pipeline or a Terraform apply. That means posture is not a fixed asset list you can inventory once a year, it is a moving target that changes with every deployment. A single misconfigured policy pushed at 3am can open an exposure that a scan run the week before would never have caught.
Put those three together and the conclusion is simple: the attack surface in cloud is not defined by IP ranges. It is defined by configuration, and configuration is controlled by whoever holds API access. That is an identity problem before it is a network problem.
What a Cloud-Native VAPT Actually Has to Cover
Identity Is the Perimeter
An attacker does not need to compromise a domain admin account to get useful access in a cloud environment. One over-permissioned service account, one IAM role with a wildcard resource policy, or one access key hardcoded into a public repository is often enough to reach data that should have been walled off. Privilege escalation in cloud usually looks like role chaining: assume role A, which can pass a policy to role B, which can read the secrets store, which contains the credentials for role C. None of that shows up in a port scan.
The Attack Surface Checklist
A cloud VAPT scope that is worth paying for covers:
- IAM privilege escalation paths and role chaining across accounts
- Misconfigured storage (S3, Azure Blob, Google Cloud Storage) with public or overly broad access policies
- Container and orchestration risks: Kubernetes RBAC, exposed dashboards, pod escape paths
- Serverless function injection and excessive execution-role permissions (Lambda, Cloud Functions, Azure Functions)
- API gateway exposure, including missing authentication on internal-only endpoints
- Logging and monitoring gaps that would let an intrusion go unnoticed (CloudTrail, Azure Monitor, Cloud Logging disabled or unshipped)
- Network security group and firewall rule misconfigurations
- CI/CD pipeline credentials and Infrastructure-as-Code secrets
Why Automated Scanning Alone Undersells the Risk
Tools like Prowler, ScoutSuite, CloudSploit and the cloud providers' own posture tools (GuardDuty, Defender for Cloud, Security Command Center) check configuration against known benchmarks, usually the CIS Foundations Benchmark for the relevant provider. That is useful and it should run continuously, not once a year.
What it cannot do is confirm exploitability or chain findings together. A CSPM tool reports a public S3 bucket as one medium finding, an over-permissioned Lambda execution role as another, and a missing MFA requirement on a service account as a third. Manual testing is what shows those three findings combine into a single path: the Lambda role can generate presigned URLs against the bucket, the service account can invoke the Lambda, and nothing requires MFA to get there. That is a critical finding hiding inside three mediums, and no scanner surfaces the connection on its own.
The volume problem compounds this. Automated scans against a mature cloud estate routinely produce more findings than any team can triage in a reasonable cycle, and a large share are false positives, accepted risk, or theoretical conditions that require an unrealistic prerequisite. Without a tester validating which findings are actually reachable, teams either drown in noise or start ignoring the tool.
The Compliance Trap: Passing an Audit Is Not the Same as Being Secure
Compliance-driven VAPT tends to test what is declared in scope, not what actually exists. If a database sits behind a public endpoint but was never added to the asset inventory the client gave the tester, it does not get tested, and the report can still say "no critical vulnerabilities found" and be technically accurate.
Annual or biannual testing cycles are also a poor match for how fast cloud configuration changes. A misconfiguration introduced by a routine deployment can sit exposed for the entire gap between test cycles, invisible until the next scheduled VAPT happens to catch it. Continuous configuration monitoring closes that gap for known misconfiguration classes; periodic manual testing is still needed for the exploit chains and business-logic issues that a rules-based scanner cannot express. Neither replaces the other.
Cloud VAPT vs Traditional VAPT
| Dimension | Traditional VAPT | Cloud VAPT |
|---|---|---|
| Primary attack surface | Network, OS, applications | Identity, APIs, configuration |
| Core tooling | Nessus, Nmap, Burp Suite | CSPM tools, cloud-native CLIs, custom scripts against provider APIs |
| Scope definition | IP ranges, domains | Cloud accounts, IAM roles, storage resources, service inventories |
| Privilege escalation | OS exploits, credential stuffing | IAM policy misconfiguration, role chaining, trust relationship abuse |
| Typical cadence | Annual or biannual | Continuous monitoring plus periodic manual testing |
| Shared responsibility | Not a factor | Central to what is even in scope |
The tooling difference matters less than the scoping difference. A tester who runs Nessus or Qualys VMDR against a list of public IPs and calls it a cloud assessment has not tested the cloud. Those platforms are strong at what they are built for, network and host vulnerability scanning, but they were never designed to trace an IAM trust relationship or evaluate a storage bucket policy.
Building a Cloud VAPT Programme That Actually Reduces Risk
1. Scope from Architecture, Not Legacy Assumptions
Build the scope with the cloud architects and the DevOps team, not from a spreadsheet of IP ranges handed to procurement. Use the provider's own inventory tooling, AWS Organizations, Azure Management Groups, the GCP resource hierarchy, to surface accounts and projects that never made it into the official register. If a resource is not in the inventory, it will not be tested, and shadow cloud accounts spun up by a project team outside central governance are one of the most common gaps in practice.
2. Test Against Real Attacker Tactics, Not a Generic Checklist
The MITRE ATT&CK matrix for cloud maps the tactics that actually get used: initial access through exposed credentials or public storage, execution through malicious container images or function code, persistence through backdoored IAM users or hidden API keys, privilege escalation through overly broad policies, defence evasion through disabling or diverting audit logs, and exfiltration through direct pulls from storage or data warehouses. A scope built around these tactics produces findings a defender can act on. A scope built around a generic vulnerability checklist produces a list of CVEs that mostly do not apply to a serverless or managed environment.
3. Embed Testing Into the Deployment Pipeline
Shift left where it is cheap to do so. Policy-as-code tools such as Checkov, tfsec or OPA can catch a misconfigured Terraform module before it ever deploys, at effectively zero marginal cost per check. That does not replace manual testing; it reduces the volume of avoidable findings a human tester has to spend time on. Pair continuous pipeline checks with a manual VAPT cycle run at least quarterly, and always after a material architecture change, a new production account, or a new third-party integration with high-privilege access.
4. Require Exploitability, Not Just a Findings List
A report of "127 findings, ranked by CVSS" is not a deliverable, it is raw output. Ask for the exploit chain: which finding, combined with which other finding, produces access to which data or system. A report that can show the path from a misconfigured bucket policy to administrative access is worth more than one that lists a hundred unconnected medium-severity items.
Evaluating a Cloud VAPT Provider
Whether you are based in Dubai or elsewhere in the GCC, a short list of questions separates a provider that understands cloud from one repackaging a network pentest:
- Do the testers hold cloud-specific credentials (AWS Certified Security Specialty, Microsoft SC-100, GCP Professional Cloud Security Engineer) alongside offensive certifications like OSCP or OSWE?
- Can they walk through a sample finding that shows an actual exploit chain, not just a vulnerability description and a CVSS score?
- Do they test IAM privilege escalation and cross-account or cross-tenant lateral movement, specifically?
- How do they handle multi-cloud environments where the same organisation runs workloads on more than one provider?
- Can testing integrate with an existing CI/CD pipeline rather than running as an isolated annual exercise?
What to Ask for Before You Sign the Statement of Work
For UAE and GCC organisations, scope the engagement to identity, storage, containers, serverless and API surfaces explicitly, by name, in the contract, not as an assumed extension of "penetration testing." Require the report to demonstrate exploit chains, not just list findings. Pair it with continuous CSPM monitoring so configuration drift between test cycles does not go unnoticed for months. And treat a clean NESA or ISO audit result as a floor, not evidence of security: the standard tells you testing happened, not that it tested the parts of your environment attackers actually use. Related reading on the difference between managing findings and reducing exposure is in the cloud security overview and the VAPT service page.
