Most organizations running on AWS, Azure, or Google Cloud already have a CSPM tool flagging misconfigurations, plus the native security console of each provider sending alerts. The picture those tools paint is reassuring. Yet a cloud security assessment IAM access keys engagement, the kind a human team runs, almost always finds the same thing: a long-lived credential, sitting in a CI artifact or a forgotten developer laptop, that quietly unlocks a path the dashboard never connected.

That is the gap CTDefense’s cloud security review is built to close. The work is not a controls checklist. It is the deliberate walk through how a real attacker would chain four common findings, each of which a CSPM correctly logs as “medium”, into account-owner access.

According to Datadog’s 2025 State of Cloud Security, “59% of AWS IAM users, 55% of Google Cloud service accounts and 40% of Microsoft Entra ID applications had an access key older than one year.” A majority of identities across every major cloud provider are carrying credentials that should have been rotated several quarters ago. That is the starting condition for almost every engagement the team runs.

Why CSPM Tools Under-Call the Credential Risk

A CSPM tool is structured to find and rank individual misconfigurations. It will flag a key older than 90 days. It will flag a role with *:* in its policy. It will flag a public storage bucket. Each item lands in its own row, with its own severity score, and very often each one is medium-rated on its own merits.

What the tool does not do is chain them. It does not say: “the key flagged in row 412 belongs to a CI service account, that service account assumes the role flagged in row 67, and that role can read the bucket flagged in row 891.” The chain is the exploitation path. The chain is what the cloud security review findings actually have to surface, because that is what an attacker does the moment they pick up a single leaked credential.

This is the practical answer to “what does a cloud security review cover that a CSPM tool does not?” A CSPM flags individual misconfigurations in isolation. A human-led review traces them, in order, from a stale key to an over-privileged role to exposed storage, into the actual sequence an attacker would follow. The output is not a longer list. It is a shorter list with arrows between the items.

The Four-Step Chain: From Stale Key to Data Exfil

The pattern below is not theoretical. It mirrors what the team sees in roughly two out of three mid-market and enterprise cloud reviews, regardless of whether the organization runs on AWS, Azure, or GCP.

• Step 1: A long-lived access key enters the attacker’s hands. Usually through a hardcoded secret in a public or near-public repository, a CI artifact, or an infostealer log harvested off a developer endpoint.
• Step 2: That key belongs to an over-privileged identity. The compromised principal can read or assume far more than its job description requires.
• Step 3: The identity reaches a high-value resource through trust relationships. Role chaining, cross-account assumptions, or service-principal pivots to production.
• Step 4: Data leaves through an unintended path. A storage bucket, a snapshot, a backup, or a serverless endpoint that holds production data the attacker now reads at will.

Each step is a finding a CSPM may have flagged. The chain is what makes them critical. Treat the four steps as independent and you remediate four mediums. Treat them as one path and you eliminate a breach.

Hardcoded Secrets in CI/CD Pipelines: The Leak That Keeps Leaking

The initial-access half of the chain is getting worse, not better. GitGuardian’s State of Secrets Sprawl 2026 report found that “28.65 million new hardcoded secrets were added to public GitHub commits in 2025 alone, a 34% increase year over year.” Developers are leaking credentials faster than organizations are rotating them.

Worse, rotation lag means old leaks stay live for years. The same report confirmed that 64% of the secrets identified as exposed in 2022 were still valid and exploitable in January 2026. So yes, hardcoded secrets in GitHub can be exploited long after rotation, because rotation never actually happened. A 2022 leak is, statistically, more likely than not to still grant production access today.

That is the dominant initial-access vector for the chain above. A cloud review scopes the build artifacts, the runner logs, and the environment variables of the pipelines themselves, not just the source repositories. That is where the access keys often hide. The same kind of supply-chain credential exposure shows up in pipeline integrations more broadly, which the team has covered separately in a recent post on MCP-style integration risks.

Over-Privileged Service Accounts Make Escalation the Default

The middle of the chain, step two, is the one that turns a leaked key from a nuisance into a breach. Orca Security’s Top 5 Cloud Security Risks of 2025 found that “93% of organizations have at least one overprivileged service account.” Near-universal over-privileging means privilege escalation is not a special case. It is the default outcome of any credential compromise.

In practice, the team finds three patterns repeatedly:

• CI service accounts with production write access. The pipeline needs to deploy, so the principal gets full write on the production account. The key that runs the deploy can also empty the database.
• Service principals with directory-wide read. An Entra ID application that needs to list users for one integration ends up with Directory.Read.All, which means a single compromised secret enumerates the entire tenant.
• Cross-account assume-role chains nobody reviewed. A sandbox role can assume a staging role that can assume a production role, because at some point three years ago that was convenient.

The recommendation in these cases is not “remove the account.” It is to separate the permissions the workload actually needs from the broader administrative scope it has accumulated. The team scopes the change in business language, names the workloads that break if the change happens too quickly, and sequences the rotation so production keeps running.

How Long Should an Access Key Be Valid

The question of how long an IAM access key should be valid has a short answer. AWS, Google Cloud, and Microsoft guidance all point to 90 days or less as the rotation horizon. The lived reality, per the Datadog data above, is that the majority of IAM users across all three major clouds carry keys older than a year. Closing that gap is one of the highest-impact, lowest-controversy fixes a review surfaces. It is also the one that drifts back open within months unless the rotation is automated and monitored, not run by a calendar reminder.

For organizations preparing for an ISO 27001 cloud security review or a DORA cycle, the auditor expectation is now explicit: key lifetime control needs to be a documented, evidenced process, not a quarterly intent.

Step Four: Exposed Compute Closes the Loop

The final step in the chain often gets less attention because it sits at the end. Wiz Research’s Cloud Data Security Snapshot 2025 found that “54% of cloud environments have exposed VMs and serverless instances containing sensitive information like PII or payment data.” Even when the credential compromise stops at read-only, more than half of cloud environments still hand the attacker a directly reachable compute asset with sensitive data on it.

The team treats step four as the validation point for the engagement. If a chained finding stops at “the attacker has read access to an over-privileged role” without reaching live data, the severity is real but bounded. If the same chain ends at a snapshot containing customer records, the same set of findings becomes critical. The chain decides the severity; the controls list cannot.

What a Human-Led Cloud Security Review Actually Scopes

The CTDefense Cloud Security Assessment is scoped around the chain, not the controls. The engagement covers, in one engagement:

• IAM and identity. Key age and rotation cadence, over-privileged roles and service principals, trust-policy abuse, role-chaining paths across accounts and tenants.
• CI/CD credential exposure. Build artifacts, runner logs, environment-variable handling, integration tokens between source control, the CI platform, and downstream cloud accounts.
• Cloud-native data exposure. Storage buckets, snapshots, backups, and any serverless or PaaS endpoint that the chained identity can reach.
• Trust and pivot paths. Cross-account assume-role chains, on-prem to cloud federation, and identity bridges between the customer’s cloud and any managed-service provider’s tenant.

Each finding is reported with the chain it sits in, not as a standalone row. The remediation plan is sequenced so that breaking the highest-impact path takes priority over closing the longest list. Where the work overlaps a broader procurement or supplier review, the team aligns its output with the same scope the customer would use in a third-party security assessment, so cloud findings feed the supplier-risk picture instead of duplicating it.

The closing observation, after a few hundred of these engagements, is consistent. Organizations approaching an ISO 27001 re-certification, a DORA cycle, or a NIS2 review do not lack telemetry. They have CSPM, they have native cloud security consoles, they have logs. What they lack is the connecting tissue between the individual alerts and the actual exploitation path. A cloud review is the engagement that draws those arrows, in business language, before an attacker does it in production.

Organizations in Finance, Technology, and Critical Infrastructure that last ran a cloud review 12 to 18 months ago are typically sitting on at least one viable chain today. Looking at it deliberately, with a team that walks the path rather than counts the rows, is the part the dashboards cannot do.