← All posts

Cloud Security: Bigger Than Any One Service

Originally published on LinkedIn

Cover image for Cloud Security: Bigger Than Any One Service

I was talking to a cloud security company recently, and they were so laser-focused on one service. Honestly, it felt like they didn’t grasp the bigger picture. I had to stop and say: “Cloud isn’t one service. It’s hundreds — and they all connect in ways that create real risk.”

That conversation made me realize how often our industry gets stuck in silos.

Why one-service thinking fails

  • Attacks chain services → Locking down Storage doesn’t matter if your Kubernetes cluster or VM has an over-privileged identity that can reach it.
  • The seams are dangerous → An Event Grid → Function App → Cosmos DB path might look fine in pieces, but together it’s an open door.
  • The surface area is massive → Azure 600+, AWS 200+, GCP 100+ services. Focusing on one while the rest shift around you is a losing game.
  • Human and non-human identities multiply risk → In cloud, it’s not just people with accounts. Every VM, container, function, and pipeline has its own non-human identity. These often carry broad or unmonitored permissions. If you only focus on one service, you miss how attackers exploit workload identities to move laterally.
  • And many others......

CNAPP in plain English

Gartner calls it Cloud-Native Application Protection Platform (CNAPP). In simple terms: 👉 Stop chasing configs one service at a time. CNAPP connects the dots across:

  • CSPM → posture & misconfigurations
  • CWPP → workloads & runtime
  • CIEM → human & non-human identities, entitlements, and permissions
  • IaC → shift-left controls & runtime visibility
  • DSPM → data security

Instead of 5 dashboards, you get one picture of how risks really chain together.

The scale problem

Let’s be real:

  • Azure → 200+ services (and more in preview)
  • AWS → 200+ services
  • GCP → 100+ services

That’s hundreds of moving parts across three different ecosystems. No single team can master them all — and trying to pretend otherwise is risky.

What works instead:

  • Guardrails by service class (VMs, containers, serverless, DBs, AI, storage).
  • Policy-as-code baked into landing zones & pipelines.
  • CNAPP as the connective tissue across posture, workloads, identity, and data.
  • Communication and collaboration with the supporting teams.

Illustration for Cloud Security: Bigger Than Any One Service

This is the reality: cloud isn’t one service, and attackers won’t wait for you to catch up.

The callout for cloud security pros

If you’re the “Cosmos person,” the “Kubernetes person,” or the “VM person,” that’s fine — but it’s not enough. Cloud security is about the ecosystem.

Attackers don’t silo themselves. Neither can we.

I’d love to hear how teams at Wiz, Microsoft Security, Palo Alto Networks and CrowdStrike are approaching this. Are you organizing by provider, by service class, or by CNAPP capability? How do you keep your Sales Engineering teams well covered?


In my own role, I’ve organized my team to be the SMEs of the entire cloud ecosystem — not just one service. That’s the only way to keep up with innovation and stay ahead of how attackers think.

CloudSecurity #CNAPP #Azure #AWS #GCP #Kubernetes #CyberSecurity #InfoSec #CloudNative

Want help applying this in your environment?

Request a service