auditing-cicd-oidc-trust

name	auditing-cicd-oidc-trust
description	Audit continuous-integration pipelines for the trust they extend to untrusted input: workflows that run on incoming change requests from forks while holding repository secrets, steps that let attacker-controlled content reach a privileged command, and cloud role trust conditions that accept a pipeline's short-lived token too broadly. Covers secret and token exposure on fork-triggered runs, poisoned-pipeline execution, and over-broad trust on the identity claim a pipeline presents to a cloud account. Use when reviewing CI/CD configuration, pipeline identity, or the boundary between a build and the cloud it can reach. An exploitable token or command from untrusted input is the finding.
license	MIT

Auditing CI/CD OIDC trust: the pipeline is an identity, treat its inputs as hostile

A modern pipeline is a privileged identity. It holds secrets, and it presents a short-lived token that a cloud account trusts and exchanges for real credentials. The danger is that the same pipeline also runs code and content that outsiders can influence: a change request from a fork, a dependency, a script in the repository. When untrusted input reaches a privileged step, or when the cloud trusts the pipeline's token too broadly, an outsider borrows the pipeline's identity. The audit is about where untrusted input meets pipeline privilege.

When to use

• You are reviewing CI/CD workflows, their triggers, and their secret and token access.
• A pipeline exchanges a short-lived identity token for cloud credentials.
• Any workflow runs on input from forks or external contributors.

Scope check

Review pipeline configuration in repositories and accounts you own or are authorized to test. If you can't name the authorization, stop.

The loop

1. Inventory triggers and what each run can reach. For every workflow, record what event starts it, whether that event can be caused by an outside contributor, and what the run holds: repository secrets, an identity token, write permission to the repository or a registry. A run that both accepts outside input and holds privilege is the shape to chase.

2. Find fork-triggered runs that keep secrets. A workflow that runs on an incoming change from a fork and still receives repository secrets or a privileged token hands those to code the outsider proposed. Confirm which triggers expose secrets on untrusted content, rather than assuming the default is safe.

3. Trace untrusted input to a privileged step. Follow attacker-influenced content, a change-request title, a branch name, a file in the fork, a dependency script, into any step that runs a command, publishes an artifact, or requests cloud credentials. Content that reaches a shell or a publish step is poisoned-pipeline execution.

4. Read the cloud trust condition on the pipeline token. For each role the pipeline can assume, read the condition on the token it presents. Confirm the condition pins the specific repository and branch or environment, and the expected token audience. A condition that accepts any repository in the organization, any branch, or omits the audience trusts too much.

5. Check what the borrowed identity can do. If untrusted input can reach the token, or the trust is too broad, determine what the exchanged cloud credentials grant. A tightly scoped deployment role limits the damage; a broad role turns a pipeline foothold into account access. This links straight to identity-graph escalation.

6. Confirm and record. Confirm by driving untrusted input through the path in an authorized repository and observing a secret read, a credential minted, or a command run; or by showing the trust condition accepts a token it should not. Kill the lead if fork runs carry no secrets, untrusted input never reaches a privileged step, and every trust condition pins repository, branch, and audience. Record the trigger, the path, and the privilege reached.

Where pipeline trust leaks

• Fork-triggered runs with secrets are the classic exposure. Untrusted content should never run in a context that holds the pipeline's privilege.
• Content is code. A title, a branch name, or a filename that reaches a shell is an execution path, not just data.
• The trust condition is the real access-control. A token is only as safe as the condition that decides which token a cloud account will exchange.
• A pipeline foothold is worth what its role grants. Scope the assumed role, or a build compromise becomes an account compromise.

Worked example (a confirm and a kill)

Confirm. A workflow runs on incoming change requests from forks so it can post a preview, and that trigger receives repository secrets. A contributor opens a change whose build script reads the secrets and sends them to an external address. The run executes the fork's script with secrets present. Confirmed secret exfil on fork-triggered run, critical, remediation = run untrusted changes in a trigger that carries no secrets, and move any privileged step to a separate run gated on a trusted review.

Kill. Fork changes run only in a trigger with no secrets and no token, the privileged deploy runs on a trusted branch push, untrusted input is never interpolated into a shell, and the deploy role's trust condition pins the exact repository, branch, and token audience. Every attempt to reach a secret or mint a credential from a fork dead-ends. Killed, kill_reason = "no secrets on untrusted trigger, no untrusted input reaches a privileged step, trust condition pins repository, branch, and audience."

Rationalizations to reject

• "Only maintainers can merge." → Exposure is at run time, not merge time. A fork-triggered run executes before anyone merges.
• "It is just a preview build." → A preview build that holds secrets or a token is a privileged build. What it holds is what leaks.
• "The token is short-lived." → Lifetime does not scope power. A broad trust condition exchanges that short-lived token for real credentials on demand.
• "We pin the repository in the trust." → And the branch and the audience? A condition missing either accepts a token from a context you did not intend.

Executing this in practice

You need every workflow definition, its trigger semantics and secret and token access, the data flow from untrusted input to privileged steps, and the cloud trust conditions on each assumable role. A view that connects a trigger to the secrets it exposes and traces untrusted content to a command or credential request is ideal; driving the input through an authorized pipeline is the confirmation.

Related

• hunting-iam-privilege-escalation-paths - what the borrowed pipeline identity can reach once its token is exchanged for cloud credentials.
• hunting-supply-chain-risks - poisoned dependencies and pipeline execution as a broader class; this is the identity and trust-boundary slice.
• finding-fail-open-flaws - a trust condition that accepts too much is the fail-open shape applied to pipeline identity.
• FINDING-SCHEMA.md - source = untrusted input to the pipeline or a token the trust wrongly accepts, sink = the secret, credential, or command it reaches.