CI/CD Pipeline IAM Permissions and Supply Chain Breach Exposure

A CI/CD pipeline is a service account with more standing access than most humans will ever hold, and almost nobody governs it that way. Overprivileged, poorly scoped IAM permissions inside the pipeline are what turn a single leaked token into a full supply chain breach, not just a bad afternoon for one repo. Closing that gap means treating pipeline identities the way a bank treats a vault key, not the way most orgs treat a build server: as background noise. The data on secrets sprawl, the OWASP CI/CD risk framework, and a run of 2025 and 2026 incidents all point at the same root cause. This piece walks through why, and what actually chains together when it breaks.

Pipeline privilege versus engineer privilege

If you ask a security engineer what the most powerful identity in the org is, most will point at a human: an admin, an infrastructure engineer with root, maybe the CTO. Wrong answer. The most powerful identity is usually a build job that nobody in the room can name.

Pipelines hold standing access to source repositories, build systems, package registries, cloud credentials, and production deployment targets, all at once. A single pipeline identity often touches dev, staging, and production under the same IAM role, because splitting that role took an extra afternoon nobody had. Compare that to the engineer sitting at a laptop: MFA, device management, EDR watching every process, DLP flagging anything that looks like exfiltration. The pipeline gets none of that scrutiny and pulls in arbitrary third-party code (actions, plugins, dependencies from registries nobody vetted) while running under a policy more permissive than the laptop it replaced.

The mental model hasn't caught up. Security teams still center protection on the workstation, the place a human sits. The pipeline gets filed under infrastructure, like a router or a load balancer, not under identity, where it actually belongs. That's the whole problem in one sentence: it's an identity wearing an infrastructure costume.

Secrets sprawl as the primary exfiltration surface

The scale here isn't subtle. GitGuardian's State of Secrets Sprawl 2026 report counted 28.65 million hardcoded secrets added to public GitHub repositories in 2025, a 34% jump year over year. Secrets sprawl is outrunning the population that creates it: since 2021, leaked secrets grew 152% while GitHub's public developer base grew 98%. The secrets are multiplying faster than the developers writing them, a stat that should make a security leader put down their coffee.

AI coding assistants aren't helping. Industry data shows an 81% year-over-year jump in leaked AI-service credentials, and commits produced with AI assistance contribute disproportionately to secrets leaks. Autocomplete is fast. Autocomplete does not check whether the API key it just suggested belongs in a public commit.

Internal repos are dirtier than public ones, which should worry an internal security team more than any of the above. GitGuardian found 32.2% of internal repos contain at least one hardcoded secret, versus 5.6% of public repos. Public GitHub gets the headlines because anyone can scan it. Internal repos are the blind spot, sitting behind the firewall, assumed safe because nobody outside the company can see them. Nobody inside the company is looking either.

The IAM misconfigurations that make a pipeline foothold catastrophic

OWASP calls this CICD-SEC-2, Inadequate Identity and Access Management, and the framing is blunt: the sheer number of human and machine identities spread across source control, build systems, registries, and deployment tools makes them hard to govern, and poorly managed identities raise both the odds of compromise and the size of the blast radius once it happens.

Three failures appear repeatedly across build systems. Build systems run with administrative privileges nobody asked for, deploying to dev, staging, and production under one shared role because provisioning three separate roles felt like busywork. Pipelines authenticate with static access keys sitting in CI/CD variables: keys that don't expire, aren't scoped to a specific action, and outlive the employee who created them. One leaked key is persistent access, full stop, until someone notices and rotates it. And accounts for former employees or decommissioned systems stay live across CI/CD tooling because deprovisioning one system does not mean deprovisioning all of them. That's an open door nobody remembered to lock.

Wiz's State of Code Security Report 2025 puts numbers on the first two: 61% of organizations have secrets exposed in public repositories, including cloud credentials, and 35% of enterprises run non-ephemeral self-hosted runners with weaker configurations, opening lateral movement paths across repos and cloud environments. Non-ephemeral means the runner sticks around between jobs. Anything an attacker plants on it sticks around too.

Exposed or overprivileged credentials make almost every other CI/CD risk on the list worse, and OWASP's CICD-SEC-6, Insufficient Credential Hygiene, is the amplifier that produces this effect. Exposed or overprivileged credentials make almost every other CI/CD risk on the list worse. A malicious package is more dangerous if it can steal a token on its way out the door. A poisoned pipeline is more dangerous if the compromised job can reach production credentials instead of a sandbox with nothing in it.

How OWASP Top 10 CI/CD risks chain together

OWASP built the Top 10 CI/CD Security Risks specifically to map how attackers exploit the trust relationships that carry code from a developer's laptop to a production server. The framework treats the pipeline itself as the attack surface, not just the thing that hosts an application.

None of the ten risks operate alone. Insufficient Flow Control, tracked as CICD-SEC-1, means no required reviews and no protected branches, so one compromised account can push straight to production. CICD-SEC-2, insufficient access controls on build identities, decides how far an attacker can travel once inside. CICD-SEC-3, Dependency Chain Abuse, is a malicious package executing inside the build environment and grabbing whatever credentials the runner happens to hold. CICD-SEC-4, Poisoned Pipeline Execution, is an attacker rewriting pipeline config so the build job's own permissions carry out the attack for them. CICD-SEC-5, Insufficient Pipeline-Based Access Controls, means access isn't scoped per pipeline or per stage, so code running in one build can reach credentials meant for a completely different one. CICD-SEC-6 is credential hygiene, already discussed. CICD-SEC-7 is weak default configuration in source control managers, CI servers, runners, and artifact repos, an easy foothold for anyone who bothers to check the defaults. CICD-SEC-8 is ungoverned third-party services: plugins and actions inheriting pipeline permissions with zero visibility into what they actually do. CICD-SEC-9 is missing artifact integrity checks, no signing, no verification, so a malicious build artifact can walk through the trusted delivery pipeline and land in production looking perfectly legitimate. CICD-SEC-10 is insufficient logging, meaning attackers operate in the dark and defenders can't reconstruct what happened after the fact even if they wanted to.

Credential exposure, the mechanism defined by CICD-SEC-6, turns a foothold in any single category into a full supply chain breach instead of a contained, boring incident that gets fixed by Friday, and it drives most of the other nine risks. Credential exposure is the mechanism that turns a foothold in any single category into a full supply chain breach instead of a contained, boring incident that gets fixed by Friday. The XZ Utils backdoor is the patient version of this: an attacker spent roughly two years building trust inside an open-source project before slipping in a backdoor targeting SSH on Linux systems. The pipeline wasn't collateral damage. The pipeline was the delivery mechanism.

Five real incidents that show the breach chain in practice

Theory is cheap. These failures occurred, proving that theory is cheap.

The tj-actions/changed-files incident hit an action used across more than 23,000 GitHub repositories. Attackers retroactively rewrote multiple version tags to point at one malicious commit, so any pipeline pinned to a tag, instead of a specific commit SHA, pulled the payload without anyone touching a line of that pipeline's own code. CVE-2025-30066 tracked the fallout: remote attackers could read action logs and pull secrets straight out of them. The IAM failure here is ungoverned inheritance, a third-party action getting the same permissions as the pipeline calling it, with no artifact integrity check to catch the swap.

The Trivy GitHub Action compromise ran in two stages. In late February 2026, a misconfigured pull_request_target workflow let attackers steal a privileged Personal Access Token belonging to Aqua Security. In March 2026, that stolen token was used to force-push malicious code to 76 of Trivy's 77 version tags. The action kept working and the legitimate scan still ran, silently harvesting CI/CD secrets across more than 10,000 affected workflows while nothing looked broken. That's the nightmare version: a breach that looks like Tuesday.

The AsyncAPI incident took patience over speed. One attacker submitted 37 pull requests across 58 days, opening with legitimate contributions that built up contributor trust the way anyone earns it, slowly and boringly. Later PRs quietly modified workflow files and package scripts. Because the CI environment ran under pull_request_target semantics with access to publish credentials, malicious scripts could push trojaned package versions out to the registry. The affected packages carried 2.9 million combined weekly downloads. Nobody flagged the pattern because static IAM controls don't watch for a slow trust-building con, they watch for a bad permission on paper.

The pull_request_target misconfiguration as an IAM design failure, not a workflow mistake

GitHub's pull_request event runs a workflow inside the context of the fork submitting the PR: no secrets available, and the GITHUB_TOKEN is read-only against the target repository. That's the safe default. pull_request_target flips it: the workflow runs in the context of the base repository, with full access to secrets, built specifically so maintainers can run credentialed workflows against PRs coming from outside contributors.

Nothing wrong with the design. The assumption baked into how orgs use it is the problem: the same credential scope gets handed to pull_request_target workflows as to fully trusted internal pipelines, with no behavioral control distinguishing a trusted code path from an untrusted one. A static IAM policy sees a permission grant. It does not see that the code executing under that grant arrived from a stranger on the internet an hour ago.

The AsyncAPI attacker's technique exploited exactly this blind spot: the slow accumulation of contributor trust that static access controls cannot distinguish from legitimate participation. Static access controls can't see a trust-building con in progress. They only see permissions, and the permissions looked fine the whole time.

AI agent layer and pipeline IAM governance urgency

AI agents are already working inside the CI/CD loop, and not in one narrow role. Some draft IAM policy alongside a feature PR, tools like Kiro, Copilot, and Claude Code reading application code and proposing AWS IAM policy to match it. Some refine existing policy by reading CloudTrail logs and opening PRs to tighten roles that look too loose. Some respond to AccessDenied events directly, reasoning in real time about whether the missing permission should just be granted.

Each of those agents inherits pipeline-level IAM permissions and acts at machine speed, faster than any human reviewer clicking through a PR. Access models built around a human clicking "approve" don't map onto an agent that can propose, and in some setups apply, a permission change in the time it takes a person to read the diff. Pipeline IAM was already the weak point before agents showed up to operate inside it. Handing that same loose, overprivileged, poorly audited access model to something that moves at machine speed doesn't shrink the risk. It just runs the same failure mode faster, with fewer humans in the loop to notice before the damage is done.