Compromised CI token

Your pipeline holds the keys to everything it deploys: steal its token and you inherit production.

The idea

A CI/CD pipeline is trusted machinery: it builds your code, then reaches out with powerful, long-lived secrets (cloud deploy keys, container-registry creds, package-publish tokens) to ship the result. Whoever holds those secrets can do anything the pipeline can do.

A compromised CI token is what happens when that secret leaks: a poisoned dependency reads the environment, a fork's pull request runs with secrets attached, or a token gets echoed into a public build log. The attacker now acts as the pipeline's identity (publishing packages, deploying to prod, pushing code) and nothing about the request looks unusual. The durable fix is to make the secret nearly worthless to steal: short-lived, federated, and scoped to one job.

Press play to watch a long-lived deploy token leak from the pipeline, get abused, and then get contained.

How it works

The failure mode: a static deploy token sits in CI secrets forever, broadly scoped, and gets handed to every job, including builds running untrusted code. One leak and the attacker has a working credential for as long as nobody rotates it.

The fix is to stop storing a long-lived secret at all. The job mints a short-lived token at runtime by federating its own verified identity (OIDC), scoped to exactly one action, and untrusted fork builds never receive any secret. A leaked token is useless minutes later.

# GitHub-Actions-style deploy job — no static secret
permissions:
  contents: read          # least privilege by default
  id-token: write         # allow minting an OIDC token

on:
  push:
    branches: [main]      # deploy only from trusted refs,
                          # NOT pull_request from forks

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4   # pin to a SHA in prod
      - name: Mint short-lived cloud creds via OIDC
        uses: cloud/assume-role@v2
        with:
          role: arn:cloud:iam::role/deploy-app-only
          ttl: 900                  # 15 minutes, then dead
          # no access-key secret — identity is federated
      - run: ./deploy.sh            # scoped to deploy, nothing else

Signals

Signal	What a compromised CI token looks like
Deploy source	Deploy or publish from an unexpected workflow or branch
Release path	A package version published outside the normal release process
API targets	Cloud calls from the CI identity to services it never touches
Build logs	A secret printed or echoed into the build output
Token lifetime	The token used after its job already finished

Watch out for

Long-lived static deploy keys. A permanent access key in CI secrets is a standing liability: one leak stays valid until a human notices and rotates it. Prefer per-job OIDC tokens that expire in minutes.
Running untrusted fork PRs with secrets. If a fork's pull request can read your secrets, anyone who opens a PR can exfiltrate them. Gate secret access to trusted refs and require approval for fork workflows.
Over-broad token scope. One token that can deploy, publish, and push everywhere turns any leak into total compromise. Scope each credential to a single action and project.
Secrets echoed into logs. A stray echo $TOKEN or a verbose flag can dump credentials into logs that outlive the job and may be public. Mask secrets and never print them.
Unpinned third-party actions. A floating tag like @v3 can be moved to malicious code; a poisoned dependency runs inside your runner with its secrets. Pin actions and dependencies to a SHA or hash.

Worked example

A build installs a dependency that was transitively poisoned: a sub-dependency added a post-install script that reads process.env, finds NPM_PUBLISH_TOKEN, and quietly POSTs it to an attacker host. Because the token is a long-lived publish credential, the attacker waits a day, then publishes a backdoored patch version. It's downloaded ~50,000 times before a maintainer notices an unexpected release and pulls it.

Contrast the OIDC design: there is no stored publish token to read. The job mints a token with a 15-minute TTL, scoped to deploy only: it can't publish packages at all. Even if the exfiltration script grabs it, the credential is dead minutes later and can't reach the registry. The same leak that caused a 50,000-install incident becomes a non-event.

Check yourself

Your CI deploy token was printed in a public build log. Beyond rotating it right now, what's the best durable fix?

Coach note: rotation and private logs shrink the window, but a long-lived secret still leaves one open. The durable move is to stop having a stealable standing credential at all.