deveshYour pipeline is production
The CI system can push code to every environment you have. An attacker who owns the pipeline does not need to attack production — the pipeline is production with better credentials. Treat it that way.
1. Kill long-lived cloud keys — use OIDC
Static AWS_ACCESS_KEY_ID secrets leak in logs, forks and laptops, and they never expire. Every major CI provider can mint short-lived cloud credentials per job via OIDC federation. The token lives minutes, is scoped to one repo and one role, and there is nothing to rotate or steal.
2. Scope secrets to the job that needs them
The lint job does not need the production deploy token. Split workflows so secrets attach only to the deploy stage, ideally gated by environment protection rules with a required reviewer.
3. Treat pull requests as hostile input
Script injection through branch names, PR titles and commit messages is the most common CI exploit in the wild:
# VULNERABLE — attacker-controlled string interpolated into shell
run: echo "Deploying ${{ github.event.pull_request.title }}"
# SAFE — pass through an env var, let the shell treat it as data
env:
PR_TITLE: ${{ github.event.pull_request.title }}
run: echo "Deploying $PR_TITLE"4. Pin third-party actions and images
A tag like @v3 is mutable — whoever controls that repo controls your pipeline. Pin actions to a full commit SHA and base images to a digest, then let a bot propose updates you review like any other dependency.
5. Sign what you build, verify what you deploy
Artifact signing (cosign or the equivalent in your ecosystem) means the cluster can refuse anything that did not come from your pipeline — closing the "push a hand-built image straight to the registry" hole.
6. Make deploy logs an audit trail
Every production deploy should answer: who triggered it, from which commit, approved by whom. If the answer lives only in the CI provider's 90-day log retention, export it.
7. Run a quarterly pipeline pentest on yourself
- Can a fork PR read any secret?
- Can a compromised dependency exfiltrate the OIDC token?
- Can anyone deploy without review by editing the workflow file itself?
That last one surprises people: workflow files need CODEOWNERS protection too, or every other control can be edited away in the same PR that exploits it.