The CTEM validation stage in AWS, with real numbers

By the Pathbreak team · October 25, 2026 · 6 min read

Continuous threat exposure management is a program structure with five stages. Scoping decides which systems are in the program. Discovery finds the exposures in them. Prioritization ranks the exposures. Validation proves which ranked exposures an attacker could use. Mobilization gets the proven ones fixed by the people who own them. The definition is well covered elsewhere, so this post is about the fourth stage, in AWS, with numbers from a real account.

Where AWS programs stall

Discovery in AWS is well served. A CSPM or a scanner will produce thousands of findings in an afternoon: public buckets, overly broad policies, unused keys, missing encryption, roles with wildcard trust. Prioritization is also well served, with severity scores, exploitability scores, and asset criticality tags that sort the list.

The stall comes at the next stage. A ranked list of 3,000 findings is still 3,000 findings, and the ranking is an estimate. A critical finding on a role that an SCP has already fenced in changes nothing. A medium finding on a role that trusts a vendor's account might be the path into production. Without validation, the team is choosing work by score, and the score was computed without reading the authorization that decides whether an attack works.

What validation looks like in the AWS control plane

In AWS the attacker's moves are API calls. Each call is allowed or denied by a set of documents that AWS evaluates together: the caller's identity policies, any permission boundary, the service control policies on the organizational unit, the trust or resource policy on the target, and the conditions on each statement. Validation means building the candidate chain, then resolving those documents for every step in the chain, the way AWS would. If every step resolves to allow, the path is proven. If any step resolves to deny, the path is removed from the list.

None of that requires executing anything. The proof is the authorization result, and reading policies needs only read access. That is what makes the stage continuous in practice: it can run every day on every account without a change window.

The numbers from the lab account

The Pathbreak lab account is the environment behind the numbers on the homepage. Here is what the validation stage produced there.

Those numbers show what validation is for. Thousands of candidate paths were not thousands of independent problems. Most of them ran through the same few roles, so a small number of changes, placed on the right principals, broke most of the proven paths at once. A severity-sorted list would have shown the same account as 4,942 items of roughly equal weight and sent the team to fix them one at a time.

What mobilization needs from validation

The fifth stage fails when the person who owns the role receives a finding they cannot act on. Validation should hand over three things. The proven path, as a chain with each hop named, so the owner can see why the role is on it. The specific change that breaks it: a Deny statement, a iam:PassedToService condition, a narrower trust policy, a removed permission, written as the change itself, ready to apply. And a confirmation: after the change ships, the path is re-evaluated and the result is recorded, so the ticket closes on evidence.

In the lab, 81 percent of the fixes were a single command. That matters for mobilization because a one-line change to an IAM policy goes through review in minutes, while a redesign of a role hierarchy goes into next quarter.

Making the stage continuous

Accounts drift with every deployment. A new role, a widened trust policy, a pipeline given iam:PassRole on a wildcard, and a path that was closed last month is open again. The validation stage only stays useful if it runs on a schedule and reports what changed, so the team sees new proven paths the day they appear and confirmed fixes that have since regressed.

Read-only validation makes that cheap. There is no agent, no change window, and no risk to production from the test itself, so daily runs across every account are the default.

What to ask a CTEM platform about AWS

Does it resolve SCPs, permission boundaries, trust policies, and condition keys for every step of a path? Does it rank by what a path reaches, across accounts? Does it name the change that breaks each path, and does it confirm the change afterwards? Can it run daily without executing anything in the account? The answers tell you what the platform will hand your team at the mobilization stage.

Pathbreak is built for this stage in AWS. The AEV for AWS post covers the validation method in more depth, and the analysis vs validation post walks one chain from reachable to proven.

Frequently asked questions