State Of Cloud Security

Since May 2026, the tech industry has seen the acceleration of what has become known as the Vulnpocalypse : an enormous increase in the volume of vulnerabilities being reported by security researchers and vendors, caused by the advent of security-capable AI models such as Claude Mythos, GLM-5.2, or Kimi K3. Malicious actors have an unprecedented opportunity to compromise applications, and by extension cloud environments. Google Cloud estimates that in the first half of 2026, 44.5% of cloud incidents originated from an attacker exploiting a software vulnerability.

This year, we analyzed vulnerability data from thousands of real-world applications running in AWS, Azure and Google Cloud. We found that this increasing number of vulnerabilities is translating into increased risk. Namely, while a cloud service had a median of 4 high or critical vulnerabilities in February 2026, it had 4x this number 9 months later in November 2026.

This data reveals that the increased number of vulnerabilities in the CVE database isn’t a theoretical risk: it affects an increasing number of real-world applications running in cloud environments, reinforcing the need for cloud security foundations that limit the blast radius of compromised applications.

Adoption of cloud-hosted AI inference services brings familiar long-lived credential risk

To make cloud-hosted AI services easier to adopt, providers offer dedicated ways of using long-lived static credentials as a path of least resistance. But those keys are a valuable target: Criminals can steal them and resell access to third-party users , and model distillation gives them a further reason to go after credentials that open access to inference services.

As of September 2026, more than one in five organizations use cloud-hosted AI inference services such as Amazon Bedrock, Azure Foundry Tools, and Google Cloud’s Gemini Enterprise Agent Platform. Nearly half of organizations using Gemini use long-lived Gemini API keys , while only 17% of organizations using Amazon Bedrock use Bedrock API keys . In Azure, the pattern differs: Azure Foundry resources are by default created with long-lived keys already generated and able to be used for authentication; the vast majority of Azure organizations (97%) don’t change this behavior, meaning developers have access to long-lived keys that are already available.

Rather than static Bedrock or Gemini API keys, you should access AI inference services through the calling workload’s short-lived identity when supported (IAM role, managed identity, or service account) so the model is reached with the same federated credentials as other cloud resources and not a separate long-lived key.

The choice between a convenient static key and a short-lived identity is the same decision every long-lived credential forces in the cloud. Long-lived credentials are one of the most common root causes of publicly documented cloud breaches year after year. Offensive tooling has long specialized in automating the finding of these flaws: Red-team frameworks like Pacu and Datadog’s own Pathrunner along with secret scanners like TruffleHog reliably find over-permissioned credentials and exposed keys at scale. That same tooling is available to autonomous attackers, who enumerate for long-lived credentials first because they’re the highest-value, longest-lived prize in the environment.

Across AWS, Azure, and Google Cloud, the legacy long-lived credential (the IAM user access key, the service account key) remains pervasive, old, and unused. We found that 43% of AWS IAM users, 41% of Google Cloud service accounts, and 66% of Entra ID app registrations have active keys created in the past year, and those keys then age into risk. The of users with access keys older than three years has climbed steadily in AWS and Google Cloud since 2024, while only Azure has trended downward.

Encouragingly, 63% of organizations exclusively use single sign-on (SSO) through AWS Identity Center and federated access, slightly up from 59% in 2025 and 55% in 2024. However, 37% of organizations still use long-lived credentials through IAM users accessing the AWS console, down slightly from 41% in 2025 and 45% in 2024. The rate of exclusive SSO adoption roughly matches the rate at which organizations remove long-lived credentials.

Humans accessing cloud environments should use identity federation from centralized SSO and avoid using long-lived credentials such as IAM user access keys. Workloads that require cloud access should use platform-native authentication mechanisms that generate short-lived credentials, such as IAM roles for EC2 instances in AWS, managed identities in Azure, and service accounts attached to virtual machines in Google Cloud. Guardrails can then help prevent long-lived credentials from being created unintentionally, for example, by using the disableServiceAccountKeyCreation organization constraint in Google Cloud or by deploying a service control policy (SCP) in AWS that blocks actions such as iam:CreateAccessKey .

Supply-chain malware is adding cloud-specific attack mechanisms

Supply-chain attacks increasingly run autonomously and at machine speed. In 2026, a bot calling itself hackerbot-claw spent 10 days probing major open source projects ( Datadog’s own among them ) for vulnerable GitHub Actions workflows. The bot landed code execution in most of its targets and a full repository takeover in one. These cloud environment attacks travel well-trodden paths—a hijacked dependency propagating from developer laptops to CI/CD pipelines to production—but they’re much faster and carry cloud-specific payloads.

New dependency versions reach cloud applications quickly: 60% of organizations we analyzed run versions that were released less than 24 hours earlier . These versions appear in more than one in five (21%) cloud applications. This matters because supply-chain malware such as Shai-Hulud targets not only the application, but also cloud credentials and services.

We found that application workloads running in cloud environments have 149 software dependencies on average (median: 129). Across an organization, cloud application workloads have 568 software dependencies on average (median: 362). We also found that more than half of these dependencies are transitive, limiting developers’ visibility into them. This number varies significantly depending on the ecosystem. Only 32% of NuGet (.NET) dependencies are transitive, compared with 86% of npm dependencies. We also found that applications running in cloud environments have more dependencies than applications running in other types of environments.

Supply-chain malware increasingly includes capabilities that target cloud credentials and cloud environments. Threats such as the Shai-Hulud malware family (whose source code was leaked ) explicitly go after cloud credential files, secrets stored in cloud-based secrets managers, and short-lived credentials available in the instance metadata service. One variant, dubbed “Mini Shai-Hulud,” even includes cloud-specific code that deploys malicious payloads to cloud environments using the AWS Systems Manager (SSM) SendCommand API to execute commands on running EC2 instances.

This isn’t only theoretical: GitGuardian’s analysis of data leaked by the Shai-Hulud 2.0 campaign found hundreds of cloud credentials. Organizations should implement dependency cooldowns to lower the risk of malicious dependencies reaching their cloud environments, because the community usually identifies and contains hijacked libraries within a few hours.

Keyless authentication coexists with long-lived credentials in CI/CD pipelines

For CI/CD pipelines, long-lived credentials are also a core concern: Pipelines authenticate to the cloud constantly, usually hold broad deploy permissions, and are increasingly targeted through malicious software dependencies and code injection , seeking credentials to exfiltrate and use in subsequent attacks. Long-lived cloud credentials are challenging to rotate and are more likely to be leaked through a misconfiguration or vulnerability in the deployment pipeline.

The best practice is to use authentication based on OpenID Connect (OIDC) (also known as keyless authentication), allowing each pipeline to present a vetted identity to the cloud environment and retrieve credentials that are valid for only a short time.

In this context, we analyzed how organizations that use the popular CI/CD platform GitHub Actions authenticate their pipelines to AWS, Google Cloud, and Azure. We found that while OIDC usage is increasing year over year in AWS, its adoption remains uneven across providers . In AWS, 54% of organizations exclusively use keyless authentication for their GitHub Actions workflows (up from 45% in 2025 and 37% in 2024), compared with 22% in Google Cloud and 5% in Azure. Many organizations use OIDC-based authentication alongside other authentication methods (22% in AWS, 13% in Google Cloud, and 52% in Azure).

Organizations that use CI/CD pipelines to deploy infrastructure and applications to cloud environments should use keyless OIDC-based authentication, which is easier to deploy and scale and is more secure because it relies on short-lived credentials. This authentication mode is supported by all major CI/CD platforms, including GitHub Actions, CircleCI, GitLab CI/CD, Bitbucket, and Azure DevOps.

Data perimeters become common in AWS, while organization-level enforcement remains rare

Because cloud providers’ APIs are exposed to the internet by design, an attacker compromising cloud credentials can use them from anywhere in the world to access the cloud environment and data it contains. To mitigate this threat, data perimeters help ensure that access to cloud resources and data is allowed only if credentials are valid and have appropriate permissions, and the request originates from a trusted account or network.

The first step to implementing data perimeters is to use AWS Organizations with a multi-account strategy. We found that although 96% of organizations use AWS Organizations , only 55% of organizations implement data perimeters , up from 40% in 2025.

We analyzed how organizations implement data perimeters and found that most do so at the resource level. Of all organizations having at least one S3 bucket, VPC endpoint, SCP, or RCP, 47% use S3 bucket policies to implement them (through explicit deny and condition keys), compared with 19% that use a VPC endpoint policy. Few organizations use more scalable mechanisms such as SCPs and resource control policies (RCPs), which allow the creation of more effective data perimeters that span multiple AWS accounts.

We also found that 14% of organizations run EC2 instances in their organization management account , up from 9% in 2025. In addition to not using the security controls offered to them by AWS Organizations, an increasingly large of organizations create additional risk by running workloads in their organization’s management account. There, a single compromised workload can lead to the entire organization being compromised.

While organizations have the foundation to build efficient and scalable data perimeters, most rely on resource-specific data perimeters and don’t build on modern options that easily scale. Organizations should use a multi-AWS-account strategy with AWS Organizations and AWS IAM Identity Center for SSO, and they should implement data perimeters and security invariants by using SCPs and RCPs. To keep workloads out of the management account, they can delegate policy and service administration to member accounts.