Cloud security incidents rarely begin with an advanced attack. They often begin with an ordinary cloud condition that nobody recognized as dangerous: an identity has more permissions than it needs, a database becomes reachable from the internet, a production resource is created outside Terraform, a secret is copied into a repository, logging is disabled, a vulnerable workload remains exposed, or a resource exists but nobody knows who owns it.
The real risk is not simply that one of these conditions exists. The risk comes from what that condition can reach, what depends on it, and how long it remains unnoticed.
Google Cloud's H1 2026 Threat Horizons report reflects this changing reality. Software vulnerabilities became the leading initial-access vector in the second half of 2025, but weak credentials and configuration errors continued to represent significant entry points. The practical lesson is that businesses must manage identities, cloud configuration, and vulnerable workloads together rather than treating them as separate security programs.
Over-Permissioned Cloud Identities
Excessive cloud permissions are among the most dangerous risks because they increase the impact of every other security failure.
A developer, workload, automation account, or CI/CD system may legitimately need access to several cloud services. Problems begin when that identity receives broad administrative access, wildcard permissions, unrestricted role-assumption privileges, or permissions that are never removed after a project ends.
The identity may function normally for months. Nothing appears broken. But if its credential, token, session, or workload is compromised, the attacker inherits the same access.
AWS recommends granting only the permissions required for a task, reviewing unused permissions and credentials, and moving from broad managed policies toward workload-specific policies.
A practical lesson from a compliance assessment
One experience that shaped our view of cloud security involved an over-permissioned identity discovered during a compliance assessment.
The immediate finding was a compliance gap. The actual business risk was larger: the identity could potentially access more infrastructure than its workload required. A compromised identity would therefore create a broader security exposure than the application's intended function suggested.
This is an important distinction. A compliance scanner might say: this identity violates a least-privilege control. A useful security assessment must also ask: what could this identity access, modify, assume, expose, or delete if it were compromised?
Compliance identifies that a control failed. Risk analysis explains why the business should care.
Publicly Exposed Cloud Resources
Cloud resources often become public through a small configuration change: a security group allows traffic from 0.0.0.0/0, a database accepts connections from the internet, a storage bucket allows public or cross-account access, a Kubernetes service is exposed through an unintended load balancer, or an administrative interface is reachable without an identity-aware control.
Not every public resource is insecure. A public website, CDN origin, or API may need internet access.
The important questions are:
- Was the exposure intentional?
- Is the exposed port or service necessary?
- Does the resource contain sensitive data?
- What identities or systems trust it?
- What would an attacker reach next?
This is why context matters. A public bucket containing marketing images is not equivalent to a public bucket containing customer exports. A public port on a disposable test instance is not equivalent to public administrative access on a production bastion.
Cloud Misconfiguration and Infrastructure Drift
A secure Terraform plan does not prove that the live cloud remains secure.
Infrastructure can change after deployment through cloud-console changes, emergency operational fixes, CLI commands, separate deployment systems, vendor integrations, manual troubleshooting, or scripts that bypass the main IaC workflow.
This produces drift: a difference between declared infrastructure and what is running.
Drift creates risk because code review, policy validation, and approval may all be operating against an outdated picture. A repository can appear compliant while production has already changed.
Cloud security therefore requires both code assessment and live-state assessment. ops0 Discovery compares real cloud infrastructure over time, identifies added, removed, and changed resources, and maintains resource timelines and dependency context.
Unpatched Software and Vulnerable Workloads
Cloud configuration is only one part of cloud security.
Virtual machines, container images, Kubernetes workloads, third-party applications, and internet-facing services can contain exploitable software vulnerabilities even when the underlying cloud account is configured correctly.
Google Cloud observed software exploitation accounting for 44.5% of initial access in the second half of 2025, overtaking weak credentials during that period.
Businesses should therefore evaluate internet-facing software, known exploitable vulnerabilities, container images, unsupported operating systems, third-party components, patch speed, and the privileges available to the affected workload.
A vulnerability on an isolated workload with minimal permissions is different from the same vulnerability on a public service carrying an administrative cloud role. Once again, severity without context is incomplete.
Exposed or Poorly Managed Secrets
Secrets frequently escape their intended boundaries through Terraform variables, environment files, CI/CD configuration, application logs, container images, source-code repositories, AI-generated code, internal documentation, or developer workstations.
Rotating a secret is also not enough if deployments continue using an old copied value.
A safer model keeps secrets in a dedicated vault, resolves the current value at deployment time, prevents secret values from entering AI context, and records when each secret is accessed.
ops0 supports encrypted inline secrets and references to AWS Secrets Manager, Google Secret Manager, Azure Key Vault, and Oracle Vault. External values are retrieved at apply time, and secret access is recorded for audit purposes.
Missing Logs and Weak Detection Coverage
Security controls sometimes fail. When they do, the organization must be able to determine what changed, who or what changed it, which identity was used, which resources were affected, whether data was accessed or moved, and whether the risky condition is still present.
Without reliable logs, a company may know that an incident occurred but be unable to reconstruct it.
AWS recommends API and user-activity logging through CloudTrail, while Google Cloud recommends protecting audit logs with least-privilege access.
Logging should cover more than application events. Cloud teams also need evidence from identity activity, cloud control-plane changes, network flows, deployment systems, policy evaluations, approval decisions, secret access, Kubernetes activity, and security findings.
Logs are detective controls. They help reveal and investigate dangerous activity. They do not replace preventive controls that stop unsafe changes before deployment.
Unmanaged and Unowned Infrastructure
Some of the most dangerous cloud resources are not obviously malicious or misconfigured. They are simply forgotten.
Examples include a production database outside active IaC, an old access key with no clear owner, a test load balancer still connected to production, a storage bucket created during a migration, a firewall rule added during an incident, an abandoned Kubernetes workload, a resource whose owner has left the company.
An unowned resource tends to miss patching, policy updates, cost review, and decommissioning.
Inventory alone does not solve this. The organization must connect resources to owners, applications, environments, dependencies, cost, code, and security findings.
ops0 scans live cloud accounts, normalizes discovered resources, builds relationships, detects changes, and connects findings to resource graphs and IaC workflows.
How Should Businesses Prioritize Cloud Risk?
Do not prioritize findings solely by scanner severity. For each finding, ask:
- Is it reachable? Can an attacker, another account, another workload, or the public internet reach the resource?
- Is it privileged? Does the affected identity or workload have access to other sensitive resources?
- Is it production-critical? Would exploitation cause downtime, data exposure, fraud, regulatory impact, or customer harm?
- What depends on it? Which applications, accounts, networks, databases, and teams rely on the resource?
- Was it an approved change? Does the condition exist in reviewed IaC, or did it appear through drift or an unmanaged action?
- Is there a safe fix? Can the risk be reduced without breaking a legitimate dependency?
This is the difference between finding risk and understanding risk.
A Better Cloud Security Operating Model
A practical cloud-security process should connect six stages: risk, impact, fix, policy, approval, and audit.
- 1Discover the dangerous condition in live cloud infrastructure.
- 2Map the resources, identities, workloads, and services it can affect.
- 3Generate or propose the smallest safe correction.
- 4Validate the correction against organizational policies.
- 5Route the change through human approval.
- 6Preserve evidence of the finding, decision, change, and result.
ops0 uses read-only discovery first, correlates security findings from multiple engines, applies contextual risk intelligence, grades cloud posture, and connects findings to reviewed infrastructure changes.
The objective is not to produce a longer list of alerts. The objective is to stop cloud risks before they become incidents.
What is the biggest cloud security risk?
There is no single biggest risk for every business. Excessive identity permissions, vulnerable internet-facing software, exposed resources, configuration drift, and leaked credentials are consistently high-impact because they can provide initial access or expand the effect of a compromise.
Are cloud misconfigurations the cloud provider's responsibility?
Cloud providers secure the underlying cloud platform. Customers remain responsible for many identity, network, data, workload, and configuration decisions under the shared-responsibility model.
Does passing a compliance audit mean the cloud is secure?
No. An audit evaluates controls and evidence within a defined scope and period. Infrastructure can change afterward, and a passing control does not necessarily explain the current blast radius of a live risk.
Can cloud security scanners prevent incidents?
Scanners primarily detect conditions. Prevention requires policy enforcement, secure defaults, deployment controls, approval gates, and a governed way to remediate findings.
Where should a business begin?
Begin with a read-only inventory of live cloud infrastructure. Identify identities, public exposure, unmanaged resources, vulnerable workloads, missing logs, drift, and critical dependencies before making changes.