Cloud Threat Modeling: Identity, CI/CD and Hunting

Cloud threat modeling must move from a static design artifact to an operational system built around identity, control-plane changes, telemetry, and hunt hypotheses. A STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) table bolted to a diagram may have been accurate at the architecture review, but it says nothing about last quarter's IAM policy change.

Responders can't investigate an alert on an unfamiliar role using a model with no opinion about roles. Most teams still rely on a method built for software-design flaws, while real intrusions now move through identities, control planes, and third-party trust.

Closing that gap starts with STRIDE's real limits, moves through the cloud-specific risks that deserve first-class modeling, and ends at a decision framework for where to start.

TL;DR:

• STRIDE remains a useful threat-identification prompt, but its six categories are not a cloud-specific threat catalog. Apply them to explicitly modeled IAM, metadata, federation, CI/CD, and key-management components, then supplement the results with cloud-specific attack techniques.
• The cloud threat model should center identity and the control plane because they govern authorization and high-impact changes. Credentials and permissions govern access across cloud and SaaS environments, while control-plane actions change authorization and infrastructure.
• An operational cloud threat model names telemetry and generates detection and hunting work wherever that reduces a relevant risk, alongside preventive controls and risk decisions. A model that stops at a document gives teams nothing to act on.
• Teams need continuous, signal-triggered modeling, paired with a hypothesis backlog they run between architecture reviews.

STRIDE still dominates, and it still misses the cloud

STRIDE remains the default threat-modeling method, but neither its categories nor its usual diagramming practice were built to capture what makes cloud environments different. STRIDE was the most commonly selected approach in Threat Modeling Connect's 2024-2025 survey of roughly 60 organizations, published August 2025: 88% of responders said it aligns with how their company threat models, while only 37% named diagrams as a main source for identifying threats. The survey isn't cloud-specific, but cloud usage data points the same way: AWS reports that Threat Composer customers using its optional metadata "most commonly use the STRIDE category and Priority metadata tags."

In a March 2023 review of NCC Group's threat model for Google Cloud Storage, Adam Shostack described its attack-goal list as "a nice illustration of the danger of limiting oneself to STRIDE" and wrote, "I prefer to use STRIDE to prompt my thinking, rather than categorize what I find." The authors of the Universal Cloud Threat Model make the same point at the category level: STRIDE and similar methods "do not account for the different operating models of cloud computing." Their seven top attack vectors (lost, stolen, or exposed credentials; publicly exposed resources; credentials exposed via application flaws; unpatched vulnerabilities and zero-days; denial of service; subdomain takeover; supply chain compromise) read like an incident report.

Generic STRIDE categories don't supply provider-specific attack scenarios on their own. The model has to represent cloud identities, trust policies, metadata services, deployment authority, and key-management relationships explicitly. Skip those details and the output stays categorically correct but operationally incomplete.

My position: keep STRIDE as the brainstorming mnemonic, because your engineers already know it, and stop using it as the structure of the model. The structure should be the control plane. Put IAM roles, trust relationships, and IMDS endpoints on the diagram as first-class elements. Then cross-check the model against ATT&CK Cloud techniques, including the Identity Provider platform view, to identify known adversary behaviors the STRIDE pass missed.

Model identity and the control plane first

Primary threat reports converge on identity because credentials and permissions govern access across cloud and SaaS environments, even when the reports' headline numbers disagree. Google Cloud's Threat Horizons H1 2026 report shows identity issues exploited for initial access in 83% of H2 2025 Mandiant Incident Response and Threat Defense engagements involving major cloud and SaaS-hosted environments.

A separate Google Cloud dataset in the same report shows software exploitation overtaking credentials as the primary initial access vector for the first time in H2 2025 (44.5% third-party software-based entry versus 27.2% weak or absent credentials), mainly via known CVEs on Compute Engine and Google Kubernetes Engine (GKE). Google notes this dataset reflects observed Google Cloud activity and may not represent all customers. The 2026 DBIR, covering incidents from November 2024 through October 2025, has vulnerability exploitation leading at 31%. These datasets cover different populations and classifications; together they support modeling both identity and trusted-integration abuse and exploitation of exposed workloads, without establishing a universal ranking for every cloud environment.

That means modeling identity wherever it actually sits: in long-lived credentials and IAM, in SaaS and OAuth trust, in the CI/CD pipelines that hold deployment authority, in Kubernetes workload identity, and in the AI agents now making privileged calls on their own.

1. Credentials and IAM

Long-lived credentials and excessive permissions are important exposures to model. In Datadog's September 2025 customer sample, 59% of AWS IAM users with active access keys and 55% of eligible Google Cloud service accounts with active user-managed keys had a key older than one year. Among Entra ID app registrations with active password credentials, 40% had credentials older than one year. Age is only one dimension of the exposure; who holds the credential matters just as much, and most holders in these environments aren't people. Sysdig's 2026 report found that human accounts were 2.8% of the accounts it analyzed, which means the model's "user" element is mostly machines in that sample.

2. SaaS and OAuth trust

A third-party OAuth app receives whatever rights were granted, so an attacker who obtains usable integration tokens may exercise the access those tokens authorize, subject to their scopes and other access controls. A Salesloft Drift incident brief documents an actor using compromised OAuth credentials from August 8 to 18, 2025 to mass-exfiltrate Salesforce Account, Contact, Case and Opportunity records, through read access to those records. Model third-party OAuth integrations by their effective scopes, accessible data, token lifetime, and revocation mechanisms; read access to sensitive records can be as consequential as write access.

3. CI/CD and the software supply chain

The build system holds deployment authority. Model how that authority moves, from source repositories and CI/CD runners to deployment identities and production resources. SafeDep's research on the May 2026 Megalodon campaign recorded 5,718 malicious commits to 5,561 repositories in roughly six hours, scanning for more than 30 secret patterns and collecting cloud credentials and Kubernetes configuration. Receiving a malicious commit doesn't mean every affected repository executed the payload; SafeDep documents a dormant-workflow variant that didn't run immediately. 

Wiz's 2025 report found public-repository cloud secrets in 61% of organizations studied and non-ephemeral self-hosted runners at about 35% of enterprises, both access paths that enable credential theft and deployment abuse. Tracking every repository, runner, credential, and deployment relationship adds maintenance as those paths change, but leaving the chain abstract hides how authority transfers.

4. Kubernetes and workload identity

After compromising a container, attackers may use the pod's mounted service account token to query the Kubernetes API, though what follows depends on the token's bound permissions and the cluster's RBAC configuration. Unit 42 reported a 282% year-over-year increase in observed Kubernetes-related threat-actor operations and suspicious activity consistent with potential service-account token theft in 22% of cloud environments in its 2025 telemetry.

Separately, Wiz's 2025 sample found that 81% of Amazon Elastic Kubernetes Service (EKS) clusters used deprecated CONFIG_MAP authentication. Model token exposure, RBAC permissions, cloud trust, and cluster access configuration as separate elements that can combine into an attack path, naming T1611 Escape to Host and T1609 Container Administration Command as the specific techniques worth modeling where privileges allow them.

5. AI workloads and agents

Agents collapse the distance between a prompt and a privileged API call. The OWASP Top 10 for Agentic Applications (2026 edition) leads with ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, and ASI03 Identity and Privilege Abuse. AWS's Generative AI Security Scoping Matrix calls for threat modeling at Scopes 3, 4 and 5, and cites NIST, MITRE and OWASP guidance naming prompt injection as a primary threat.

Record tool calls alongside their inputs, retrieved content, identities, authorization decisions, and outputs: the telemetry MITRE ATLAS's mitigation guidance points toward for agent workloads. These areas overlap, and modeling all of them increases maintenance work, but each one needs a named telemetry source and an owner, or the resulting threats stay disconnected from operations.

A model that ends in a document is half a model

Detection and hunting are where the model earns its keep day to day, even though they sit alongside preventive controls, architecture changes and risk decisions as outputs. One threat modeling post describes its threat models as a direct input to detection and response work. The connective tissue is ATT&CK, whose current release includes a Cloud matrix covering Office Suite, Identity Provider, SaaS and IaaS.

Map each modeled threat to techniques. Score visibility per technique with the DeTT&CT scoring tool, which maintains an assessment of log source quality, visibility coverage, and detection coverage, so gaps show up before you write rules, and update that assessment as logging and detections change. Use CTID's Summiting the Pyramid methodology to evaluate resistance to evasion, precision, and coverage across different implementations of a technique, and select spanning sets of observables that hold up well against both measures. Then write hunts for the techniques where detection is weak.

The detection step looks like the prebuilt Elastic CreateTrail rule, a low-severity rule whose hypothesis is that adversaries create trails to subvert monitoring. The logic matches event.action: "CreateTrail" with a success outcome. Responders check user_identity and source.ip, verify bucket ownership, and look for follow-on PutEventSelectors or prior DescribeTrails enumeration. A successful CreateTrail event only indicates a change that needs validation.

Elastic also flags onboarding, compliance initiatives, and IaC or control-tower automation as legitimate triggers for the same rule, and maps it to T1530 Data from Cloud Storage and T1562.008 Disable or Modify Cloud Logs. Separately, ATT&CK's DET0402 strategy for T1526 Cloud Service Discovery looks for unusual service and resource enumeration through cloud, identity-provider, and SaaS APIs.

The ways this loop breaks are well documented, and cloud adds its own failure points. A green ATT&CK heatmap says little about whether anyone is detecting attacks, and a red cell may mean the technique is irrelevant to your model.

Model cloud data-access logs, Kubernetes audit logs, application logs, and runtime telemetry as separate, specific sources. Short-lived workloads can lose local process, filesystem, or memory evidence before investigators arrive even when centrally retained audit and application logs survive, so collect and export the evidence each scenario needs before the workload terminates. 

Hunting frameworks describe their outcomes as feeding back into detection engineering and, less often, into the threat model itself, but published cloud examples of a hunt result changing a threat model are still hard to find. Treat the feedback loop as a design goal to build toward rather than an established practice.

Why cloud threat models die

Cloud threat models often die because calendar-driven reviews alone cannot track environments that change between review dates. A 2025 SecAppDev talk on continuous threat modeling argues that developers should maintain the model directly, alongside the periodic audit cycle. A Cloud Security Alliance piece makes the same point for cloud specifically: "in the cloud, these models break down," and continuous programs pair modeling with CSPM, IaC scanners and identity analyzers "so the model reflects reality, not wishful architecture."

• The first fix adds event-triggered updates without dropping periodic reviews. AWS's own Well-Architected guidance names a major change, a shift in the threat landscape, or adopting a new feature or service as its triggers. Keep a periodic cadence alongside them to catch missed changes, stale assumptions, and residual-risk decisions those triggers won't surface on their own.
• The second fix is modeling as code where the infrastructure is code. IriusRisk IaC import generates a model, threats, and countermeasures from imported CloudFormation or Terraform. With Threagile YAML modeling, architecture lives in a YAML file and the tool runs as a CLI or in Docker. In the OWASP pytm project, you define the system in Python. None of these import tools captures a SaaS OAuth grant, a runtime permission change, or a business trust relationship on its own, so treat the generated model as a starting point that still needs those inputs added by hand.
• The third fix treats CNAPP attack paths as an input the model consumes, while the model keeps doing its own broader analytical work. An attack path guide describes a security graph that traces "toxic combinations" where multiple issues of varying severity chain into a critical asset. This attack-path analysis can inform the threat model by identifying exploitable combinations of exposure, vulnerabilities, permissions, and sensitive assets; current CNAPPs increasingly add runtime threat detection and investigation capabilities too, so evaluate their posture and detection functions separately. The graph ranks today's exposure chains, while the model names the attacker behaviors to watch for regardless of posture.

Decision criteria: how to choose the right approach for your program

This sequence covers common program gaps. Use the conditions in priority order to find your starting point:

1. If you have no cloud model and a small security team of one to three people, then start from UCTM's seven vectors and run one tabletop built on a breach from your own environment, or, absent one, a published incident report such as the DBIR, asking at each step whether you could detect and contain it.
2. If you have STRIDE models at the application level, then add an identity and control-plane layer rather than starting over, with the ATT&CK Cloud and Identity Provider matrices as the completeness check.
3. If vendor alert catalogs are driving your detection backlog, then map every modeled threat to techniques and score visibility with DeTT&CT before writing rules.
4. If infrastructure changes daily through IaC, then move to model-as-code with CI triggers on Terraform and CloudFormation changes, and accept that you will own the pipeline integration.
5. If you ship AI agents with tool access, then add the Agentic Top 10 categories to the model and start recording tool calls alongside the inputs, identities, and authorization decisions behind them.
6. If hunting in your SOC is episodic, then treat the model as a hypothesis backlog and run those hypotheses on a schedule.

Most programs match more than one condition. Start with the lowest-numbered one that applies, since earlier conditions in the list point to more foundational gaps.

From design document to hunt backlog

Hunting frameworks already treat the threat model as an input. PEAK's Knowledge element turns hunt insight into new detections, data gaps or new hunt ideas; Sqrrl's loop ends by informing and enriching automated analytics; and TaHiTI treats threat intelligence as "a major source of threat hunting hypotheses." As Daylight writes in its analysis of the loop, "The loop sounds good in a framework diagram, but it breaks down in operation." 

Manual hunting tends to be episodic because it depends on senior people having time. A tool-only operating model leaves the same team responsible for writing, scheduling, and maintaining queries. Moving hypothesis design to experts and scheduled execution to agents separates the thinking from the execution, which changes the operating model itself.

Daylight is a Managed Agentic Security Services (MASS) company that extends its AI-native MDR platform to separate services, including a Threat Hunting service. For that service, a security expert defines each customer's hunt hypothesis, while agents run it continuously against up to 90 days of historical telemetry and escalate unexplained behavior into a full investigation.

Frequently asked questions about cloud threat modeling

Can you use STRIDE and ATT&CK together?

Yes: use STRIDE to brainstorm candidate threats, since your team likely already knows it, then treat ATT&CK Cloud as the completeness check that catches the identity and control-plane behaviors STRIDE's categories tend to miss. For Kubernetes threats specifically, also check the Enterprise matrix's Containers platform, since the Cloud matrix alone doesn't cover container-specific techniques.

Who should own a cloud threat model?

A cloud threat model needs an owner who can see both the architecture and the control plane. In practice, that means pairing a security architect with the platform or DevOps lead who changes IAM roles, CI/CD pipelines and Kubernetes configuration. Detection engineers and hunters should have write access to the model too, since they use it week to week, well beyond any annual review.

What's the difference between a threat model and a CNAPP attack path?

A CNAPP attack path describes a potentially exploitable chain in your observed environment right now, combining misconfigurations, vulnerabilities, secrets, reachability, permissions, and runtime signals of varying severity. A threat model considers assets, trust relationships, attacker behavior, impact, and mitigations across current and proposed designs, so it stays relevant even after a specific attack path gets remediated. Attack paths are useful inputs to the model; they don't replace the broader modeling process.

Is threat modeling part of threat hunting?

They're related but separate: a threat model identifies which techniques matter for your environment, and that list becomes the hypothesis backlog a hunting program works through on a schedule. Threat hunting doesn't replace the model, and the model doesn't replace scheduled hunting; each hunt's outcome should feed back into updating both the model and the detection backlog it drives.