Pen-testing CI/CD pipelines: a checklist

Why pipelines deserve the same scrutiny as production

A modern build pipeline has access to:

• Production deploy keys
• Cloud provider credentials
• Package registry tokens
• Source code signing keys
• Customer database read access (in some flows)

If an attacker compromises CI, they own production. Yet most pen-tests stop at the application layer.

The 12-point checklist

1. Branch protection — main protected, required reviews, no force-push
2. Required CI checks — security scans + tests must pass before merge
3. Workflow review — no workflow_dispatch from untrusted forks
4. Pinned actions — every third-party action pinned to a SHA, not a tag
5. Secret scoping — least-privilege scopes, environment-scoped where supported
6. OIDC for cloud — short-lived federated credentials over long-lived keys
7. Self-hosted runner isolation — ephemeral runners, never reused across jobs
8. Artifact signing — releases signed with a key not stored in CI
9. Dependency provenance — SBOM generated, supply-chain attacks detected
10. Audit logs — pipeline runs logged to immutable storage
11. Approval gates — production deploys require human approval
12. Disaster recovery — pipeline can be rebuilt from source in under an hour

What we typically find

• Pinned to a tag, not a SHA — 60% of teams
• Long-lived AWS keys in secrets — 40%
• No SBOM — 75%
• Self-hosted runners reused across jobs — 30%
• Production deploy without approval — 20%

None of these are exotic. Closing them takes a sprint.