Prove Your Cloud
Actually Holds
CSPM tooling tells you what is misconfigured. We tell you which of those misconfigurations chain into a working attack path. AWS, Azure, GCP and OCI — IAM graph analysis, Kubernetes admission testing, serverless + IaC scanning, all mapped to CIS Benchmarks, NIST 800-204D and MITRE ATT&CK Cloud.
- AWS · Azure · GCP · OCI
- provider coverage
- IAM attack graph
- every path, per-edge PoC
- EKS / AKS / GKE
- Kubernetes admission testing
- 30 days
- free retest window
Service overview
An AxVeil cloud security assessment combines posture review with adversary-led validation. We start with a read-only audit role and extract the full configuration of every account, subscription, project or compartment in scope — IAM policies, network paths, storage permissions, KMS / Key Vault usage, compute hardening, container registries, Kubernetes RBAC, serverless triggers, IaC modules. That baseline is compared against the CIS Foundations Benchmark for the target provider, cross-referenced with the AWS Well-Architected Security Pillar, the Microsoft Cloud Adoption Framework Secure baseline, the Google Cloud Architecture Framework Security pillar, the CSA Cloud Controls Matrix v4, and NIST SP 800-204D where the engagement touches the CI/CD pipeline.
What separates an AxVeil engagement from CSPM output is the second half: we model exploitable paths through the configuration. The IBM Cost of a Data Breach Report 2024 attributes 40% of breaches to data stored across multiple environments — cloud-public, cloud-private, on-prem — and the median dwell time for a cloud-resident breach was 277 days. The recurring failure mode is not a single missing checkbox. It is a chain: an overly broad cross-account trust, an EC2 instance role with iam:PassRole, a Lambda with secret material in its environment, a Kubernetes service account bridged to a powerful IAM role through IRSA. CSPM tools flag the individual nodes; the engagement maps the graph.
Engagements scope cleanly to the standard you need to satisfy. SaaS targeting SOC 2 Type 2 typically asks for an AWS or GCP CSPM review plus IAM attack-path mapping on the production account. PCI DSS v4.0 cloud environments ask for segmentation testing across cardholder data environment boundaries and quarterly external coverage. RBI-regulated entities ask for the cyber security framework's annual penetration test extended to cover the cloud control plane. Kubernetes-heavy estates ask for cluster-by-cluster RBAC and admission-controller review against the NSA / CISA Kubernetes Hardening Guidance.
Four sub-offerings
CSPM gap review
Read-only configuration capture across every account / subscription / project / compartment in scope, evaluated against the CIS Foundations Benchmark for the target provider. Cross-referenced with the AWS Well-Architected Security Pillar, Microsoft CAF Secure baseline, Google Cloud Architecture Framework Security pillar and CSA Cloud Controls Matrix v4. Output is a prioritised gap register with each finding tagged to its control, blast radius and remediation owner.
IAM attack-path mapping
Full IAM graph extraction across AWS IAM, Azure RBAC + Entra ID, GCP IAM and OCI IAM. Cross-account / cross-tenant trust relationships, sts:AssumeRole and OIDC federation chains, iam:PassRole edges, lambda:InvokeFunction-as-privesc, condition-key bypass and confused-deputy paths. Output is a directed-graph diagram showing every path from an external or low-trust principal to a sensitive resource, with a PoC command per edge.
Container & Kubernetes testing
EKS, AKS, GKE, OKE and self-managed Kubernetes. RBAC role-binding analysis, admission controller review (Pod Security Standards, OPA / Gatekeeper, Kyverno), service-account-token abuse, network policy validation, container image registry and provenance review, and the IAM bridge between Kubernetes service accounts and cloud roles (IRSA, Workload Identity, Azure AD pod identity). Findings reference the CIS Kubernetes Benchmark v1.9 and the NSA / CISA Kubernetes Hardening Guidance.
Serverless + IaC scanning
Lambda / Azure Functions / Cloud Functions / OCI Functions trigger surface, execution-role privilege review, secrets-in-environment audit, event-injection PoCs across SNS / EventBridge / Pub/Sub / Service Bus. Terraform, CloudFormation, Bicep and Pulumi modules scanned with Checkov, tfsec and KICS, with manual review of high-blast-radius modules (networking, KMS, IAM root policies). CI/CD pipeline review aligns to NIST SP 800-204D where in scope.
Methodology
Seven phases derived from NIST SP 800-204D, the CIS Foundations Benchmarks, MITRE ATT&CK Cloud and the AWS Well-Architected Security Pillar. Multi-cloud estates run the same shape per provider with shared reporting.
Frameworks & standards
Every finding is tagged to the control your auditor or platform team will reference.
Deliverables
A written report (typically 70–140 pages depending on cloud-account count and Kubernetes footprint) plus machine-readable artefacts. Every finding is reproducible from the report alone.
{
"id": "AXV-CLOUD-2026-0007",
"title": "EC2 instance role can iam:PassRole into AdministratorAccess via Lambda",
"severity": "Critical",
"cvss_v3_1": "AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"cvss_score": 9.6,
"provider": "AWS",
"attack_path": [
"principal: arn:aws:iam::111122223333:role/web-tier-ec2",
"edge: iam:PassRole -> arn:aws:iam::111122223333:role/lambda-admin",
"edge: lambda:CreateFunction + lambda:InvokeFunction",
"target: AdministratorAccess via lambda execution"
],
"mitre_attack_cloud": ["T1078.004", "T1098.001", "T1548.005"],
"cis_aws": ["1.16", "1.17"],
"nist_800_53": ["AC-6(1)", "AC-6(2)", "AC-6(7)"],
"remediation": "Scope iam:PassRole on web-tier-ec2 to an explicit allow-list via iam:PassedToService and a resource ARN list; remove the wildcard.",
"retest_status": "pending"
}Engagement timeline
Calendar weeks for a single-provider, 5-to-15-account engagement with one Kubernetes cluster in scope. Multi-cloud estates run providers in parallel under a shared report.
Frequently asked questions
Which cloud providers do you cover?+
AWS, Microsoft Azure, Google Cloud Platform and Oracle Cloud Infrastructure. Each engagement is staffed by a tester whose primary specialism is the target provider — AWS engagements lead with Security Audit role analysis, Azure with Defender for Cloud + Entra ID review, GCP with IAM Recommender + Org Policy review, OCI with Cloud Guard + IAM compartment review. Multi-cloud estates are scoped as one engagement with a unified report and a per-provider methodology annex.
What is the difference between CSPM tooling and a cloud security assessment?+
CSPM (Cloud Security Posture Management) tools — Wiz, Prisma Cloud, AWS Security Hub, Defender for Cloud, GCP SCC — continuously flag misconfigurations against a benchmark. They are excellent at the breadth dimension. A cloud security assessment goes beyond that: a tester validates which CSPM findings are exploitable, models real IAM attack paths (which the tooling rarely surfaces with full graph context), tests Kubernetes admission controls, performs container escape research where applicable, and proves segmentation actually holds. The deliverable is exploitable risk, not a list of green and red checks.
How do you map IAM attack paths?+
We pull the full IAM graph using read-only audit roles (AWS SecurityAudit, Azure Security Reader, GCP Security Reviewer, OCI Auditor) and analyse it with PMapper / Cloudsplaining / Principal Mapper-style tooling backed by manual review. Each edge in the graph — iam:PassRole, sts:AssumeRole, lambda:InvokeFunction, role-trust-policy condition-key gaps — is evaluated for exploitability. The deliverable includes a directed-graph diagram showing every path from an external or low-trust principal to a sensitive resource, with PoC commands per edge.
Do you test our Kubernetes clusters?+
Yes. EKS, AKS, GKE, OKE and self-managed Kubernetes are all in scope on request. We test RBAC role bindings, admission controllers (Pod Security Standards, OPA / Gatekeeper, Kyverno), service-account-token abuse paths, network policy enforcement, container-image provenance, and the IAM bridge between Kubernetes service accounts and cloud roles (IRSA, Workload Identity, Azure AD pod identity). Findings reference the NSA / CISA Kubernetes Hardening Guidance and CIS Kubernetes Benchmark v1.9.
Which standards and frameworks do you align to?+
CIS Foundations Benchmarks (AWS v3.0, Azure v2.1, GCP v3.0, OCI v2.0), NIST SP 800-204D (Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines), MITRE ATT&CK Cloud (Enterprise matrix), AWS Well-Architected Framework Security Pillar, Microsoft Cloud Adoption Framework Secure baseline, Google Cloud Architecture Framework Security pillar, CSA Cloud Controls Matrix v4, and the relevant provider-specific Kubernetes benchmarks. Findings are tagged to the controls your auditor will ask about.
Is the testing safe to run against production?+
Default posture is non-destructive. Configuration capture and IAM graph extraction are read-only. Active testing — IMDS exploitation PoCs, SSRF-to-role-credential chains, container escape PoCs — runs only against pre-agreed targets with rollback procedures documented. Anything that touches data integrity or availability happens in a staging environment unless production testing is explicitly authorised in writing under the Rules of Engagement.
Related work
Scope your cloud security assessment
Send the provider mix, account / subscription count, Kubernetes footprint and audit deadline. We respond with a fixed-fee proposal, lead-tester biography and a sample IAM attack-path diagram from a comparable engagement.
Request a scoping call →