Cloud Web Apps Have More Than One Attack Surface

One thing I think cloud security teams sometimes underestimate is how quickly a "web application issue" can stop being an application issue.

A vulnerable endpoint may be where an attacker gets in. But once that application is running in AWS, Azure, or GCP, the real attack path can continue through workload identity, deployment pipelines, container registries, serverless triggers, cloud storage, databases, staging environments, and management APIs.

Microsoft published a new Cloud Web Applications Threat Matrix on September 9, mapped to MITRE ATT&CK. What stood out to me was not one specific technique. It was how clearly the matrix shows that application security and cloud security are becoming difficult to separate.

Consider a fairly normal architecture.

A public application is deployed automatically from GitHub. The build produces a container image. The workload runs with a managed identity so it can read from storage and connect to a database. Logs go to a cloud logging service. A staging slot exists for releases. Terraform manages most of the infrastructure.

From an engineering perspective, that is a reasonable design.

From an attacker's perspective, it is also a chain of trust relationships.

If the application has an RCE vulnerability, the attacker may not care much about the container itself. They care about what the workload can reach next.

Can it query the cloud identity endpoint?

What permissions does its managed identity have?

Can those permissions reach storage, secrets, databases, queues, or AI services?

Can a compromised repository or registry push malicious code through the legitimate deployment path?

This is where I think DevSecOps needs to move beyond asking, "Did our scanner find a vulnerability?"

A better question is, "If this vulnerability is exploited, what trust boundary does the attacker cross next?"

Microsoft's research describes several paths that are worth paying attention to. A compromised source repository can feed malicious code into an automated deployment. A compromised container registry can turn a trusted image pull into code execution. Serverless triggers can become an attack path when attacker-controlled input reaches functions that process it unsafely. Deployment credentials can expose management interfaces. And once code execution is achieved, workload identity tokens may provide access to completely different cloud resources.

None of these controls live neatly inside one security product.

That is the operational challenge.

SAST might understand the vulnerable code. A CNAPP might understand the cloud permissions. GitHub knows who changed the workflow. Kubernetes knows which service account the pod is using. Terraform knows how the infrastructure was intended to be configured. Runtime telemetry knows what actually happened.

The useful security signal appears when we connect those views.

There are a few practices I would prioritize.

First, treat workload identity permissions as part of application security. If an internet-facing workload is compromised, its IAM permissions become part of the exploit's potential blast radius. Managed identity removes stored credentials, which is good, but it does not remove the need for least privilege.

Second, protect the deployment path as aggressively as the production runtime. Branch protection, immutable dependencies, signed artifacts, protected environments, short-lived CI/CD credentials, and controlled promotion between environments matter because attackers increasingly benefit from using the same trusted automation we use to deploy software.

Third, include staging and preview environments in threat modeling. These environments often have weaker monitoring or looser access because they are considered "non-production." But if they share identities, networks, data, secrets, or deployment mechanisms with production, the distinction matters much less to an attacker.

Fourth, correlate application and cloud telemetry. A suspicious HTTP request followed by unusual workload-identity token use, storage enumeration, or a new cloud API pattern tells a much stronger story than any of those events alone.

And finally, test the attack path, not only the individual control. A Terraform policy can say an IAM role is compliant while the overall chain still gives an exploited application more reach than anyone intended.

From a DevSecOps perspective, this is why I like threat models that follow identities and trust relationships instead of stopping at infrastructure diagrams. Modern applications are not just code running on servers. They are connected systems of repositories, pipelines, identities, APIs, managed services, and automation.

The security boundary is the whole path.

When you threat-model a cloud application today, does your team stop at the application boundary, or do you follow the attacker all the way through CI/CD, workload identity, and connected cloud services?

SOURCES: https://www.microsoft.com/en-us/security/blog/2026/09/09/threat-matrix-mapping-threats-across-cloud-web-applications/ https://attack.mitre.org/ https://learn.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices