The main cloud security threats are misused identities, exposed or misconfigured resources, compromised software supply chains and abuse of the management interface. You detect them mainly through control plane logs, identity activity and a reliable asset inventory. Most incidents use ordinary mistakes, not new techniques.
What does the evidence say?
The Cloud Security Alliance published "Top Threats to Cloud Computing: Pandemic 11 Deep Dive" on 17 October 2023. It analyzes eight real breaches as narratives and as threat models, including the actor, the cloud weaknesses involved, the impact, and the controls that would have helped, and maps them to the earlier Pandemic Eleven list and to its Cloud Controls Matrix. The cases range from an identity provider incident to a build tool compromise and a vulnerable logging library. The paper points to identity and the supply chain as growing factors, and to shifts in who targets cloud services.
That mix is the useful takeaway. Cloud risk is less about the cloud itself and more about who holds keys, what is exposed and what you depend on.
Which threats come up most?
Identity compromise. Stolen passwords, reused credentials and leaked access keys give an attacker the rights of a legitimate user. MITRE ATT&CK describes valid accounts being used across cloud IaaS and SaaS, identity providers and network devices, and recommends multi factor authentication on all account types.
Misconfiguration. Storage left open, overly broad roles, management ports reachable from anywhere. These come from speed and complexity, not malice.
Supply chain. Third party code, build tools and images run inside your environment with your permissions.
Control plane abuse. An attacker with a valid role can create resources, change logging or grant themselves access without touching a single server.
Data exposure. Copies and exports that nobody tracks, which we cover in our post on shadow data.
Denial of service and resource abuse. Floods and unauthorized compute use, which show up as outages and bills.
How do you detect them?
Control plane logs. Every major cloud records API calls: who did what, from where, when. Alert on the high risk actions: new access keys, role changes, logging turned off, storage made public, new regions in use.
Identity signals. New country or device, impossible travel, first use of a privileged role, repeated failures then success.
Asset inventory. If you know what should exist, new and unowned resources stand out. NIST CSF 2.0 expects inventories of hardware, software, services and data.
Configuration monitoring. Compare live settings with a baseline and flag drift.
Workload and network signals. Unusual outbound traffic, new processes in containers, spikes in compute use.
What makes it hard?
Scale and speed: thousands of resources change daily. Shared responsibility: the provider secures the platform and you secure your use of it, and teams disagree about where the line sits. Multiple clouds and accounts: logs and rules differ. Short lived resources: a container may be gone before an analyst looks. And skills: the controls are specific to each platform.
Constructed example: the new access key
At 03:10 a log entry shows a new access key created for a developer's account, followed by a call from an address in another country that lists every storage bucket. No exploit is involved. The developer's token was lifted from a build log. A rule alerting on key creation followed by an unfamiliar address fires within minutes, the key is revoked and the account's session invalidated. Without that rule, the first sign would have been a data leak report.
The incident is invented but follows a pattern the CSA cases describe in general terms.
Where does software fit?
Many cloud incidents start in application code or dependencies that run there. Safeguard's code and dependency scanning, secrets scanning and reachability analysis help find the application side early, before the build reaches the cloud account. Cloud account monitoring itself is a separate job for your provider's tools and your logging platform.
How to check or apply this
- Enable control plane logging in every account and send it to a protected, central store.
- Require multi factor authentication for all human users and short lived credentials for machines.
- Write alerts for key creation, role changes, logging changes and public storage.
- Keep an inventory of accounts, resources and owners and reconcile it monthly.
- Scan code, images and dependencies before deployment.
- Define the shared responsibility split for each service you use.
- Rehearse a leaked key scenario.
Quick check
Are cloud breaches usually caused by sophisticated exploits?
Often not. Many involve stolen credentials, misconfiguration or compromised third party code, which is why identity and inventory controls matter.
What is the first log to turn on?
The control plane audit log in every account, since it records who changed what and lets you spot misuse of valid credentials.
Sources
- Cloud Security Alliance, Top Threats to Cloud Computing: Pandemic 11 Deep Dive
- MITRE ATT&CK, Valid Accounts (T1078)
- NIST Cybersecurity Framework 2.0, CSWP 29
Last reviewed: 18 October 2026.
