Secrets in CI skill for Codex

Done well means: no long-lived cloud key sits in CI when short-lived OIDC tokens will do, every secret is least-privilege and scoped to the jobs that need it, untrusted code (fork PRs, third-party actions) never reaches a secret, and logs and artifacts are clean. CI is a high-value target: it has credentials and runs code on every push.

Assess the pipeline first

rg -n -i "AKIA|aws_secret|AIza|ghp_|xox[baprs]-|-----BEGIN|password|token" \
   .github/ .gitlab-ci.yml .circleci/ Jenkinsfile   # static secrets committed in config
rg -n "secrets\.|\$\{\{ secrets" .github/workflows/
rg -n "uses:\s" .github/workflows/ | rg -v "@[0-9a-f]{40}"   # actions not pinned to a SHA
rg -n "pull_request_target|workflow_run" .github/workflows/  # dangerous triggers to review

Read AGENTS.md and the provider’s settings (repo/org secrets, environments, OIDC trust). Note which jobs actually need which secret; most need none.

Prefer OIDC over stored cloud keys

Replace static AWS_ACCESS_KEY_ID / GCP service-account JSON / Azure client secrets with federated short-lived credentials. The CI provider issues a signed OIDC token; the cloud exchanges it for a session scoped by a trust policy.

# GitHub Actions -> AWS, no stored keys
permissions:
  id-token: write        # required to request the OIDC token
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4   # pin to a SHA in practice
        with:
          role-to-assume: arn:aws:iam::111122223333:role/ci-deploy
          aws-region: eu-west-1

The AWS IAM trust policy must pin the subject tightly, or any repo can assume the role:

"Condition": {
  "StringEquals": {"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"},
  "StringLike":  {"token.actions.githubusercontent.com:sub": "repo:ORG/REPO:ref:refs/heads/main"}
}

• Scope sub to the exact repo and ref/environment. repo:ORG/* or a bare audience check is how misconfigured trust policies get abused across repos.
• GitLab (id_tokens), CircleCI and Buildkite have equivalent OIDC federation to AWS, GCP and Azure. Vault also accepts CI OIDC for dynamic, short-TTL secrets.
• Where a static secret is unavoidable (a third-party API with no federation), store it in the provider’s secret store with the narrowest scope and rotate it on a schedule.

Keep untrusted code away from secrets

The core rule: secrets are available to workflows triggered by trusted code, never to arbitrary fork contributions.

• GitHub: pull_request from a fork runs without secrets by default — keep it that way. pull_request_target and workflow_run run in the base repo’s context with secrets and must never check out and execute the PR’s code. If you need to build a fork PR with secrets (for example to deploy a preview), gate it behind an environment with required reviewers, or split into an untrusted build job (no secrets) and a trusted deploy job.
• Set least-privilege permissions: at the top of every workflow (contents: read default); grant id-token, packages, deployments only to the jobs that need them.
• Pin third-party actions to a full commit SHA, not a tag — a tag can be moved to malicious code. Review what an action does before adding it; it runs with your token and can read env. Prefer first-party or widely-audited actions.
• Use GitHub environments with protection rules and environment-scoped secrets so production credentials are not readable from a feature-branch run.

Stop leakage through logs and artifacts

• Register dynamic secrets as masks (echo "::add-mask::$VALUE"); provider masking only covers values it already knows. Never echo a secret, and avoid set -x/bash -x in steps that touch them.
• Do not pass secrets as command-line arguments (they show in process lists and some logs); use env vars or files with restricted permissions, deleted at job end.
• Exclude .env, credential files and ~/.aws from uploaded artifacts and caches; a cache key that captures a token persists it.
• Add a secret scanner to CI (gitleaks, trufflehog) and enable the provider’s push protection so a secret is caught before merge. Detection and rotation of committed secrets is $secret-scanning.

If a secret leaked

Treat exposure as compromise, in this order:

- [ ] 1. Rotate/revoke the credential at the provider now (do not wait to confirm misuse)
- [ ] 2. Invalidate derived sessions/tokens
- [ ] 3. Review access logs for use during the exposure window
- [ ] 4. Remove it from logs/artifacts; purge affected caches
- [ ] 5. Replace with OIDC or a scoped secret so it cannot recur

Rotation touches live credentials and can break running deploys. Confirm the new credential works and coordinate before revoking the old one; get the user’s go-ahead on the cutover. Purging a secret from git history ($secret-scanning) is separate from rotating it, and rotating comes first — the committed value must be assumed public.

Gotchas

• Masking is not containment: a masked secret can still be exfiltrated by malicious code (base64, split, send). Masking protects against accidental logging only.
• Org/repo secrets are readable by every workflow in scope, including a new malicious one in a PR to a non-default branch if triggers allow. Scope with environments.
• Self-hosted runners on public repos execute fork PR code on your infrastructure; never attach secrets or persistent state to them without strong isolation.
• GITHUB_TOKEN defaults can be write; set the org default to read-only and widen per job.
• Reusable workflows and composite actions inherit secrets only when passed; pass the minimum.

Verification

• Grep merged workflow logs and artifacts for the secret pattern after a run: nothing.
• Confirm a fork PR build runs with no secrets (the deploy job is skipped or gated).
• From a non-privileged branch, confirm production environment secrets are not accessible.
• For OIDC: break the IAM trust sub condition in a test and confirm the role assumption is denied, then restore it.
• rg "uses:" .github/workflows | rg -v "@[0-9a-f]{40}" returns only first-party actions you accept unpinned.