Piscium SecurityPISCIUMSECURITY
blog

CTEM for Cloud and Enterprise: From Thousands of Findings to Proven Attack Paths

Cloud and enterprise teams drown in exposure findings. Here is how continuous threat exposure management proves which ones form real, exploitable attack paths.

By Piscium Security Team

TL;DR

  • Cloud and enterprise security tools produce thousands of findings a day. Continuous Threat Exposure Management (CTEM) is the discipline of proving which of those findings an attacker could actually use, and fixing those first.
  • The dominant risks are not exotic zero-days. They are misconfigurations and over-permissioned identities. Gartner has projected that through 2025, 99 percent of cloud security failures would be the customer's fault, and a 2022 Unit 42 study found that nearly 99 percent of cloud identities were granted permissions they never used.
  • Most exposures go nowhere. In a 2024 analysis of more than 40 million exposures, XM Cyber found that about 74 percent were dead ends and only about 2 percent sat on the choke points that lead to critical assets. Severity scores cannot tell you which is which; attack-path analysis can.
  • Piscium Radius applies the CTEM loop across AWS, Azure, and GCP: it maps cross-account and cross-cloud attack paths, validates which exposures are exploitable, and drives fixes to closure. It is an early-stage platform, and any before-and-after numbers in our material are modeled or illustrative.

A modern cloud estate generates an astonishing amount of security data. Every misconfiguration scanner, every CVE feed, every identity tool adds to the pile. The problem is no longer finding exposures. It is knowing which handful, out of thousands, an attacker could actually chain together to reach something that matters.

That is the job Continuous Threat Exposure Management does. Gartner introduced CTEM in 2022 as a five-phase program (scoping, discovery, prioritization, validation, and mobilization) that runs continuously rather than once a quarter. This piece is about what it looks like in cloud and enterprise environments, where the volume is highest and the noise is worst.

The real problem: too many findings, no proof

Cloud security tooling is very good at producing findings and much weaker at telling you which ones matter. In a 2022 survey of more than 800 practitioners, Orca Security found that 59 percent of teams were getting more than 500 public-cloud alerts a day, and 55 percent said critical alerts were slipping through because of the volume.

The findings themselves cluster around a few unglamorous causes. Cloud breaches are driven overwhelmingly by misconfiguration and mismanaged access rather than by flaws in the cloud platforms themselves. Gartner captured this years ago with a projection that has aged well: through 2025, it estimated, 99 percent of cloud security failures would be the customer's fault. Identity is the sharpest edge of that problem. A 2022 Unit 42 study of more than 680,000 identities across 18,000 cloud accounts found that nearly 99 percent of cloud users, roles, and resources held permissions they had not used in 60 days or more. Excess permission is standing attack surface.

Enterprise IT has the same shape at larger scale. Verizon's 2025 Data Breach Investigations Report found that credential abuse was the single most common way attackers got in, involved in 22 percent of breaches, while exploitation of vulnerabilities accounted for 20 percent and rose 34 percent year over year. The breaches that hurt most are the ones that span environments: IBM's 2025 Cost of a Data Breach report put the global average breach at 4.44 million dollars, and breaches involving data spread across public cloud, private cloud, and on-premises at 5.05 million, the highest of any configuration.

Severity scores lie; attack paths tell the truth

One finding should change how a cloud or enterprise program spends its time. When XM Cyber analyzed more than 40 million exposures across millions of critical assets in 2024, it found that roughly 74 percent of them were dead ends, giving an attacker little or no onward movement. Only about 2 percent sat on choke points, the junctions where many attack paths converge on the way to something valuable. A small subset of exposures put more than 90 percent of critical assets at risk.

The same research made a related point that vulnerability-only programs tend to miss: about 80 percent of exposures came from identity and misconfiguration issues, while CVE-based vulnerabilities made up less than 1 percent of the average organization's exposure landscape. If you are ranking work by CVSS score, you are sorting the least of your problems.

This is why a severity score, on its own, is a poor way to decide what to fix. A "critical" vulnerability on an isolated asset with no path to anything may be safely ignored for weeks, while a "medium" misconfiguration that opens a route from an internet-facing app to a production database is the one that ends up in an incident report. The only way to tell them apart is to look at how findings connect, in your specific environment, into paths an attacker could walk.

What CTEM adds in cloud and enterprise

Applied to cloud and enterprise, the CTEM loop does three things a scanner does not.

  • It models attack paths, not lists. Prioritization is based on where a finding sits in the graph of your environment and what it leads to, so a misconfiguration that unlocks lateral movement outranks a high CVSS score that goes nowhere.
  • It validates exploitability. Before you spend a change window on something, validation proves whether the path is actually usable. That turns "we have 4,000 findings" into "these 30 are exploitable and reach crown jewels."
  • It closes the loop. Mobilization assigns the fix, tracks it, and re-checks that the path is gone, so remediation is measured by exposure removed rather than tickets opened.

The volume problem does not get solved by finding more. It gets solved by proving less, precisely.

Where Piscium Radius fits

Piscium Radius runs that loop across multi-cloud and hybrid estates. A few concrete, already-published specifics:

  • Multi-cloud and SaaS coverage. Radius integrates natively with AWS, Microsoft Azure, and Google Cloud Platform, and discovers and validates SaaS through Microsoft 365, Google Workspace, and Okta. It detects ephemeral and serverless assets (containers, Kubernetes workloads, Lambda, and Cloud Functions) as they are provisioned.
  • Attack paths, including cross-cloud. It models paths that span multiple accounts, subscriptions, and projects, including chains that traverse from one cloud to another and into on-premises systems, so lateral movement is visible rather than assumed.
  • Validation, then fixes that fit the workflow. Where a CSPM tool tells you a misconfiguration exists, Radius validates whether it is exploitable, then generates remediation guidance including infrastructure-as-code fixes for Terraform, CloudFormation, and Pulumi. It complements your existing cloud posture tools rather than replacing them.
  • Closed-loop remediation. Validated findings become tickets with owners and SLAs, and Radius re-validates after a fix to confirm the path is closed.

Two honest notes. Piscium is an early-stage company, and any before-and-after figures in our material are modeled or illustrative rather than production results. We align our own testing to the OWASP Autonomous Penetration Testing Standard (APTS) and do not claim compliance certifications we have not earned.

Frequently asked questions

Is Piscium a CSPM tool? No, and it is not trying to be. Cloud security posture management tools detect misconfigurations. Piscium Radius takes those findings (and its own discovery) and validates which misconfigurations are actually exploitable by modeling attack paths, then drives the exploitable ones to a confirmed fix. Many teams run a CSPM tool and Piscium together.

Does it work across more than one cloud? Yes. Radius covers AWS, Azure, and GCP, and specifically models cross-account and cross-cloud attack paths, which are the blind spots that appear at the seams between providers.

We already have too many findings. How does adding a tool help? The point is to reduce what you act on, not increase it. By validating exploitability and ranking by attack path, the goal is to turn thousands of findings into a short list that actually reaches critical assets. In our modeled scenarios, exploitability validation reduces the actionable set substantially, though results vary by environment.

Can it suggest the actual fix? When Radius validates a cloud misconfiguration as exploitable, it generates remediation guidance, including infrastructure-as-code fixes for Terraform, CloudFormation, and Pulumi, for your team to review and apply.

For the framework basics, see What is CTEM? and ASM vs. CTEM. For the industrial version of this argument, see CTEM for OT/ICS.

Sources


Want to see which of your cloud findings actually reach a crown jewel? Schedule a technical demo to watch Piscium Radius map and validate real attack paths across your cloud, enterprise, and OT estate.