✓ Human-authored analysis; AI used for formatting and proofreading.
CSA's Top Threats to Cloud Computing 2026 published in August 2026. 507 experts. 11 issues. The scores range from 7.45 to 7.95. A spread of half a point, meaning the industry considers all eleven roughly equally severe. Identity holds the top spot. Two AI-specific threats enter for the first time: AI-Enhanced Attacks at rank 2 and AI System Compromise at rank 6.
The report tells you what to worry about. It doesn't tell you which worries are mechanically checkable.
We took the report and asked a different question: for each issue, what machine-verifiable properties can we extract from a cloud configuration snapshot, and do we already check them?
The results: 112 properties across all 11 issues. 93 are snapshot-verifiable. 91 are at least partially covered. Two are pending on observation data. The controls are designed but the data isn't collected yet. And 19 properties are out of scope because they require runtime behavior, organizational process, or data that doesn't exist in a configuration snapshot.
The methodology
A risk framework and a verification tool operate at different levels of abstraction. The CSA report says things like "implement least-privilege access controls." That's good advice. It's also not checkable as stated.
So the first step was decomposition. For each of the 11 issues, we extracted every concrete property that could be expressed as a predicate over cloud configuration state. "Implement least-privilege access controls" becomes a family of specific checks: IAM roles don't have wildcard actions, execution roles don't carry PowerUserAccess, trust policies require MFA conditions, cross-account roles scope to specific principals.
Then we classified each property into three categories:
Snapshot-verifiable. The property can be checked by examining current AWS configuration such as IAM policies, security group rules, encryption settings, logging configuration, resource tags. This is Stave's domain.
Runtime-behavioral. The property requires observing system behavior over time such as API call patterns, anomalous logins, data access frequency, runtime attestation. The domain of SIEM, EDR, and runtime monitoring. We can't check these from a snapshot.
Procedural. Organizational process such as access reviews, incident response plans, shared responsibility understanding. They are important, but not machine-checkable.
Out of 112 properties: 93 snapshot-verifiable, 19 out of scope. The 19 break down as: 8 runtime/behavioral, 5 non-AWS-Config data, 4 organizational/process, and 2 that we deliberately chose not to implement. One because the property requires application-level authorization logic rather than configuration (OWASP BOLA/BFLA). Another one because including the data in snapshots would create the very exposure it's supposed to detect (secret values in environment variables). The 19 are boundaries, not gaps.
What 97.8% means
93 snapshot-verifiable properties. Of those: 77 fully covered, 14 partially covered, 2 pending on observation data. 91 out of 93 at least partially covered. That's 97.8%.
The 14 partial items are narrow scope boundaries within well-covered areas such as "container base image currency requires layer analysis" when we already check ECR scanning, image signing, digest pinning, and untrusted registry pulls. The configuration side is covered; a thin slice at the edge isn't.
The 2 pending items are both AI/ML-specific: prompt/dataset versioning and model artifact signing. These need observation fields that AWS services don't yet surface as configuration data such as model provenance metadata, dataset lineage, prompt version history. The controls are designed and the predicates are written. The day the observation data is available, 14 controls activate across those two properties. Zero new logic required.
Zero actionable snapshot-verifiable gaps. Every configuration property that can be verified from an AWS snapshot has at least partial coverage.
Eleven issues, one catalog
We checked against a catalog of 3,434 controls and 745 chains across 131 AWS services. Of those, 744 unique controls, 21.6% of the catalog mapped directly to CSA properties. The rest cover areas the CSA report doesn't touch (service-specific best practices, compound attack paths, ghost reference detection) or provide depth beyond what the framework requires.
Here's how each issue broke down.
Issue 01: Inadequate Identity, Credential, Access, and Key Management
The deepest coverage in the catalog. 11 properties, 9 fully covered, 1 partial, 1 out of scope (token replay, which is runtime). 138 controls referenced, spanning trust policies, confused deputy prevention, session management, credential lifecycle, and agent identity.
The compound chain third_party_exposure_path fires when a vendor role is both dormant and overprivileged and lacks an external ID condition. Three facts that are individually common but together create an unmonitored ingress path through a third-party trust relationship. This is the shape that atomic scanners miss: each control might pass a risk threshold alone, but the combination doesn't.
Issue 02: AI-Enhanced Attacks and Weaponization
New in 2026. 9 properties, 6 covered, 1 partial, 2 out of scope (vulnerability remediation velocity and runtime integrity verification). 92 controls referenced.
This issue functions as a threat amplifier. The snapshot-verifiable properties are about reducing the surface that AI-enhanced attacks target. Credential lifetime, logging depth, detection coverage. The mitigations overlap heavily with Issues 01 and 05.
Issue 03: Insecure Third-Party Resources
9 properties, 5 covered, 2 partial, 2 out of scope (SaaS dependency inventory and SBOM presence, both require data sources outside AWS configuration). 82 controls.
EKS image provenance is the deepest area: 10 controls covering public registry pulls, missing digests, unsigned images, and the critical-severity eks_image_provenance_unsafe chain. The partial items are container base image currency (we check signing and scanning, not individual layer freshness) and API key rotation lifecycle (no native API Gateway mechanism exists).
Issue 04: Insecure Interfaces and APIs
10 properties, 7 covered, 1 partial, 2 out of scope. 77 controls. API Gateway carries 105 controls in the catalog including auth, throttling, WAF, logging, mTLS, and orphan detection. One of the out-of-scope items is OWASP BOLA/BFLA which is whether your application checks that User A is allowed to access Object B. That's authorization logic in code, not AWS configuration.
Issue 05: Misconfiguration and Inadequate Change Control
The original cloud security problem. 12 properties, 7 covered, 3 partial, 1 pending (prompt/dataset versioning which is AI/ML-specific, controls designed, waiting on observation data), 1 out of scope (IaC validation is pre-deploy; Stave checks post-deploy state). 93 controls.
The three partials are exposed credentials (we check rotation and storage patterns, not secret content), configuration drift (we compare snapshots, not continuous real-time monitoring), and RAG pipeline misconfiguration.
Issue 06: AI System Compromise and Supply Chain Exploitation
New in 2026. 11 properties, 7 covered, 0 partial, 1 pending (model artifact signing has controls designed, waiting on observation data), 3 out of scope (prompt injection defense, output monitoring, and runtime behavioral analysis are all runtime concerns). 72 controls.
The compound chain bedrock_agent_data_exfiltration is the standout. It fires when three conditions stack: a Bedrock agent role grants broad lambda:InvokeFunction on Resource: *, the agent references a Lambda that no longer exists (ghost ARN), and the role has overbroad S3 write access. Prompt control gives the mechanism, the ghost reference gives the exploitation vector, S3 gives the exfiltration destination. Drop any one leg and the chain breaks.
Three of this issue's out-of-scope properties do have boundary controls. Prompt injection defense is runtime, but Stave verifies that the guardrail configuration exists. The prompt attack filter is enabled at high strength and the agent has a guardrail associated. The control doesn't detect injection at inference time. It verifies the defensive configuration is in place.
Issue 07: Advanced Persistent Threats
10 properties, 7 covered, 1 partial (CodeArtifact supply chain persistence has controls queued pending observation data for package repository policies), 2 out of scope. 112 controls.
Issue 08: Insufficient Cloud Security Architecture and Strategy
10 properties, 6 covered, 2 partial, 2 out of scope (SaaS integration visibility and shadow AI detection). 126 controls. One partial is the human-to-machine identity ratio which is a governance indicator tracking whether non-human identities are proliferating faster than oversight can keep up.
Issue 09: Insecure Software Development Lifecycle
10 properties, 6 covered, 2 partial, 2 out of scope. 118 controls. One out-of-scope item, secret values in environment variables. We deliberately chose not to implement. Including the secret content in configuration snapshots would create the exposure risk the control is supposed to detect. The correct tool for that check is a secrets scanner operating on the live environment, not a configuration verifier storing the values.
The codebuild_build_escape chain maps here: when a CodeBuild project runs with Docker privileged mode and has an overprivileged IAM role, a container escape grants the build role's full permissions on the host. Both conditions must stack.
Issue 10: Accidental Data/AI Data Exposure
10 properties, 7 covered, 1 partial (SageMaker model package group policy closes when the AI/ML governance observation data ships), 2 out of scope. 77 controls. S3 alone carries 149 controls covering public access block, ACLs, bucket policies, website hosting, access points, encryption, and versioning.
Issue 11: System Vulnerabilities
10 properties, 10 covered. 0 partial. 0 gaps. 0 out of scope. 125 controls. 100% coverage.
This is the counterintuitive result. "System vulnerabilities" sounds like CVE patching, which is runtime. But the CSA properties decompose into configuration checks: is Inspector enabled, is SSM Patch Manager configured, is ECR image scanning active, are ECS/EKS clusters running supported versions, are security groups restricting unnecessary exposure. Every one of those is a snapshot-verifiable configuration predicate.
The exclusions
Nineteen properties across all 11 issues are out of scope. None are missing categories. They're individual properties where the required data doesn't exist in an AWS configuration snapshot, or where implementing the check would be counterproductive.
Six of the 19 have boundary controls. These don't cover the runtime property itself, but they verify the infrastructure prerequisite. The distinction matters: when Stave reports that a Bedrock guardrail is configured with prompt attack filtering at high strength, that's not the same as detecting prompt injection at inference time. It's verifying the defensive configuration exists. The gap between configured and effective is real, and we don't paper over it.
The remaining 13 have no boundary coverage at all. Token replay is runtime. SBOM presence is a development artifact. Edge device security isn't AWS configuration data. These aren't gaps in the tool. They're boundaries of the domain.
Where AI/ML observability falls short
The two pending properties: prompt/dataset versioning and model artifact signing are both AI/ML-specific. They need 3 new asset types and 16 observation fields. Currently in development.
This tells you something about the state of the industry. Traditional cloud services (IAM, S3, VPC, EC2, EKS) have mature APIs that produce comprehensive configuration data. AI/ML services (Bedrock, SageMaker) expose their core functionality through APIs but don't yet surface the governance metadata such as model provenance, dataset lineage, prompt version history that security verification needs. The gap isn't in verification logic. It's in what the platform makes observable.
The number that matters
744 controls out of 3,454 which is 21.6% of the catalog map to the 11 CSA threats. That means 78.4% of the catalog covers properties the CSA report never mentions: service-specific best practices, compound attack paths between services, ghost reference detection, denial-of-wallet controls, and controls at depths the framework doesn't reach.
The CSA report is a useful floor. It is not a ceiling. The properties it recommends are the ones 507 experts agreed are important. The properties it doesn't mention are the ones that show up in incident reports.
Stave is an open-source cloud configuration verifier. It evaluates AWS configuration snapshots against system invariants and finds compound attack paths that single-resource scanners miss without requiring any credentials.
Top comments (0)