Cloud Workload Vulnerability Testing: What CSPM Misses

Two H2 2025 threat reports converged on the same finding: known, well-catalogued weaknesses on cloud-hosted workloads have overtaken misconfiguration and credential abuse as the most common way attackers get in. Wiz’s 2026 retrospective attributes roughly 80% of documented cloud intrusions to these testable entry points, and Google Cloud’s Threat Horizons H1 2026 report puts software vulnerability exploitation at 44.5% of cases, ahead of weak credentials at 27.2%. That reversal changes what an annual cloud security review needs to cover this cycle, and it puts cloud workload vulnerability testing at the centre of it.

Most annual cloud reviews were scoped around configuration posture. That scope was reasonable in 2022. In 2026, it leaves the largest current initial-access vector untested.

Why CSPM Alone Is Not a Security Review

Cloud Security Posture Management (CSPM) tools do one thing well. They compare a cloud tenant’s declared configuration against a benchmark and surface deviations. Public S3 buckets, permissive inbound rules, disabled logging, over-broad IAM roles: those are the findings a CSPM will produce day after day, and the fixes are usually straightforward.

That value is real. It is also incomplete.

A CSPM does not know whether a workload sitting behind a well-configured network perimeter is actually exploitable. It cannot tell whether a container running the latest declared image is running the latest deployed image. It cannot chain three findings into a business-impact narrative and say “this exposed workload leads to that object store.” Those are the questions a human-led review answers.

CTDefense sees this gap most often in organisations that treat the annual CSPM report as the complete review. The report is accurate for what it measures. It just does not measure workload exploitation, and workload exploitation is where the initial-access numbers now sit. A similar pattern showed up in what CSPM misses on IAM keys: the configuration was clean, the operational reality was not.

A complete review covers configuration posture, IAM privilege scope, and workload exploitation testing. Most annual engagements deliver only the first two, which is the gap this post maps.

Exploitable CVEs in Cloud-Hosted Workloads

The first finding type a human-led review surfaces is the exploitable CVE on a public-facing cloud workload. A cloud vulnerability assessment delivered by scanner alone will list the CVE, note the CVSS score, and move on. That list becomes an unread ticket queue.

A pentester takes the same list and asks a different question. Which of these can actually be reached from the internet, and which of those, once exploited, gives access worth caring about?

The team examines:

• The exposed surface of each workload. Load balancer rules, WAF coverage, and any authentication in front of the vulnerable endpoint change what is actually reachable versus what looks reachable in the inventory.
• Whether a public proof-of-concept works against the specific runtime. Version, patch level, kernel, and configuration all matter, and a scanner cannot confirm any of them the way a hands-on test can.
• What identity the compromised workload runs as. The service account or role attached to the workload defines the blast radius, so the team traces what that identity can reach: object storage, secrets managers, managed databases, other workloads.

This is the difference between a vulnerability scan and a cloud penetration test. A scan identifies known CVEs by signature match. A pentest confirms whether a CVE is actually exploitable in the specific running environment and what an attacker could reach from that foothold. The Wiz Cloud Threats Retrospective 2026 makes the point directly: “These entry points were not novel, but they remained highly effective, accounting for roughly 80% of documented cloud intrusions.” Testable, in other words. Catchable before an attacker finds them.

According to the Google Cloud Threat Horizons H1 2026 report, “threat actors exploited software-based vulnerabilities (44.5%) more frequently than weak credentials (27.2%)” in H2 2025. That is the reversal most cloud security programmes have not yet re-scoped around.

Unverified Container Images Running in Production

The second finding is less obvious. A container image vulnerability in a base image gets flagged in the registry scan report, someone opens a ticket, someone else closes it as “patched in the next build,” and nobody verifies what is actually running in production two months later.

This gap is common because responsibility is split. The image scanner belongs to the platform team. The running workloads belong to whichever service team ships them. Registry pass or fail does not equal production pass or fail.

CTDefense’s review checks the delta between what was scanned and what is running. In one recurring pattern, the team finds:

• A base image scanned clean six weeks ago, still deployed, now carrying known-exploitable OS packages disclosed after the last scan.
• A build pipeline that pins a base image tag but pulls a mutable tag at deploy time, so the running image drifts from the scanned image.
• A sidecar or init container that never went through the registry scanner at all, because it was added by a Helm chart the platform team did not own.

None of these are configuration mistakes a CSPM would catch. All of them turn into exploitable CVEs on production workloads, which is exactly the initial-access vector the Wiz and Google Cloud data highlights.

Chained Attack Paths Only a Human Can Map

The third finding type is where the value of a human-led review compounds. Individually, three findings can look like low-severity noise. Chained, they describe a full breach path.

A representative chain looks like this. An exploitable CVE on a public-facing containerised microservice gives shell access. The workload runs under a service account that a CSPM correctly flagged as slightly over-privileged, at “medium” severity, and nobody prioritised. That service account can read an object store bucket with customer data in it, or can assume a role that can. What was three medium findings becomes one critical business risk.

Automated tools can list the individual pieces. They cannot walk the path and prove it. That is a human task, and it is the same pattern discussed in CI/CD secrets and the cloud attack paths they open: individual findings look tolerable until someone strings them together.

Blast-radius analysis, cross-tenant pivot potential, and lateral movement between workloads in adjacent environments all fall into this category. They are the findings the board actually cares about, because they translate into an answer to the question that follows every breach report: if that workload gets popped, what do we lose?

What a Complete Cloud Security Review Should Cover

A cloud security review that reflects the H2 2025 threat picture covers three tracks, in this order:

• Configuration posture. The CSPM output, verified and prioritised. Public assets, misconfigured storage, permissive network rules, disabled logging. Table stakes.
• IAM privilege scope. Which principals can reach which resources, which roles can assume which other roles, and where the standing permissions sit versus what business use actually requires.
• Workload exploitation testing. Which running workloads carry exploitable vulnerabilities, whether public proofs-of-concept work in the specific environment, what identity each vulnerable workload runs as, and what that identity can reach.

The first two tracks answer whether the environment is configured well. The third answers whether the environment holds up when tested. A NIS2 cloud security audit or an ISO 27001 evidence pack increasingly asks for both. Auditors and cyber insurers now expect documented evidence of workload-level testing, not only a CSPM posture report; a review that includes exploitation evidence satisfies that bar.

CTDefense delivers this scope through its human-led Cloud Security Assessment, which explicitly includes workload-level exploitation testing as a scope item alongside configuration and IAM review. The output is a prioritised list of findings written in business terms, with the exploit chain traced end to end for each critical issue.

Similar organisations running cloud-first or hybrid environments are encouraged to look closely at the scope of their next annual review. If the scope document does not mention workload vulnerability testing, the review is not covering the vector that generated most of last year’s cloud intrusions.