CI/CD pipeline secrets and cloud security assessment gaps your annual review misses

A typical annual cloud security review captures the state of an environment on the day the engagement closes. Two weeks later, a developer adds a third-party integration, a CI/CD workflow gets a new IAM role, and a decommissioned workload leaves an orphaned service account behind. The posture the assessor signed off on is no longer the posture in production. This is the gap where the most common cloud breaches now live: not in zero-days, but in the credentials and non-human identities that pile up between CI/CD pipeline secrets cloud security assessment cycles.

In May 2026, GitGuardian disclosed that a public CISA GitHub repository had been exposing plain-text passwords, AWS tokens, and Entra ID SAML certificates for more than six months before anyone noticed. That incident is the textbook version of a much wider pattern, and it sets up the four attack paths CTDefense sees most often when a follow-up engagement goes deeper than the previous one.

Why cloud posture drifts the moment the review closes

The honest answer to what an annual assessment actually tests is that it covers misconfigurations, IAM trust policies, and exposed storage, and its findings reflect posture at the moment of engagement, not the credentials and service accounts added in the weeks after. That is not a flaw in the methodology. It is a structural property of point-in-time assessments.

According to Datadog’s State of Cloud Security 2025, “59% of IAM users have an active access key older than one year.” More than half of AWS IAM users carry long-lived credentials that persist well beyond any sensible rotation window. Some of those keys existed at the time of the last review. Many did not. The assessment captured the day-one map, and then the map kept changing.

The follow-up question is the one buyers ask after the report lands: what does the engagement actually test, and what does it miss? A review tests what is in scope on the day, and misses what arrives after. That answer is uncomfortable, but it is the starting point for a more useful conversation about cadence.

Attack path 1: leaked CI/CD secrets and IAM role assumption

The first path is the one the CISA incident illustrates. A secret ends up somewhere it should not be (a public repository, a build log, a Terraform state file in an open bucket, a Slack message), and the rest of the chain writes itself.

How do attackers use leaked CI/CD secrets in practice? A leaked GitHub Actions secret is enough to call sts:AssumeRole, inherit the pipeline’s IAM permissions, and reach whatever S3 buckets or databases that role can touch. No zero-day, no novel technique. This IAM role assumption attack is well-documented; the only variable is whether the pipeline’s role was scoped tightly or, as is more common, given the permissions the developer needed to ship the change quickly.

The team’s recurring finding on this path:

• Build logs are credential goldmines. CI runners print environment variables on error, store artifacts that include .env files, and cache containers that bake in tokens. None of these are visible to a CSPM scanner.
• Pipeline roles outlive the pipelines. When a workflow is renamed or removed, the IAM role it assumed often stays in place, ready to be assumed by a leaked key that was issued to it months ago.
• Trust policies are written for convenience. A wildcard in the Condition block of a sts:AssumeRoleWithWebIdentity policy turns a federated identity check into a free pass.

The Wiz Cloud Threat Retrospective 2026 reports that “these entry points were not novel, but they remained highly effective, accounting for roughly 80% of documented cloud intrusions.” Four-fifths of real-world cloud breaches trace back to well-known, preventable weaknesses. The question for the security buyer is not whether the path is known, but whether the assessment proved that the path is currently open in their environment.

Attack path 2: over-privileged third-party integrations added post-review

The second path is the one a year-old report cannot cover by definition. A new SaaS tool gets connected to production. The OAuth or service-principal grant requested by that tool is broader than the integration actually needs. The security team signs off because the alternative is blocking a business workflow.

Datadog’s State of Cloud Security 2025 also found that “12.2% of third-party integrations are dangerously overprivileged.” Over one in eight third-party connections has excessive permissions. Most of those connections were added after the last engagement concluded; the review captured the integrations in place on day one and could not see what was added in week ten.

What the team typically uncovers on this path:

• Read-only marketing tools granted write access to identity providers or to S3 buckets used for billing exports, because the consent screen offered no granular option.
• Observability platforms with cross-account IAM roles that allow assuming roles in production from a less-protected analytics account.
• Old integrations from vendors no longer in use. The contract ended; the role did not.

These integrations rarely surface in a CSPM dashboard because they look like normal, sanctioned activity. They surface in a pentest because the assessor follows the chain from the integration’s stated scope to the role’s actual permissions and into the data the role can reach.

Attack paths 3 and 4: stale service accounts and non-human identity sprawl

The third and fourth paths share a common root cause: the cloud identity estate grew faster than the inventory that tracked it.

Permiso’s State of Identity Security 2026 found that “comprehensive identity visibility plummeted from 93% in 2024 to just 46% in 2025.” Organisations lost the ability to track what their cloud identities can reach, and when, even as the identity estate kept expanding. That is the structural condition under which the next two paths thrive.

Path 3: forgotten service accounts. When a workload is decommissioned, the account that backed it is often left behind because no one is certain which other job still uses it. Over months, those accounts collect access through cleanup scripts that never run and IAM policy attachments that never get reviewed. Stale service account exploitation is straightforward once an attacker holds any one of their long-lived keys: the account looks legitimate, its activity does not trigger anomaly detection, and its permissions chain into the data it was originally provisioned to touch. A scanner can flag that the account is unused. It cannot prove what an attacker could do with it.

Path 4: non-human identity sprawl, including AI agents. The newer variant is the proliferation of non-human identity security problems created by AI agents and automation tools spun up by individual teams without central oversight. An agent gets an API key to read a database, then a second key to write to a different system, then a third for an external SaaS. The keys are long-lived because the agent runs continuously. They are scoped broadly because the developer did not know in advance which tables or buckets the agent would need. None of this is malicious. All of it is invisible to the assessment that closed six months ago.

Can a vulnerability scanner find stale cloud credentials? A scanner can flag that a long-lived key exists. It cannot prove whether that key chains to a lateral-movement path. That proof requires active exploitation, which is what a pentest delivers.

What exploitation proof changes about the remediation conversation

The thread tying all four paths together is the difference between flagging that a credential exists and proving what an attacker can do with it. A pentest that proves an IAM key is exploitable is categorically different from a CSPM alert that says the key exists. The first generates a remediation ticket with an attack chain attached, a blast radius, and a priority that maps to business impact. The second generates noise that competes with thousands of other findings for the same engineering attention.

CTDefense’s Cloud Security Assessment is built around that distinction. The team’s previous post on what CSPM tooling misses on IAM key exposure walks through the static-key gap in detail; this piece picks up where that one stops, at the dynamic gap that opens between reviews.

The cadence problem is real, and an annual deep engagement is the right shape for some questions, the wrong shape for others. Between full reviews, an autonomous AI pentest platform like PentX can re-test the highest-impact paths after every infrastructure change, which is what continuous cloud security validation actually looks like in practice. The team’s view on how automated pentest tooling fits into a cloud validation cycle covers the limits and the trade-offs honestly: continuous validation is good at catching regressions in known patterns, and it does not replace senior judgment on novel architectures or business-logic flaws. The two cadences complement each other; neither stands alone.

For mid-market finance, technology, and SaaS organisations that completed an annual engagement in the last twelve months, the practical next step is narrow. Look at the credentials, service accounts, and integrations created since that report closed. Treat them as in-scope for the next assessment, ahead of any new feature work. The drift is the gap, and the gap is where the breach starts.