Cloud Security Audit in Bengaluru · SaaS

Bengaluru is the densest cloud-native engineering market in India. Cloud-security audits here have to go several layers deeper than 'enable CloudTrail and turn on GuardDuty'. The Embassy Tech Village / Outer Ring Road belt and the Whitefield product corridor are full of multi-account AWS landing zones running production workloads on EKS, GCP project hierarchies running Anthos / GKE, and increasingly Azure tenants for the Microsoft-stack fintechs and enterprise SaaS. We review the IAM trust graph end-to-end, the Kubernetes RBAC and admission-control layer, the service-mesh authorisation policy (Istio is dominant on Bengaluru EKS, with Linkerd showing up at the smaller-scale clusters), and the data-plane key management that the customer's enterprise security team actually asks about during procurement.

Most of our Bengaluru engagements cover a multi-account AWS landing zone with at least one production account, one staging account, one shared-services account and one security/audit account, plus a logging account that aggregates CloudTrail, Config and VPC Flow Logs. We use Prowler 4.x for CIS Benchmark gap analysis (AWS Foundations Benchmark (current CIS v3 series)), ScoutSuite for cross-cloud posture comparison, Pacu for active IAM privilege-escalation enumeration, and Wiz / Tenable Cloud Security (where the client already runs them) to validate against findings. The IAM trust-graph review uses Macksofy-internal tooling on top of the AWS Access Analyzer findings and a custom BloodHound-style graph view of the cross-account role-assumption paths — the same Cyber-Kill-Chain shortest-path analysis we use on AD forests, adapted to AWS STS.

For product companies running multi-tenant SaaS — which is most of Bengaluru — we test tenant-isolation at four layers explicitly. IAM-role boundaries between tenants (does a customer-A service-role have any IAM transitive path to a customer-B resource?). KMS key separation (per-tenant CMKs, key policies, grants, and cross-account key-policy abuse paths). Network policy egress controls (can a tenant pod call out to another tenant's S3 prefix?). And noisy-neighbour exposure in shared EKS clusters (pod-security admission, resource quotas, taints/tolerations, and the not-uncommon mistake of running tenant workloads on the same node group as the cluster's logging or admin tooling). The output is a tenant-isolation matrix per tenant pair, which is the exact artefact enterprise procurement asks for in vendor-security questionnaires.

Kubernetes review goes deep on the admission-control layer because that is where the modern attack surface actually lives. We exercise OPA Gatekeeper and Kyverno policy gaps, validating-vs-mutating-webhook trust paths, ServiceAccount token-mounting defaults (the long-standing Kubernetes default that quietly bound a JWT to every pod), and the IRSA / Workload Identity / Azure Workload Identity federation back to cloud IAM. Service-mesh testing covers Istio AuthorizationPolicy authz drift between resolvers (a frequent finding — devs add a new service and forget to add the AuthorizationPolicy), mTLS enforcement gaps in PERMISSIVE mode, and the East-West-vs-North-South policy split that almost every Bengaluru SaaS gets partially wrong on first deployment.

The build-and-deploy plane is where attackers actually land on modern SaaS, and most generic cloud audits skip it entirely. We review GitHub Actions / GitLab runner privilege scopes, OIDC trust from CI to cloud IAM (a 2023-2024 trend — almost every Bengaluru SaaS has at least one GitHub OIDC trust with a wildcard subject claim), signed-artefact policy (cosign / Sigstore adoption), the secrets-management substrate (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager) and the Terraform / Pulumi state-file blast radius. These are the paths the LAPSUS$, Octo Tempest and Storm-0558-style adversaries use against modern SaaS — and a missed GitHub OIDC subject-claim wildcard has been the root cause of more than one Bengaluru SaaS breach in the last 24 months.

Engagements run three to five weeks for a single-cloud single-product scope and five to seven weeks for a multi-cloud or multi-product scope. Kickoff is onsite at Embassy Tech Village, ORR or the Koramangala / Indiranagar startup belt — the threat-model whiteboard is non-negotiable because the team always under-estimates the trust graph going in. We map findings against the CIS Benchmarks for AWS / GCP / Azure, the CNCF Kubernetes Hardening Guide, OWASP Cloud-Native Security Top 10, SOC 2 CC controls (CC6, CC7), ISO 27017 cloud-services Annex A, and (for cloud-native SaaS that handles PII) DPDP Act §16 cross-border-transfer obligations. The same report typically closes both an AppSec audit ask and the next enterprise customer's vendor-security questionnaire.

Reports include a Terraform / Helm-level remediation backlog rather than vague 'tighten IAM' bullet points. Every finding ships with a code-level fix snippet — a corrected IAM policy with explicit conditions and resource ARNs, a Kyverno policy that closes the admission-control gap, a Helm values diff that disables ServiceAccount token auto-mount on non-controller pods, a Terraform module patch that tightens KMS key-policy grants. The Jira-importable CSV maps each finding to severity, CIS control ID, OWASP CNS Top-10 mapping and a suggested epic-link so the platform team can drop it into the next sprint without re-typing.

Bengaluru procurement on cloud-security closes through the CTO and the head of platform engineering, sometimes with the AppSec lead as the technical reviewer. For Series-C and later SaaS preparing for an enterprise customer's security review, we ship a sanitised vendor pack alongside the technical report — same artefact answers the auditor and the customer's CISO without re-assembly, with the SOC 2 CC6/CC7 evidence and ISO 27017 crosswalk pre-built. The continuous-testing retainer option — quarterly full-coverage cloud-posture review with monthly delta tests against new cloud-account onboardings — matches the cadence at which Bengaluru SaaS actually spawns AWS accounts.