CSA's 2026 threat list is a flat line, so ask which threats a config snapshot can prove

The Cloud Security Alliance published Top Threats to Cloud Computing 2026 in August 2026, polling 507 experts across 11 issues, with scores landing between 7.45 and 7.95 ^[1]. That spread is half a point, about 6 percent of the top score, which means the document is a flat line rather than a ranking and cannot tell an operator what to fix first ^[1][5].

If severity will not sort the list, something else has to. A post on dev.to by the author of an AWS configuration-verification tool takes the more useful cut: for each of the 11 issues, which properties can be expressed as a predicate over configuration state ^[6][22]. The author's starting complaint is fair. The report says things like "implement least-privilege access controls," which is sound advice and not checkable as written ^[21]. Decomposed, it becomes a family of specific tests: IAM roles carry no wildcard actions, execution roles do not hold PowerUserAccess, trust policies require MFA conditions, cross-account roles scope to named principals ^[14].

Run that across the whole framework and the author reports 112 properties, sorted into snapshot-verifiable, runtime-behavioral, and procedural ^[6][7]. Ninety-three are snapshot-verifiable and 19 are out of scope, so roughly 83 percent of the framework reduces to configuration state and 17 percent does not ^[8][9]. The 19 break down as 8 runtime or behavioral, 5 needing data AWS Config does not carry, 4 organizational, and 2 deliberate refusals ^[10]. The refusals are the honest part: one property is application-level authorization logic rather than configuration, and one would require putting secret values from environment variables into the snapshot, creating the exposure it is meant to detect ^[11]. In the one per-issue breakdown visible in the post, 11 properties yield 9 fully covered, 1 partial, and 1 out of scope for token replay ^[24]. A replayed valid token is indistinguishable from a valid token in a config file, which is what a boundary looks like.

The coverage numbers are self-scored and should be read that way. The author claims 77 of the 93 fully covered, 14 partial, 2 pending, giving 97.8 percent at least partially covered and zero actionable snapshot-verifiable gaps ^[12][18]. Full coverage alone is about 83 percent of the snapshot-verifiable set ^[13]. The party doing the decomposition also defines the denominator, so a perfect score against 112 properties you wrote yourself is a statement about scope, not about safety. The catalog behind it is 3,434 controls and 745 chains across 131 AWS services, of which 744 unique controls, 21.6 percent, map to CSA properties at all ^[19].

The interesting failure is at the new end of the list. Two AI-specific threats entered for the first time, AI-Enhanced Attacks at rank 2 and AI System Compromise at rank 6, which is two of eleven ^[4][23]. Both pending items are AI/ML: prompt and dataset versioning, and model artifact signing, blocked because AWS does not surface model provenance, dataset lineage, or prompt version history as configuration data ^[16]. The predicates are written and 14 controls are said to activate the day that data exists ^[17].

Watch whether AWS starts emitting provenance and lineage fields as configuration ^[16]. Until then, the 8 runtime items and 4 procedural ones need named owners in SIEM, EDR, and process, because the flat ranking gives you no licence to defer them ^[10].